How do you treat the “house” of your applications? In this article we will review the concepts of Environments and Infrastructure and how to manage them with a DevOps mindset.
It is time to define concepts:
In nature, an environment is the habitat that surrounds a body.
For example, our planetary ecosystem is an environment made up of millions of sub-ecosystems, which in turn have thousands of plant and animal species cohabiting with each other.
In technology, an environment is the territory that houses and surrounds a software application so that it works and fulfills its purpose.
In technology, our environment is the digital space where databases, websites, rest apis, and other apps (including infrastructure) interact in harmony and synchronicity to support a software product or service.
But, unlike natural ecosystems, a technological environment can be recreated at our disposal. This is the great advantage that we have in relation to nature and that we take advantage of any area of knowledge.
Imagine this. You see two football teams battling it out to win the Champions League and realize that it’s unlikely they got there without a lot of private training, rehearsing different plays and strategies.
Or even think about this. When you go to a concert and enjoy the impressive performance put on by an artist. Do you think he or she got on stage to give that show without having practiced (and a lot) in private?
This is the same question and perspective that we take when we have to build our environments on technology.
In our case we have two types of environments: Production (Prod) and Non-Production (non-prod). This last type can be divided into several others, but for simplification we will only take these two types.’.
Non-prod is where we confidently fail, and Prod is where we clean things up.
The trick is that these two environments are as similar as possible in functionality and elements with the only difference being their size or performance power.
Sound trivial? Yes, I know.
I also know that very few software teams are aware of this triviality and/or have the discipline to keep both environments nearly identical, which gives them constant headaches.
Infrastructure (or “infra”, as we will call it from now on) on the other hand are those elements that are interconnected to form an environment.
For example, in the material context, “Home”, this abstract idea, is your environment; and the house with its rooms, electrical and aqueduct connections and other elements, make up the infrastructure.
This infrastructure is what houses us and sustains our daily lives (water, heat, shelter, etc.). And being tangible, this infrastructure needs to be built brick by brick, cable by cable, based on a previous design (blueprint) created by an architect.
The problem with this type of infrastructure in the physical world is that it takes time to build and also requires human effort and tools to be set up following that architectural blueprint.
On the other hand, something similar happens in technology in certain aspects, since it is necessary to have an infrastructure with interconnected elements (servers, databases, Caching Systems, AI, etc.) that hosts our applications to provide a service to users.
But, contrary to the physical plane, in the digital world we can (and must) make use of automation tools that allow us to build and destroy infrastructure and entire environments with minimal human effort.
Sure, we still need a Blueprint, and this is what we call Infrastructure-as-Code (IaC or Infrastructure-as-Code).
The IaC is similar to the plans or blueprint that an architect creates for a house before it is built, and thanks to it we can create and destroy infrastructure as we please and with minimal effort.
Well, once this is clear, now we are going to review the 5 tips that will make your day to day in technology easier.
1. Build at least two environments
Production and non-production are the minimum we need in order to have peace of mind before releasing new versions of software to Production.
Beware, when I talk about Non-Production, I DON’T MEAN your laptop.
Non-prod It must be an environment with almost-identical characteristics to Production.
If, for example, your Production environment is in Azure, then to non-prod has to be there too, and it’s fine if it has a smaller capacity. Take it as a tiny twin brother of your official environment.
2. Build Promotion Pipelines
Since you have two environments, it’s now necessary to create automated pipelines that allow you to promote changes from the non-prod environment to Prod.
For this, like IaC, there are Pipeline-as-Code (PaC), but we will talk about this in another article. The important thing at this point is to understand that these are the Pipelines that will allow you to practice Continuous Deployment effectively by taking your changes from one environment to another with minimal human intervention.
3. Use Automation most of the time
If you want to go to sleep every night knowing your infrastructure is stable, you need to automate EVERYTHING using IaC.
The commandment is “Automation First”, and to fulfill it, we use tools like Terraform, AWS CloudFormation, Azure RM, Ansible, etc.
I know it sounds extreme, but maintaining your discipline on this principle is like having insurance against accidents or fires… because these will come sooner or later (Constructive Pessimism).
Now, an exception to this rule:
If you are not yet familiar with the infrastructure you will be using, put aside the IaC momentarily and experiment with this infrastructure using the visual tools (User Interface) until you feel comfortable. Then destroy everything you made and it’s time to re-create it using IaC.
4. Avoid manual changes to the infra or its configuration
Any changes must have been previously created in code. This will ensure that your infrastructure blueprint is continually reflecting the implementation.
In a future post we will talk about Conf-as-Code.
5. Re-create Non-Prod regularly
By following the previous tips you will discover that you can have several non-prod environments (for example: Testing, Staging, UAT, etc), and you will also discover that these environments can be ephemeral, coming to live only for a limited time.
For this reason it’s highly recommended to be able to destroy and re-create non-prod environments on a regular basis as this will give you the confidence to recreate your environments at any time and especially in Production if something were to happen with this environment.
This mindset of knowing environments means practicing “Lean Infrastructure”.
To finish, apply at least one of these tips and I assure you that your environments and infrastructure will become more robust, as will your DevOps practice in general.
Let me know what other tips you have and as always, leave your comments to continue the conversation!
Keep on Learning….