Cloud Native Computing

A New Way to Build

First Salesforce revolutionized IT with SaaS, then other service platforms extended those ideas for the full stack. Cloud Native Development is here to stay.

The Dawn of Time

Eons ago, people developed enterprise software as standalone packages that were delivered to companies who then painstakingly installed and updated them. Often installation or upgrade projects could take over a year to complete. The software ran on servers that cost hundreds of thousands of dollars and were physically located at the company's headquarters. To the younger readers, I know this is sounding like some sort of nightmarish hellscape, but I promise that it really happened.

Software as a Service

In 1999 at the beginning of recorded history, a man named Marc Benioff founded a company called Salesforce that saw a better way forward. The goal was to provide a better experience and value to their consumers — enter the software as a service model (SaaS). SaaS aimed to improve on enterprise software delivery in a few key areas.

First, it decided on a subscription pricing structure so that customers were only paying for the features they were using. It also lowered the barrier to adoption and let users land on a platform for lower cost. The idea was that after the users landed, the quality of the product and the variety of features would incentivize them to increase their usage and feature adoption on a higher subscription tier.

Second, the SaaS movement wanted to kill enterprise software costs, both monetary and temporal. It kills the cost of buying expensive hardware by distributing that cost across all users of the service, lowers the cost on a per-user basis since hardware is cheaper to buy directly in bulk, and kills the time of installing and upgrading the software since the service is always up to date.

SaaS delivered on its goals and revolutionized the tech industry. It put the focus on better user experiences and showed that subscription models are the gold standard for consumer adoption. It accelerated the pace of technological innovation in the industry and for the average consumer. Although looking back today, some of the concerns that SaaS addressed became obsolete: hardware became cheaper by orders of magnitude and software installation became substantially easier. Enter the infrastructure as a service model (IaaS).

IaaS, PaaS, CaaS, and FaaS

It doesn't take great mental leaps to come to the next logical step to the SaaS model. With the simplicity of software installation and upgrades and the reduction in hardware costs, it only makes sense to create business-to-business services that take advantage of those new realities, offering cheap reliable infrastructure to any size business.

The goal of infrastructure as a service is to abstract the server infrastructure layers of virtualization, networking, and storage. This allows developers and ops engineers to spend less time dealing with the implementation of infrastructure and more time defining and fine-tuning what infrastructure their company needs. It also comes with more self-servicing and scaling options that take the manual tasks of resource provisioning and put them squarely in the hands of the provider. This is attractive on its own, but IaaS also gets the benefits of economies of scale and multi-tenancy. The provider can build thousands of virtualized computers and networks far more quickly and efficiently than a thousand businesses could build their own.

Over time IaaS has evolved into a more complete set of services that can be categorized but largely fall under the same umbrella as IaaS and SaaS. Platform as a service (PaaS), containers as a service (CaaS), and functions as a service (FaaS) are all new combinations of infrastructure and software services.

The next service to appear chronologically, PaaS services, sometimes called application platforms, aim to split the difference between IaaS and SaaS and focus on application deployment. The first PaaS services let developers think of their infrastructure in terms of their applications and allowed them to provision resources based on what their application was. This took a lot of the emphasis off of needing specialized systems administrators and developers and started fledgling movements like agile development, full stack engineering, and DevOps. Moving on, we now have services that split the difference between PaaS and IaaS and the difference between PaaS and SaaS.

CaaS falls between IaaS and PaaS as an automation layer slightly above IaaS but below the abstraction of PaaS. The process of containerization allows different applications, services, and software to be bundled into redistributable, platform independent, self-contained packages. Once an application is containerized, a CaaS service can help orchestrate the deployment of the application including the previously laborious tasks like load balancing, service replication, and rolling deployments. Another benefit of CaaS is that unlike PaaS, the types of applications and services that you can deploy as a container are unlimited. Where PaaS services required the existence of a typical web application or a complete piece of software, CaaS allows anything that you could do on a VM plus the reliability, speed, and repeatability of containers.

