This is a contributed article by 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 a survey by O’Reilly, 48% of enterprises intend to migrate half or more of their applications to the cloud in 2022. With cloud deployment reliability, agility and cost management expressed as related requirements in the survey, organisations are focusing on the processes and tools needed to ensure that the transition from code development to cloud deployment is consistent and continuous. 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 declaring that IaC is “a necessity for any organization building on the modern cloud”, i.e. using 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 instructions may depend on the cloud platform used. However, one common benefit rises to the fore: IaC frameworks provide for version control across deployment configurations, thereby making each configuration faster to set up, precisely repeatable and less error-prone.
With the cloud, maintaining control of the environment is as critical as managing the programming code itself. As hybrid- and multi-cloud environments proliferate, the need for IaC-based management becomes that much more essential.
IaC’s technology and business impact
There are multiple benefits to a “code represents infrastructure” approach, not only for the technical teams but at a business level as well.
For the DevOps and Cloud Engineering organisations, the instruction sets and scripts in Infrastructure as Code make it easier to apply rigorous version control to environment specifications. This is essential given the thousands of lines of instructions needed to configure a typical application on the cloud. IaC contrasts with 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, one can build security best practices into the environment configuration, for example, ensuring least-privilege-required access to resources in all situations.
At the highest level, a business overall becomes more digitally agile. When a developer is ready to move code to production on the cloud, there’s little-to-no wait for the admin to verify or modify the environment when DevOps has committed to an IaC approach. New web or in-house digital services can be delivered to the cloud on a weekly basis or faster, with minimal concern for performance issues. With IaC, the rationale becomes considerably stronger for continually monitoring customer / site visitor reactions to new digital features, or monitoring competitors’ digital capabilities, and reacting via quick sprints.
Obstacles to delivering on the modern cloud
Despite IaC’s benefits, these early tools exhibit certain high-level issues. First, the IaC approach requires significant oversight. The tools are powerful and readily can be applied in error. Uncaught errors can quickly expose your broader cloud infrastructure to performance issues and risks. Second, the crafting of IaC deployment templates can be tedious. Therefore, DevOps often resorts to a one-size-fits-all template, one which is sub-optimised for either performance, cost, and/or security.
As for security issues, best practices can be built into one’s cloud configurations using IaC, but effecting this strategy remains dependent on DevSecOps staff rigorously defining each configuration, not just production. Strong security isn’t achieved automatically with this approach.
Certain challenges with IaC are being addressed: for example, one’s team in many cases must select and specialise in a language used to specify the infrastructure. In response, particular IaC tools have started to offer IaC support via more common programming languages and CDKs (cloud development kits).
Fundamentally, however, IaC in its current form fails to deliver on the full promise of modern cloud computing because it works at a relatively low level of cloud platform abstraction and addresses only resource allocation, not optimisation, for example.
Enter infrastructure from code
Infrastructure from Code (IfC) is a substantial improvement over Infrastructure as Code. With IfC, a DevOps team doesn’t need to specify and maintain extensive configuration specifications or even learn an IaC language. Instead, a ‘cloud compiler’ (more precisely a ‘service template compiler’) interprets the logic and references in traditional programming languages and automatically generates the thousand-plus lines of logic flow, plus resource configuration and permissions specification, needed for a platform like Amazon Web Services. This configuration generation is done on-the-spot, whenever the code logic has changed and a new series of tests or deployment is needed.
With IfC’s automatically-generated cloud specifications, 10x improvements in developer productivity and deployment speed are possible. Developers can incorporate new cloud services - data sources, APIs, authentication, notifications, etc. - by importing libraries; there’s no need for DevOps to manually configure the added services. In addition, testing cycles are collapsed as one can test both on a local machine and in the cloud in a rapid-fire sequence. Further, best-practice security measures are consistently applied across all applications and environments.
How IfC works
How does Infrastructure from Code achieve automated creation of cloud resource configuration? It relies on simple reference conventions being embedded in normal programming code to indicate what cloud services are needed. For example, starting a programming function’s name with “get_” implies that REST APIs are invoked and therefore an API Gateway needs to be configured.
The cloud compiler applies baseline assumptions of what an appropriate environment configuration looks like for an application and the services it calls. This is ideal for quick solution proof-of-concept or the creation of a minimally viable product (MVP). To migrate software from a PoC to enterprise-wide production, the cloud environment likely will involve security, price and performance hardening of the environment to fit the practices of an enterprise. Nonetheless, 80% or more of an organisation’s configuration will be created out-of-the-box by the IfC compiler.
Game-changing possibilities for the cloud
The potential of fast-evolving IfC tools is even broader than the current benefits listed above. The cloud compiler isolates considerations of which cloud platform is used in one’s environment from the applications themselves. Organisations are free to switch cloud vendors for technical or financial reasons (or just to improve their negotiating position), or, further yet, flexibly administer a multi-cloud environment.
The intelligence that IfC captures about one’s cloud environment enhances the possibilities for automatically optimising the performance and operating cost of applications and services in that environment. Support for cloud portability and machine learning-based, performance optimisation likely will appear in IfC frameworks later in 2022.
While cloud computing is becoming easier to adopt and more agile to use, complicated deployment efforts have deterred innovation and kept costs elevated. With Infrastructure as - and now, from - Code, one of the major barriers to cloud usage is minimised, clearing the path toward the greater democratisation of code.