This year marks my 30th year in IT. I have witnessed numerous attempts by vendors over the last several decades to speed up the development process. We’ve moved from machine code to assembler to languages like Cobol, Fortran, and RPG in the early mainframe days. Each language was an attempt to abstract the complexities of the previous language in order to enable developers to complete tasks faster.
Even in the mainframe era I saw code generators for Cobol and JCL. Next, came the CASE tools from companies like Ashton Tate and Texas Instruments that promised to create large amounts of code with little effort from the developers. Then, came Windows which greatly abstracted away the complexities of managing operating systems. Windows empowered developers with drag and drop capabilities.
The Cloud On-Demand
Before cloud, I remember waiting months to get a new server procured and installed at my old corporate job. Around 2006, cloud computing emerged as the next level of abstraction. Datacenters were now being abstracted and available on demand as a set of APIs. When I left the corporate world in 2008 to join a born-in-the-cloud startup, that multiple month process became a few clicks of a mouse. A working virtual machine was available in minutes. This was my first experience with Infrastructure as a Service (IaaS) and there was no turning back.
As game changing as IaaS was, I still had to mess around with a lot of networking, storage and virtual server configurations. As a developer, all of these “IT plumbing” tasks were slowing me down from building working software. That’s when I started leveraging Platform as a Service (PaaS) solutions like Heroku. PaaS solutions took abstraction to a whole new level. Now low-level infrastructure like networking, compute and storage were managed for me. Database and application stacks were off my plate as well.
The problem with PaaS was that it was too prescriptive and often times too expensive. The public cloud providers evolved from basic compute, network and storage APIs to higher level managed services like database as a service (Azure SQL Database), streaming (AWS Kinesis) and machine learning (Google Machine Learning Engine). Now developers could pick and chose various “PaaS-like” services and combine them with IaaS capabilities as needed. Google and Microsoft also provide their own PaaS solutions that are integrated with the core services of their IaaS offering such as security, monitoring and logging services.
Combining IaaS and PaaS services has become the way forward over the last few years but it still required a significant amount of work to create the original landing zone (core infrastructure design) in the cloud due to security and regulatory requirements.
In the financial services industry, it’s common to have over 200 controls that must be baked into the infrastructure. This often includes integration of 10 or more vendor solutions like firewalls, centralized logging tools, various monitoring tools, Active Directory and more. All of this initial setup work for IaaS starts to look and feel very similar to data center work, minus the procurement process. Things like patch management, key and secrets management, third party tool life-cycle management and other processes consume large amounts of time. As important as this work is, it can significantly impact productivity, thus reducing agility.
Containers promised to abstract away a lot of the IT plumbing and configuration management in order to enable developers to be more productive. What used to take 100s of lines of code in Chef or Puppet can now be reduced to a few lines of code in a Docker Image le. In addition, the painful patching process gets reduced to the updating of the image file and re-deploying the containers. At first glance, containers look super simple to build and manage, but at scale in a heterogenous environment, containers start to look more like a science project. There is an incredible amount of complexity when building out containers at scale. Integrating with various network, database, and storage components requires a great deal of up-front work. There are a number of third party solutions for container management that strive to greatly streamline and simplify the integration and management of containers. However, the initial effort should not be underestimated.
Containers as a Service (CaaS) is Docker’s answer to the prescriptive challenges of PaaS. CaaS allows you to roll your own PaaS without being as prescriptive. CaaS allows you to abstract the technology components of your choice into containers and integrates all of the containers into a common platform so that developers are shielded from all of the underlying complexity.
In response, traditional PaaS solutions like Pivotal’s Cloud Foundry now allow you to pick and choose what components in the stack you want to manage yourself and which ones you want the PaaS solution to manage. You can make compelling arguments for both approaches. One of the biggest advantages of CaaS over traditional PaaS (Cloud Foundry, Heroku, etc.) is cost. With CaaS, you pay for support and possibly subscription fees for various ecosystem tools. PaaS charges a premium for their services.
Welcome to a World of Serverless
Serverless, or functions as a service (FaaS) totally changes the abstraction game. With serverless, you invoke functions and all of the infrastructure is provided for you on demand. No setting up AMIs, patching, deploying virtual machines, etc. No more large up front enterprise agreements.
FaaS is a simple pay-as-you-go service that requires a minimal amount of administration and management. Serverless is relatively new and immature and has its limitations. Testing can be complex and the tools to help in this area are not yet robust. Serverless is also known to be inefficient with long-running applications.
When it comes to abstraction, there isn’t one solution that will meet all your needs. In large enterprises, there are use cases that justify using IaaS, PaaS, CaaS and serverless. It is prudent to use the right tool for the job instead of picking one and forcing every application or service into a single architecture. The ecosystem around these solutions is maturing quickly. If you are not leveraging CaaS or serverless, we recommend you kick off some proof-of-concepts so you can evaluate the pros and cons of each as they pertain to your environment and your culture.
Keep in mind, each one of these solutions to require a mental change from a development and operations perspective. The more people hang on to the legacy development processes and organizational structures, the less benefits they will reap from these different abstraction solutions. Technology is changing at a rapid pace. A year ago I thought containers were the clear way forward. Then serverless became mainstream. I’m sure the next level of abstraction is right around the corner. The new reality is that the bets placed on technology today have a shorter shelf life than in the past. Don’t architect yourself into a corner that you won’t be able to get out of in the near future. The next big thing is always right around the bend.