The newest of the whole group is FaaS, also known as serverless computing. These services are similar to PaaS, but they also offer simpler language frameworks to work with. The goal of FaaS is to provide developers with simple ways to handle events and trigger actions. It's simplistic and unfair to the power of FaaS to describe them like this, but I find it easy to think of them as event-driven cron jobs on steroids with an API. The other reason it helps me to think about FaaS this way is that it isn't suitable for every situation, just like cron jobs. Because of the high level of abstraction, it's likely that FaaS will be used in conjunction with CaaS or IaaS which can provide the lower level foundation and flexibility that FaaS lacks.

If the best parts of all of these services are still considered best practices where is there left to go? At first glance, it seems that the whole stack of hardware, software, and client interaction is optimized. Besides my general philosophy that nothing is perfect and everything can be improved, there is a critical part of any software's lifecycle that's conspicuously missing — development.

The Cloud Native Movement

If we look at all of the services, it's easy to see that there's been two major driving forces: development velocity and automated operational expertise. If we look at that more closely, we see the same two goals that have been around in every industry since the dawn of time: speed and reliability. No matter if you're a car mechanic or a developer, a chef or a surgeon, you want the job to be done fast and well every time like clockwork. This is where cloud-native development comes in.

Cloud native development is a movement to take advantage of the strengths of all of these different cloud-based service platforms to increase development velocity and produce consistent operational results. This is easier said than done though. We found three areas that gave the most return on investment and drastically shifted our company's mindset to the cloud-native approach: teams, culture, and technology.

Building the Right Team

The first and most important part of our transition to a microservice based, cloud-native development process was to build expertise. This can be done in a variety of ways. If possible, you could hire new people with the existing skill set you're looking for. You could also bring an expert in to consult on the transition projects or send your developers to conferences or training seminars. If you're like us though and only have a few developers and a limited budget, you can simply make it a priority for your existing team to spend the time to learn new skills.

In the modern age as knowledge workers, having the opportunity to learn new skills and keep growing as individuals is a big part of our job descriptions. If you take this approach though, I found it was important to set aside actual work hours to allow people to do their research. It can become more of a demand than an opportunity if the developers are required to take on extra work beyond their already stacked workload. We set aside a few hours at the beginning and end of each week to research and share our new ideas and skills with the team.

Getting Into the Right Frame of Mind

The second most important adjustment that most teams will have to make is a cultural one. I've been in plenty of places and heard plenty of stories of companies that have an adversarial relationship between the developers and the operations admins. In days gone by, the developers didn't really need to know how the application was deployed, how its performance was monitored, or what infrastructure it lived on. Likewise, the system admins didn't need to know how an application worked, what it was used for, or what it was coded in.

In today's cloud-native world, it's more important than ever to break down these barriers. The implementation and automation of cloud-native development require constant communication and collaboration between the developers and operations experts in order to function. It's easy to see that the culture around the DevOps connection point is crucial to maintaining the velocity and simplicity achieved by our efforts. For our company, this was mostly a non-issue. Right now, our shop is too small for there to ever have been a divide like this. We're all full-stack engineers who do the development and operations, and the transition to this culture was as simple as our collective decision to want to simplify and automate our jobs.

Picking the Right Tech

Many companies start large process changes by picking new technologies then building teams and cultures around that. I think this is completely backward from what it should be. First and foremost, how can we make the best decisions about technology if our team aren't experts? Some might argue that consultants or outside experts could be used for making recommendations like this. To that, I'd argue that we don't always have the time or money for external consultants. More importantly, shouldn't our team that knows the business and its needs, isn't trying to sell us something, and will have to work with the technology for years be the people who choose the new direction? For that matter, cloud-native development espouses the interoperability and flexibility of technology. It might not even be too far to say that the core ethos of cloud-native development is maintaining our ability to move from one technology to another easily and efficiently. When we look at the process of choosing which technology to use through that lens, we see that our the choices are transient and the core foundation of our company is the people and the culture. So pick whatever tech your new experts want to use and keep the culture of cloud-native exciting and alive in your company.

Going Beyond

Now that you know all about cloud-native development, I'm sure you're itching to try it out for your team. I can only say that we saw immediate benefits and couldn't think of going back to how it was before. The attitude shift is palpable across the company as well. The speed and ease that we bring new features to market shocks our business development group. It used to be us keeping up with what they sold to clients, and now it's them keeping up with their imagination and creativity. I'm excited to see what the future brings in terms of cloud technology solutions because I know our team is perfectly positioned to take advantage of them.