Infrastructure-as-Code series - BlackSwan: Configurations, challenges & CDKs
The Computer Weekly Developer Network (CWDN) now starts its Infrastructure-as-Code (IaC) series of technical analysis discussions to uncover what this layer of the global IT fabric really means, how it integrates with the current push to orchestrate increasingly cloud-native systems more efficiently and what it means for software application development professionals now looking to take advantage of its core technology proposition.
This piece is written by Mr. Asher Sterkin, general manager at BST LABS/BlackSwan Technologies – known for Element (branded as ELEMENT), an enterprise AI and digital transformation platform, the company is making available its cloud optimization infrastructure available independently at no cost. CAIOS, the Cloud AI Operating System, reduces development times and specialist knowledge required to deploy to the cloud while improving security and performance. Sterkin has 40+ years of experience with software development frameworks and systems architectures.
Sterkin writes as follows…
Let’s start off by asking, what is IaC and what are its benefits?
Given the dominance of cloud architectures for running modern applications, technologists who are new to cloud computing might expect that code deployment is a fairly straightforward activity.
However, it’s a poorly-kept secret that a good deal of specialist knowledge relating to cloud services (plus exhaustive environment configuration specifications) are needed to translate programming code into a fully-operation cloud application.
Much of this work today is done manually by an enterprise’s DevOps team, but IaC is making headway in the environment configuration aspects of the cloud.
IaC relies on a variety of structured languages to describe and implement how a cloud environment is configured. The language format can vary from declarative statements (e.g., via YAML or JSON) to imperative SDKs (as with Pulumi or AWS CDK)… and the instructions are cloud platform dependent.
However, one common benefit stands out.
Namely, IaC frameworks provide for version control across deployment configurations.
This is essential given the thousand of lines of instructions needed to configure a typical application on the cloud. With the cloud, maintaining control of the environment setup is as critical as managing the programming code itself. Whenever application upgrades or performance troubleshooting are required, the development/DevOps/cloud engineering teams need to rely on a stable environment.
BlackSwan’s Sterkin: Cloud code pragmatic practitioner.
A side benefit of IaC is that it becomes much easier to set up new environments which are price/performance-optimised for particular applications. Without IaC, it’s tempting to run a single development and single production environment for most enterprise apps.
Also with IaC, we can build security best practices into the environment configuration, for example, ensuring least-privilege-required access to resources in all situations as part of an IaC template.
IaC challenges
But there are challenges here and IaC tools exhibit certain issues. The IaC approach requires significant oversight. The tools are powerful and readily can be applied in error, in no small part because configuration templates often are crafted manually. Uncaught errors can quickly expose your broader cloud infrastructure to performance issues and risks.
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.
IaC doesn’t, in the main, provide observability, which supports both environment troubleshooting and performance optimisation. With some tools, the conversion of declarations into cloud-platform native instructions is a black box.
While best practices for security can be built into a cloud configuration, this strategy remains dependent on DevSecOps staff rigorously defining each configuration, not just production. Strong security isn’t manifested automatically with IaC.
Cloud Development Kits (CDKs)
There are other challenges with IaC that are being addressed at present: for example, one’s team in many cases must select and specialise in a language used to specify the infrastructure. Some of the languages used are HashiCorp Configuration Language (HCL), JSON and YAML.
This demand is coming at a time where language and platform agnosticism is emerging as a trend with great potential. In response, certain IaC tools have started to offer IaC support via more common programming languages and CDKs (Cloud Development Kits).
In summary, IaC represents great progress but, in its current state, fails to deliver on the full promise of cloud computing. This is most of all because it still works at a relatively low level of cloud platform abstraction and addresses only resource allocation.