Everybody enjoys shortcuts. We enjoy them in their most literal sense, such as benefitting from a shorter route to the office and, increasingly, we enjoy them in the way we use technology, such as having our favorite app appear on the home screen of our smartphones. Much like animals and plants, humans are driven to conserve energy (both mental and physical). We do this so that we can spend our time or other resources doing something that we enjoy more, or something that adds more value to our lives. Whatever the reason, we continue to discover, develop and enjoy shortcuts in all facets of our lives. IT and computing are no different. Marcin Dąbrowski, Chief Innovation Officer at ITMAGINATION, explains how IT professionals are taking shortcuts to the next level, with Infrastructure as Code (IaC).
Provisioning infrastructure to test new products and services can be a tricky business. Cloud services, such AWS and Microsoft Azure, are making life easier, but IT professionals still need to consider aspects such as scalability and security. They need tools to relieve them of tasks such as manually creating and maintaining environments. Infrastructure as Code, or IaC as it’s often referred to, is a recent development that enables engineers to create individual files that, with just one click, enable the creation of a ready-to-use environment that can be used to support an IT system or service. With IaC, engineers can automate the creation, maintenance and update of systems as part of their Continuous Integration/Continuous Deployment initiatives. The time freed up by using IaC can be devoted to ongoing enhancements of the system or service.
Imagine if you could:
From a business perspective, IaC means saving time and resources spent on tasks that you don’t necessarily see the output of and freeing up time and resources for tasks that matter to the top line, such as adding new features and functionalities or improving performance.
Configuration files, which are used to define environments, are typically text files. They are created in languages such as JSON and YAML, i.e. languages that are used by programmers on a daily basis in the serialization of data and sending data between various different system components. Thanks to the use of these well-known languages, these text files can be edited in the same tools as the source code (e.g. Visual Studio, XCode, IntelliJ, etc.) and then saved as a new version in a code repository such as Bitbucket, GitHub, Azure DevOps and others. This enables full control, visibility and transparency over the configuration of the infrastructure. This is especially useful if a system or service is worked on by multiple individuals, as it allows them to see what changes have been made, when they were made and who made them. Importantly, it also enables the team to revert back to previous iterations if it is discovered that later iterations feature bugs or cause issues with the performance of the system or service.
This word, popular among IT professionals, means that an operation can be executed many times and will always provide the same outcome. For example, if the operation being executed is to extract a specific value from a database, then that action can be performed an infinite number of times and – provided that the value in the database does not change – the value being extracted will not change.
An environment provisioned using IaC will work in this way, provided that the application and IaC code are based on the same source code. This is an important consideration, especially in the context of maintaining a service or system operational and verifying errors. In this way, IaC allows engineers to forget about problems related to services working differently according to how and where they are accessed. We’ve all heard people say “it works for me” or “I don’t know why it’s not working for you”. There can be a variety of reasons for services working differently for different people (e.g. network configurations, changing configurations at the moment of an applications startup, etc.) but IaC empowers engineers to dictate all such configurations so that the experience is the same for everybody accessing the service or system. If problems are detected, the engineer simply updates the IaC file to address any such problems, which means that the problem should be resolved and that there is no requirement for end users to change anything at their end in order to make use of the service.
We really start to feel the benefits of Infrastructure as Code (IaC) when we build the provisioning of an environment into the entire product lifecycle. At that point, it becomes an integral part of the CI/CD process (e.g. in the Azure DevOps pipeline). That way, when the source code of an application or system is committed to the repository, it’s then possible to test it immediately in an environment that is built from the newest version of the application. We can immediately run tests automatically, using tools like Selenium or Cypress. This has a number of benefits. A new or updated service can be written by one programmer or on an individual branch of code within a larger service or system. It can be deployed immediately for testing and, because it’s provisioned quickly and on its own environment, it doesn’t get in the way of applications or environments being run elsewhere. In this way, various different individuals can be working on – and testing – individual features or functionalities on individual environments, without them disrupting each other or without having to wait for individual versions to be brought together and tested as a whole. This enables the product to be delivered and tested much more quickly and for the business to start benefitting faster.
The public cloud has delivered a number of significant benefits to businesses and IT organizations (ITMAGINATION recently published 30 tips on how to make better use of cloud). However, it can still be a challenge to configure different resources, networks and subnetworks and appropriate access for different resources and services. And it’s often challenging to make the different service components from different vendors’ Infrastructure as a Service (IaaS) and Platform as a Service (PaaS) portfolios work together as they should. Using IaC, it’s possible to capture the entire configuration in a single script and upload it to public cloud provider’s portal. Whether it’s Azure or AWA, the most important tasks can be conducted through the portal and they’re also available via APIs (such as those used in CI/CD tool suites). Writing a script that an API can make use of is one of the first tasks a DevOps professional will undertake when setting up a new project. In the JSON or YAML file referred to earlier, an engineer can include all sorts of configuration variations and use tools that will change the properties of the script depending on what kind of cloud environment we want to create and provision.
With virtualization, public cloud and containers (e.g. Docker) our approach to creating, provisioning and maintaining environments for new applications and services has changed dramatically. Generally speaking, the environments live much shorter lives. Very often, if significant changes are made to a product or service, it’s easier to simply discard the existing environment and set up a new one. With IaC, discarding existing infrastructure environments and creating new ones can be done rapidly, which means the precious time of your developers and engineers is used more effectively and there is little or no impact on your AWS or Azure bill.
Another huge benefit of IaC is the freedom it provides you to separate the environment from the hardware level. As long as you’re not using specific platform elements from a particular supplier, IaC empowers you to accelerate your migration from Azure to AWS and vice versa, which means that you can take advantage of the right provider at the right time and for the right market.
ITMAGINATION has extensive experience deploying applications and services to the cloud using IaC. We have enjoyed great success with Terraform, an open-source tool developed by HashiCorp that is available for use on all of the leading cloud platforms. Terraform works regardless of which technologies and coding languages are used to build the application. Terraform uses its proprietary language, HCL, although this is similar to YAML and can be understand by any competent programmer. One of the main advantages of Terraform is the added features and functionalities, such as the ability to automate communication with various different components of platforms such as Azure, AWS and Google Cloud. Furthermore, it makes describing databases (e.g. PostreSQL or MySQL) and RabbitMQ much easier and enables environments to be updated automatically based on changes to the original text file. It can all be done with one command in a command-line interface.
Once a configuration has been done well once, it becomes a ready-to-go infrastructure component that can be used in future projects (provided that the use and architectural approach is similar). These configurations can be used again, refined and finetuned with each iteration. And the beauty is that these configurations remain as the company’s assets, and thus enable the organization to test and bring products to market much more quickly than would otherwise be possible.
ITMAGINATION has a wealth of experience helping companies maximize the value of Infrastructure as Code and. We have ‘baked’ IaC into our standard way of working and apply it all projects possible. In this way, we’re helping ITMAGINATION clients maximize their return on investment from cloud technologies.
If you want to get your products and services to market stronger and faster, talk to ITMAGINATION.
Learn it. Know it. Done.
.svg){kind=small}
