Overcoming infrastructure as code obstacles: It’s time for infrastructure from code


This is a contribution from Asher Sterkin, General Manager of BST LABS, developer of CAIOS, the cloud AI operating system. BST LABS is a subsidiary of BlackSwan Technologies.

According to an O’Reilly survey, 48% of companies intend to migrate half or more of their applications to the cloud in 2022. With the survey citing the reliability, agility, and cost management of cloud deployment as related requirements, organizations are focusing on the processes and tools needed to ensure the transition from code development to cloud deployment is consistent and continuous is. These goals have given rise to related trends: DevOps, PlatformOps (the tools, increasingly from third-party ISVs, that automate end-to-end DevOps), CI/CD, and finally Infrastructure as Code (IaC).

Interest in IaC has grown dramatically recently. Its value is reflected by more than one venture capitalist who state that IaC “a need for any organization built on the modern cloud”, i.e. with serverless / containerized / AI-friendly platforms.

IaC relies on a variety of structured languages ​​to describe and implement how one’s cloud environment is configured. The format can vary from declarative statements a la JSON to programmatic SDKs, and the statements can depend on the cloud platform used. However, one shared benefit stands out: IaC frameworks provide version control across deployment configurations, making each configuration faster to set up, precisely repeatable, and less error-prone.

With the cloud, control over the environment is just as important as managing the programming code itself. With the proliferation of hybrid and multi-cloud environments, the need for IaC-based management becomes even more important.

IaC technology and business implications

A “code represents infrastructure” approach offers numerous benefits, not only for the technical teams, but also at the business level.

For the DevOps and cloud engineering organizations, the instruction sets and scripts in Infrastructure as Code make it easy to apply strict version control to environment specifications. This is essential given the thousands of command lines required to configure a typical application in the cloud. IaC is in contrast to alternative, interactive tools or native hardware configuration programs, neither of which ensure the consistency and efficiency of the environment management process.

For the IT security team, security best practices can be built into the environment configuration, for example to ensure access to least privileged resources in all situations.

At the highest level, a company becomes more digitally agile overall. When a developer is ready to move code to production in the cloud, the admin has little or no waiting to review or change the environment when DevOps is committed to an IaC approach. New web or in-house digital services can be deployed to the cloud weekly or faster without having to consider performance issues. With IaC, the rationale for continuously monitoring customer/website visitor responses to new digital features, or monitoring competitor digital capabilities and responding via quick sprints, becomes significantly stronger.

Obstacles to deployment in the modern cloud

Despite the benefits of IaC, these early tools have certain common problems. First, the IaC approach requires significant oversight. The tools are powerful and can easily be applied in error. Uncaught failures can quickly expose your broader cloud infrastructure to performance issues and risk. Second, creating IaC deployment templates can be tedious. As a result, DevOps often fall back on a one-size-fits-all template that is either sub-optimized for performance, cost, and/or security.

When it comes to security issues, best practices can be built into one’s cloud configurations using IaC, but executing on this strategy depends on DevSecOps staff rigorously defining each configuration, not just production. Strong security is not automatically achieved with this approach.

Certain challenges with IaC are addressed: For example, in many cases one’s own team must select and specialize in a language that will be used to specify the infrastructure. In response, certain IaC tools have started offering IaC support via more popular programming languages ​​and CDKs (Cloud Development Kits).

Basically, however, IaC in its current form does not fulfill the full promise of modern cloud computing, since it works at a relatively low level of abstraction of the cloud platform and, for example, only deals with resource allocation, not with optimization.

Enter infrastructure from code

infrastructure from Code (IfC) is a major improvement over Infrastructure how Code. With IfC, a DevOps team does not have to specify and maintain extensive configuration specifications or even learn an IaC language. Instead, a “cloud compiler” (more specifically, a “service template compiler”) interprets the logic and references in traditional programming languages ​​and automatically generates the thousands of lines of logic flow, resource configuration, and permissions specification required for a platform like Amazon Web -Services. This configuration generation occurs immediately when the code logic has changed and a new set of tests or deployment is required.

10x improvements in developer productivity and deployment speed are possible with IfC’s auto-generated cloud specifications. Developers can integrate new cloud services – data sources, APIs, authentication, notifications, etc. – by importing libraries; DevOps does not need to manually configure the added services. In addition, test cycles are reduced because you can test both on a local computer and in the cloud in a rapid-fire sequence. In addition, best practice security measures are consistently applied across all applications and environments.

This is how IFC works

How does Infrastructure from Code achieve automated cloud resource configuration creation? It relies on simple reference conventions embedded in normal programming code to indicate which cloud services are required. For example, if you start the name of a programming function with “get_”, it means that REST APIs are being called and therefore an API gateway must be configured.

The cloud compiler makes basic assumptions about what an appropriate environment configuration is for an application and the services it invokes. This is ideal for a quick solution proof of concept or minimally viable product (MVP) creation. To migrate software from a PoC to enterprise-wide production, the cloud environment will likely involve security, price, and performance hardening of the environment to align with an organization’s practices. Nonetheless, 80% or more of an organization’s configuration is created by the IfC compiler by default.

Breakthrough Opportunities for the Cloud

The potential of the rapidly evolving IfC tools is even greater than the current benefits listed above. The cloud compiler isolates the considerations of which cloud platform to use in its own environment from the applications themselves. Organizations are free to switch cloud providers for technical or financial reasons (or simply to improve their bargaining power) or to flexibly manage a multi-cloud environment.

The information that IfC collects about its own cloud environment expands the possibilities for automatically optimizing the performance and operational costs of applications and services in this environment. Support for cloud portability and machine learning-based performance optimization will likely appear in IfC frameworks later in 2022.

While cloud computing has become easier to adopt and more flexible to use, complicated deployment efforts have discouraged innovation and increased costs. With infrastructure as – and now, from – Code, one of the biggest barriers to cloud adoption, is minimized, paving the way for greater code democratization.


Comments are closed.