This post is from the XebiaLabs blog and has not been updated since the original publish date.
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.
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.