Deploy Web Infrastructures That Are Both Complex and Maintainable Through Infrastructure as Code

At Mirego, we have been designing, developing and deploying Web applications for over 10 years. This allowed us to experience a variety of platforms, suppliers, techniques and deployment principles.

Lately, the desire to minimize the risk of human error, improve visibility on the infrastructure and increase the validity of our projects’ documentation led us to question our DevOps processes. For the past few years, we have relied on the principles of Infrastructure as Code to build and deploy reliable, maintainable and documented Web infrastructures.

Evolution

First, in 2008, the rise of cloud computing with the arrival of Amazon Web Services (AWS) EC2 service allowed us to manually launch machines on which we installed Web servers. Manual provisioning and deployments controlled by custom scripts were common problems.

Then came Heroku, which eliminated machine management and customs scripts became obsolete when performing manipulations relating to the deployment of a Web application. Adjustment of the number of instances, automatic security updates of the operating system, rapid provisioning of external components via add-ons, etc. All this complexity was abstract and managed transparently by Heroku.

With Mirego’s growth and the size of our new clients, Heroku often ended up being put aside since these projects came with constraints from specific suppliers. These limitations, combined with the expensive management costs of Heroku, made us pivot to services such as AWS Elastic Beanstalk, Google App Engine and Azure App Services. These services are a good compromise between a full service like Heroku and Do it yourself services like AWS EC2 and Google Compute Engine, which offer more control and flexibility, but also require more maintenance and configuration of internal services to be provisioned (e.g. database, content distribution network). Everything was still managed with manual operations and personalized scripts using the CLI tools made available to us by these suppliers.

In short, regardless of the supplier’s choice (AWS, Google Cloud, Azure, Heroku, etc.) and its servicing methods (do it yourself, fully managed, semi-managed, etc.), our infrastructure deployment principles were always the same and therefore had the same potential challenges.

Challenge #1: Risk of human error

No one is perfect, everyone makes mistakes sometimes. By relying on human manipulation to make changes in an infrastructure, we introduced an additional risk into the equation since these modifications were often far from trivial. Differently or poorly configured infrastructures depending on environments then became potential liabilities.

Challenge #2: Lack of visibility

We have had code review processes in place for a very long time to ensure the highest quality code when integrating into our existing projects. We couldn’t say the same for infrastructure changes and deployments, which are just as, if not more, important than changes to the code. There was little to no traceability for all parties, either on who made what change or triggered what deployment.

Challenge #3: Documentation for information only

Documentation is often seen as the bane of developers. Despite its crucial importance in the maintainability of a project, its value is often only defined by the overall effort put in by the team to write and maintain it. If there is no direct incentive to maintain documentation, it will be left behind and become obsolete or worse, harmful. Often, this is what happened with our infrastructure documentation; one could no longer rely on documentation to know the truth.

Infrastructure as Code

To eliminate these problems, we turned to the principles of Infrastructure as Code (IaC).

In an IaC system, the state of the infrastructure is represented declaratively rather than imperatively in the form of code in the project. This report includes the basic components of the infrastructure: servers, internal services, deployed applications, configurations, etc.

A tool is then in charge of applying this state in a given environment, taking care of making the additions, modifications and deletions necessary to reflect the state described in the code, compared to the state currently in place in this environment.

Benefit #1: Processes applying to the code

Since the state of the infrastructure is stored declaratively in the project files, it is therefore treated as part of the project code. It is then subjected to the same processes as the remaining code:

• Versioning—You can view its history and evolution since the start of the project;
• Code Review—Changes made to it must be approved by team members before being incorporated;
• Linting and formatting—Its syntax and format are essential in the maintainability of it, they must be taken care of.

Benefit #2: No human manipulation, no human error

Relying on an automated tool to deploy infrastructures and Web applications ensures that we have:

• Peace of mind—No direct human input is required in applying changes. The only human intervention acts on the declarative representation of the infrastructure and not on the infrastructure as such. The risk of human error is therefore minimized;
• Traceability—Any changes and deployments in the infrastructure are documented, traceable and attributable;
• Multi-environment symmetry—Perfect symmetry between infrastructures deployed in different environments (e.g. development and production) allows us to reduce the number of potential bugs that could be caused by even minor differences.

Benefit #3: Security and ownership

It is important to Mirego that developers cultivate a sense of maximum ownership for the product they build. Functionality must be carried on by the same person from the beginning (code) until the end (deployment). The security of the infrastructure is critical, and it is just as important to us that a minimum of people have access to it. An automated infrastructure deployment system allows us to strike the right balance between a culture of ownership and security. Anyone can deploy infrastructure changes, but no one has direct access to them since it is the role of the automated system to implement them.

Benefit #4: Disaster recovery

In the event of a major incident, it is simple to provision a new environment from scratch since it suffices to follow the same process as a deployment or a simple change: the automated tool applies the state described in relation to the state in place. The state in place is then empty and all components will be created automatically.

Benefit #5: Implicit documentation

In describing the infrastructure and its components, we are also documenting it. It then becomes almost impossible to end up with incomplete or incorrect infrastructure documentation since the infrastructure itself is the source of truth that is used to apply the changes.