10 Best Practices for Application Deployment

Source:- datamation.com

The application deployment process offers numerous complex challenges to enterprise IT managers. Chief among them: your staff’s existing application deployment skills and tactics may not apply in all scenarios. For instance, deploying an on-premises or private cloud is nothing like deploying in the public cloud.

We’ll look at several of these challenges as we explore application deployment strategies in-depth. Or you can jump directly to the application deployment best practices list below.

Some background: With the move to the cloud, cloud-specific deployment skills are as mandatory as on-prem deployment skills are for top efficiency, security, and productive output. According to the RightScale State of the Cloud Report, 92 percent of organizations use cloud companies, so you better know cloud deployment as well as you know on-premises deployment.

Cloud vs. In-House Application Deployment

There is a world of difference between on-premise deployment and cloud computing application deployment. If you approach your cloud deployment or migration thinking there is little difference, you could be in for a world of financial hurt.

Among the key differences:

• Direct Access: On-premises apps have direct access to the servers and all of the data that is kept on them. In contrast, cloud apps will at the very least need to connect to the business to get at on-premises data or, more likely, collect data in the cloud and process it there. Moving data between on-prem and the cloud is expensive and opens the company up to potential regulatory problems, so cloud apps are more likely to use data born in the cloud.

• The Risk Element: Cloud apps minimize risk. Should the project fail, sure, your developer time is gone. But you didn’t invest in on-premises equipment, like servers and software licenses. On-premise app deployment leans toward expansion of your data center, which brings increased expenses in power and cooling.

• Much Faster: Cloud deployments are faster since virtual machines can be spun up in minutes instead of days to deploy workspace on-prem. And if more resources are needed, the same applies. It takes minutes to allocate resources on Amazon Web Services or Microsoft Azure or Google Cloud instead of weeks to order and install new hardware.

• The Expense Issue: On the down side of the cloud app deployment, every expense is metered and charged, so if you have an app that needs to run 24/7 and process lots of data in a large memory space, the AWS bill is going to grow to a major level. On-prem, there is no such use charges. Once the servers are bought, paid for, and deployed, that’s it.

• Regulatory concerns: Also you may face regulatory limits on moving data to the cloud and not have the option of letting some data out of your firewall. So in some cases, the apps and data must stay in-house and on-premises.

Cloud Application Deployment: Key Scenarios

Should you choose to deploy your application in the cloud, there are generally speaking three options: infrastructure as a service (IaaS), platform as a service (PaaS), or software as a service (SaaS). Your choice depends on the specific needs for the application.

IaaS Deployment

In an IaaS scenario, the infrastructure for building cloud apps is provided for you. This is the most basic service of all the cloud providers, whether it’s Amazon or a local provider. The vendor provides a virtual machine and operating system, usually Linux but in some cases Windows. However, you will have to install libraries, application runtimes, and any databases that your application will require.

PAAS Deployment

PaaS provides more of a development environment, so you get developer tools, libraries, and databases. All you need to provide is the apps and data. The PaaS environment is actively and completely managed by the provider. On the flip side, you often have no choice but the developer packages provided to you, so if you don’t want/like/need what the provider offers, you are out of luck.

SaaS Deployment

With SaaS, everything is provided for you except the application data. Vendors provide application coding tools to modify their tools but you are still working with the app they offer. For example, Salesforce allows you to customize its flagship CRM software, but in the end it’s still Salesforce’s product and some changes are out of your reach.

Almost all applications require a database of some type, and while the major vendors offer a variety of SQL and NoSQL databases, while smaller providers have fewer options. Cloud providers also offer horizontal and vertical scaling and load balancing for spikes in app usage.

Application Deployment Evaluation Cycle

Application deployment is about intent. In some instances, after you select a Big Data application, you’ll need to be clear about the plans and intentions for this app. In this process, an IT manager sets up a schedule to evaluate these key question in the life cycle of an application:

• When should an application be installed?

• When should the app by updated?

• Should an application be uninstalled or completely deleted?

Completely and carefully scheduling these key points allows for updates and removals to be automated – and taken out of the hands of end users.

An industry-leading example of of a tool used for the app deployment evaluation cycle is Microsoft’s System Center Configuration Manager, which engages in a variety of actions on client computers. The Application Deployment Evaluation Cycle will check new application deployment polices available to client computer and start a new or update installation as per schedule.

Application Deployment Checklist: Best Practices

There are a number of best practices to be kept in mind when it comes to application deployment. Some are specific to on-prem or the cloud while others are universal. We will start out with the basics and drill down from there.

1) Simple. Keep the installation structure simple, with minimal file distribution. Don’t install libraries that won’t be used and don’t scatter files all over the place.

2) Consistent. Have a consistent deployment mechanism and don’t change things between development, test, and deployment.

3) Organized. Clean up after yourself. Remove old and obsolete files when installing a new version. Delete old files before beginning the install process so the install is essentially a clean installation.

4) Secure. Focus on security as if your company depends on it – because it just might. Poke and prod your application perimeters to find holes where hacker might attack. Consider using any number of application security tools.

5) Plan B. Have a roll back strategy in case things go wrong. Having a “plan B” may save your company when problems arise – and they will.

6) Be Agile. Agile deployment’s biggest strength is in rapid deployment, along with continuous delivery. Of course it only works if you use the processes listed above.

7) Checklist. Use a deployment checklist. There’s a reason pilots go through a checklist before takeoff even after decades in the cockpit. Things can slip your mind. A checklist reminds you of every step.

8) Continuous. Use a continuous integration server. One of the big problems in a project is tracking down why code works on the developer’s computer but breaks in a deployment setting. A continuous integration (CI) server is an important tool in Agile development because it pulls in the source code from all developers and test it together in real time. That’s why CI servers are sometimes called “build servers.”

9) Automate. Use automation as much as possible. Automation can and should be done at the deployment level through tools like Microsoft System Center Configuration Manager so as to push out the most recent build of an app as possible. Scripting is also a means of deployment in non-Microsoft and Microsoft environments alike.

10) Top Tools. Use the right tool, always. This will likely require some research. There is no lack of deployment tools available for a wide array of budgets and enterprise scenarios.