We would like to take you on a journey to share why we use IaC. What is IaC? Infrastructure as Code or template-based Azure Infrastructure deployment.
At Neos the default way to deliver Azure projects is by using IaC with Azure Bicep. This means that all Azure resources including:
are defined and orchestrated in a set of configuration files. These configuration files are then deployed to Azure and result in a complete and ready to use infrastructure without any manual steps in the process.
Benefits for our customers.
It is much easier to start provisioning infrastructure with the Azure Portal graphical web interface. The Portal makes several checks for the user:
The Azure Portal reduces the complexity presented to the user. Some niche solutions are not available through the Portal at all. Writing good IaC requires a full understanding of underlying IT concepts, how Azure resources interact and all resources (including invisible ones) are declared implicitly.
Therefore, by using an IaC first approach, we set a high knowledge and skill standard for all teams involved. The deep understanding gained through that, allows us to quickly create accurate, complex solutions for our customers.
It is a safer (which also means less stressful) and a more pleasant way to work.
With a manually created setup, as the system grows, so grows the risk of change in general. The chance of unintentionally breaking something without being able to fix it increases. Using IaC we can make complex changes quickly and if something goes wrong, revert the change reliably within minutes.
The code is the single, standardized, unambiguous source of truth about the system. The code serves as the system technical documentation. IaC eliminates the need for manual documentation updates in various locations which can be difficult to do reliably and can create situations where key pieces of information are missing or conflicting. This in turn, can cause lost time on communication over trivial details.
IaC allows us to focus on work we enjoy and avoid repetitive tasks.
For one client, during a period of a few weeks and cooperation with another company specializing in networking, we built a complex connectivity hub in Asia. Then the requirement came to add another one in Europe as well. It took us only one meeting to define the differences between the hubs and adjust the parameter values in our code. The Europe Connectivity hub was ready and running the next day.
If the Asia hub had been manually created, then we would spend days going along the documentation and focusing on clicking the same buttons as last time, with very little chance of getting it right the first time.