Deployment Automation vs. Server Provisioning

In my two previous blogs, I compared deployment automation to build automation and release management automation respectively. Build automation tools automate the building of software while deployment automation focuses on deploying the software after it has been built. In the other blog, I explained that release management tools manage the release process of software but don't do the actual work. In this blog, I will compare deployment automation to server provisioning automation and here the distinction is harder to make. So please bear with me!Let's start by defining server provisioning. We can look at the ubiquitous Wikipedia definition or at the one from wordIQ. They tell a similar story: Server provisioning is about making a server ready for service. It usually involves activities such as:

• Selecting a server from a physical server pool or selecting a hypervisor, whichever is applicable.
• Selecting an image to install (for a physical server) or an image to run (for a virtual server).
• Installing and booting the image.
• Assigning and configuring resources (IP address, disk space, etc.).
• Installing and configuring middleware.
• Installing and configuring applications.

There are a number of commercial products (such as CA Server Automation, HP Server Automation and IBM Tivoli Provisioning Manager for physical servers and IBM CloudBurst for virtual servers) and open source tools (like Chef and Puppet) that automate this process. If we take a closer look at that list of activities, there is one that is of particular interest to us: The last step "Install and configure applications" is really about deploying an application! If we were to zoom in here, we'd see activities like the ones described in Robert van Loghem's blog So what is a deployment really?. One could say that deployment automation is a subset of server provisioning. But that is not the complete story because there are some things that are very specific to deployment automation. First, while server provisioning is usually solely the responsibility of the operations department, deployment automation tends to be a shared responsibility of the development and operations departments. The developers deliver the applications to be deployed, the operators maintain the environments onto which those applications will be deployed. That means that a deployment automation tool should distinguish between the different ways the different groups use the tool and it should have security features in place to make sure that neither group accidentally changes the wrong bits.

WHITE PAPER

Meeting the Challenges of Delivering Microservice Applications in the Enterprise

  Microservices offer many potential advantages, including the ability to scale, greater agility and speed, and increased flexibility. However, adopting microservices also introduces new and fundamental challenges. Download this white paper to learn about these challenges and how to addresses them.

Secondly, the lifecycle of servers is different from that of applications. For every server, there might be 10 applications deployed onto that server and each of those applications might be (re)deployed at least 10 times, which makes for applications being deployed a hundred times more often than servers being provisioned! And that means that deployment automation tools should be so easy to use so that everybody in the IT department, be they developers, testers or operators, can perform a deployment to keep up with the deluge of application deployment requests. Of course, there are two current trends that blur the boundary between server provisioning and deployment automation. On the one hand, the DevOps movement is about having a multidisciplinary team that is responsible for application development and deployment, and for infrastructure setup and configuration. But even then the lifecycle of servers will be different from the lifecycle of applications. On the other hand, cloud infrastructure means that (virtual) servers will be provisioned more often, maybe even just for the duration of a test. This causes the server lifecycle to become shorter and even become part of the application lifecycle. In fact, one can envision (virtual) server provisioning tools and deployment automation tools becoming ever more integrated as cloud infrastructure becomes more popular. Apart from the high-level differences described above, deployment automation tools also tend to have different standard functionality. To put it plainly, the most basic functionality of a Java EE application deployment automation product is to deploy an EAR file, while the most basic functionality for a server provisioning system is to install an application server (at least where it concerns Java EE). But talk about the creation of a datasource and the distinction becomes harder to make. Luckily the DevOps movement and cloud infrastructure may soon cause the distinction to disappear altogether! And then we will need tools that combine the features of the current server provisioning tools and the current deployment automation tools.