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:
- Networks
- VPN connections to existing the on-premises datacenter
- Virtual Machines
- Technical User Accounts
- and Active Directory permissions
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.
- Consistency and quality. We can quickly and easily deploy new environments or make changes to existing ones, while eliminating the need for manual configuration, which can be time-consuming and prone to errors. The infrastructure is always deployed in the same way every time, resulting in more secure, reliable and stable systems. Every change is automatically tracked.
- Ability to work iteratively. Some changes require deleting and re-creating the existing infrastructure. This can be impossible to do reliably if the infrastructure was deployed manually, and configured by a larger team. With IaC we can destroy, change, and redeploy even the most complex setups within minutes without risk.
- Code as technical documentation. When all changes are made only through IaC, then the code in the repository makes a complete, detailed technical documentation. One that is unambiguous and always up to date. IaC and a high-level governance document is all you need for even the biggest and most complex deployment!
Benefits for Neos
It is much easier to start provisioning infrastructure with the Azure Portal graphical web interface. The Portal makes several checks for the user:
- The Portal presents only proper combinations of values
- It automatically fills some values for the user
- it creates invisible and child resources implicitly
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.
Engineer’s Perspective
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.
Customer Example
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.
