Let’s consider the process of making a new server available to run our applications on: We have to follow several steps to be able to do that in production. We could divide this process into three main stages:
Stage 1: Starting an Instance
This phase covers all the necessary steps to run the application. It could also include updating security patches, which may take up to half an hour to complete. It’s hard to estimate the total duration of this stage, since if there’s an updating process going on, it will depend on how outdated the image of the operating system is.
Stage 2: Launching the Application
This implies copying the application into the server, configuring settings and running the application. If nothing goes wrong, this should take no more than a few minutes.
Stage 3: Deploying the Instance
The last step is to add the server to the infrastructure, so that it can begin to receive traffic from users. Usually, we add a load balancer to distribute users’ requests to the different instances of the application. At least in AWS, the load balancer is expected to transfer a sequence of requests to the application, to ensure that it will then be able to receive users’ requests. This could take several minutes to complete.
All the previous steps occur in what’s known as the cooldown, the period of time ranging from the moment the decision of adding a new service is made to the moment the server is ready to be used. During this period, we shouldn’t pay attention to any sign indicating we need to remove or add new servers.
We should observe though if the entire process takes a lot of time to complete (for example, if a server takes more than 45 minutes to start and be ready). In that case, we need to be able to know in advance if we have to add a new server, something that not only affects the application performance, but has an economical cost. Adding or removing resources has an impact on the application’s performance because we cannot know for certain when the users would need them.
There are ways to reduce the total time, so that we don’t have to anticipate creating new resources and avoid making a wrong decision. It’s worth noting that removing a resource is quicker than creating a new one, in terms of infrastructure. One alternative is to create an image.
Using a Previous Image: Packer and EC2 Image Builder
If we want to reduce the time needed to start an instance and deploy an application, instead of starting from scratch by updating the operating system, we could use a previously prepared image. In that way, we could have a new instance in a few minutes.
After this long introduction, we are now going to discuss two tools that make the process of creating images to use in our infrastructure a lot easier.
Packer is a multi-platform tool that was introduced some time ago in the market. It allows easy, transparent integration with other suppliers’ tools. We only need two components to use it: a JSON file and the executable file to run the JSON file we’ve defined.
EC2 Image Builder is relatively new. It uses YML and can be natively integrated into AWS. Unlike Packer, we can define smaller steps and then reuse them when creating different images. On the other hand, one of its disadvantages is that it only allows to use two types of images (Windows and Linux), while Packer has no limitations in that aspect. That’s definitely going to be an issue if we need a different image from the default one offered by AWS. For example, if we want to use a different distribution in Linux, we have to install an agent, create the image manually, and then automate it.
When it comes to its advantages, we can mention two great functionalities of EC2 Image Builder:
- It allows to create several images in different conditions (for example, after a certain amount of time or in the face of an infrastructure event).
- It’s easy to reuse components either to create or to test images —which is another functionality worth noting: the ability to execute lines of code to test images.
So, Which One of the Two Is Best?
Among Packer’s strong points is the fact that it has an easy learning curve and that it has reached maturity in the market. Anyone using Chef, Puppet or Ansible will find it simple to migrate to Packer. It’s multi-platform and easy to integrate with other services.
Compared to Packer, EC2 Image Builder is a pretty new tool. Those who aren’t familiar with the AWS ecosystem may find it complex and confusing, because there are several details to be mindful about. Its advantages lie in its integration with other AWS services.
As a final remark, I’d like to share Charles Darwin’s words to reflect upon:
“It is not the strongest species that survive, nor the most intelligent, but the ones that are most adaptable to change.”