4 Pillars of the “Infrastructure from Code”
Part Three: Deployment Locations; IfC Mission Elaborated
In this series, I’m trying to answer the question: “Precisely what kind of problems is IfC trying to solve?”
Acknowledgements
Many thanks to Shruti Kukkar for the valuable feedback on the early draft of this paper.
Introduction
In Part One of this series I suggested the following mission statement for Infrastructure of Code solutions: “To ensure an automatic conversion of cloud-neutral application code into a coordinated set of cloud-specific assets using operational feedback as an input wherever appropriate”.
In attempt to clarify what does exactly this mean, the following diagram was introduced:
In Part One I analyzed 4 different types of interactions with cloud services (aka four pillars of IfC): Acquisition, Configuration, Consumption, and Operation.
In Part Two, I took a closer look at different types of cloud services, vendors, and different types of APIs to communicate with cloud services.
In this Part Three, I’m going to analyze different deployment location options, using AWS offerings as an example and paying a special attention to sustainability factor of each option. I’m also going to provide a more elaborated version of the IfC mission.
This is the third part of a three-part series organized as follows:
- Part One: Types of Communication with Cloud Services
- Part Two: Types of Services, Vendors, and APIs
- Part Three: Deployment Locations, IfC Mission Elaborated
Deployment Location
Once upon a time, we all were thinking that cloud is a kind of new era mainframe computer located at one place. We were aware about multiple availability zones and regions, but still considered cloud as kind of virtual centralized location, where all computations are performed, and where all data is stored. This idealized picture is pretty far from reality and is going to seize to be useful anymore. To understand why, let’s take a look at available deployment options, using AWS offerings as an example:
Apparently, cloud vendors allow us to choose from multiple options where to deploy our software:
- Device Gateway (IoT, mobile phones, tables and PCs)
- 5G Tower (AWS Wavelength)
- Content Distribution Network Point of Presence (AWS CloudFront Edge Location)
- At our office or headquarters (AWS Outposts)
- At a data center available at some large cities (AWS Local Zone)
- And, finally, at some Cloud Region
Some trade-offs in choosing the most optimal deployment option are pretty straight forward: because of speed of light limitations and network reliability constraints, tough latency requirements will push software to be deployed closer to end user. It’s also true, yet not always, that local deployment provides better privacy (I think I do not share my data with anybody). On the other hand, data aggregation, available computing power and maintenance will normally push deployments towards more centralized options. Because of technology advances with ARM and RISC-V we could get more computing power in smaller space for less energy than previous generation of even most advanced super-computers could dream about.
However, there is a catch there. The Planet Earth resources are not infinite, and we could not ignore sustainability considerations anymore. Here things, are much less obvious and require further research.
On the one hand, the current generation of centralized cloud datacenters, consume, directly and indirectly, a lot of electric power and produce a lot of physical waste and environment pollution. I highly recommend reading the Steven Gonzalez Monserrate’s “The infinite cloud is fantasy” article to get more perspective on this topic. From that perspective, it seems that the more local computing we employ, the better.
On the other hand, end user or intermediate level devices computing might consume less electric power and produce less heat, but their manufacturing might still do, not speaking about physical waste of broken or just abandoned devices, packaging, and batteries to name a few. Putting too many computing devices at home, office or somewhere in between might not be more sustainable solution than concentrating as much computing as possible at one centralized place and to leverage economics of scale to inflict as less environmental damage as possible.
The story does not stop here. Even within the same location, we might have multiple options where the computation will take place. Let’s again use AWS offerings as an example:
Strong bias towards serverless computing as most sustainable one reflects my own understanding of the subject. As we can see, there are multiple options where a computation could take place: from an API Gateway (through a request or response transformation encoded in a form of VTL Script) till a dedicated Virtual Machine instance. Which one is preferable? As usually, it depends. One option might the best one from security, cost or sustainability point of view, but enforces using an arcane programming language very few developers are fluent. Another option must be just what is required for production load, because it supplies required fleet of GPUs, but is the most expensive one and wasteful for development environment. To be honest, making the right choice for different environments: development, test, production, is too ofent just beyond mental capabilities of ordinary people involve, not saying that the situation is constantly changing due new features released by the cloud platform vendor.
We are far from to be done, though. There are multiple option for computation deployment, but what about data? Apparently there are even more, as the following diagram demonstrates, using the AWS offerings as the example:
Dear Werner Vogels! “Choose the Right Tool for Each Job” saying is nice in theory, but most of the practitioners will be wrong most of the time for sure. The number of choices, and we have not started counting alternative offerings, for the same product from different vendors, is just mind-blowing.
Are we done with this? Not yet. Just one more nail in the coffin. In distributed systems, different parts need to exchange messages. How many options do we have? You got it: beyond the mental capabilities of ordinary people, this time, not because of the sheer number of options, but because the selection criteria are too often far from obvious. And, alas, there are not enough geniuses in the world to serve all IT needs. Here is a visual proof, again from the AWS offering:
So, what could we do about all this complexity? Not too much at the moment — the computing industry is still young. We need to experiment, most likely fail, reflect, fix and try over and over again. We could, however, formulate a very important constraint.
IfC #1 Constraint: Keep deployment, computation and data location, and messaging channel completely transparent for the application code — considering the formidable challenges large-scale ubiquitous computing is going to face, the so-called Distribution Computing Fallacies argument does not hold anymore.
IfC Mission Elaborated
Based on the previous analysis, we may conclude that the core IfC mission is to ensure automatic coordination of four types of interactions with cloud services: life cycle management, pre-and post-configuration, consumption, and operation, while making pragmatic choices of the most appropriate levels of API abstraction for each cloud service and leaving enough control to the end-user for choosing the most suitable vendor, based on personal preferences, regulations or brownfield deployment constraints. In other words, IfC needs to shape properly 4 pillars of activity in a 3-dimensional space. It also needs to choose the most suitable deployment location option taking into account expected latency, privacy, cost, and sustainability requirements. Most importantly, IfC must make the deployment option transparent from the application code point of view. Thus, allowing one to choose the most sustainable one without any obstacle of mass reprogramming.
References
Publications
Here is the list of all IfC publications I’m aware about, including my own. If there is anything else not included here, drop me a line.
- A. Sterkin, “If your Computer is the Cloud, what should its Operating System look like?”
- A. Sterkin, “Serverless Cloud Import System”
- A. Sterkin, “Cloud Service Template Compiler in Python”
- A. Sterkin, “Cloud Application Infrastructure from Code (IfC): The Next Logical Step in Cloud Automation”
- Shawn Wang, “The Self Provisioning Runtime”
- Allen Helton, “What Does The Future Hold For Serverless?”
- Allen Helton, “My First Impressions of Infrastructure From Code”
- Allen Helton, “The Current State of Infrastructure From Code”
- Allen Helton, “Why Serverless Direct Integrations Aren’t As Scary as They Sound”
- Paul Swail, “Infrastructure-from-Code vs Infrastructure-as-Code”
- Nadar Danelya, “Infrastructure From Code”
- Jeremy Daly, “Introducing Serverless Cloud”
- Jeremy Daly, “The future of cloud development”
- Jeremy Daly, “Can Serverless really save polar bears?”
- Russel Schick, “How Serverless Cloud Works (Part 1)”
- Russel Schick, “How Serverless Cloud Works (Part 2)”
- Alex Mitchel, “Building a Serverless Express App with Klotho”
- Steven Gonzalez Monserrate, “The infinite cloud is fantasy”
Products
Here is the list of pure IfC products, I’m aware about, including my own CAIOS. If there is anything else not included here, drop me a line.
- Cloud AI Operating System (CAIOS)
- Serverless Cloud
- Nitric
- Encore
- Modal
- Shuttle
- Klotho
- Dark
- Ampt
- Substation — not exactly IfC, but close enough and interesting
- CloudCompiler
- AWS Chalice
- Domovoi
About
The author, Asher Sterkin, is an SVP Engineering and GM at BST LABS. BST LABS is breaking the cloud barrier — making it easier for organizations to realize the full potential of cloud computing through a range of open-source and commercial offerings. We are best known for CAIOS, the Cloud AI Operating System, a development platform featuring Infrastructure-from-Code technology. BST LABS is a software engineering unit of BlackSwan Technologies.
