In a recent survey, Sumo Logic surveyed 1,500 customers who employ cloud services such as Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP). According to the survey, a quarter of the respondents have already deployed Docker containers and nearly as many (23 percent) are employing the AWS Lambda serverless computing framework.
It’s clear: serverless is here to stay. The adoption does come with some needed changes, within both application development and operations. That means serverless is also changing the way we leverage public clouds.
Shift in Thinking
First of all, serverless does not mean without servers. It simply means you use an automation mechanism that allows you to focus on the purpose and build of the application itself. This mechanism insures that you allocate enough servers and storage to support the applications. This strikes me as something that should have been a part of the public clouds from the very beginning.
The reality is that public IaaS clouds, such as AWS, Google Cloud, and Microsoft Azure, treat their cloud resources as a virtual data center. However, instead of buying and installing physical servers in a data center, you can virtually provision compute servers and storage, not to mention other cloud services such as databases, security, governance, and many others.
Truth-be-told, many enterprise IT shops were so happy to get out of the management of physical servers within a data center that many limitations of the existing public IaaS clouds were forgiven. However, now that we’ve lived a few years with public IaaS clouds, developers and CloudOps pros are giving a huge thumbs down to the constant monitoring of servers, provisioned or not, that’s required to support the workloads.
Here are two things that are happening with traditional IaaS that contributes to the problem. First, they over provision the servers needed, and go for a “You can’t have too many resources” model. Or, second, they do not provision enough resources, and instead go for a “Make them ask for more” model. Both are the wrong approaches.
While estimates vary, the provisioning of pubic IaaS cloud resources over what’s actually needed is at almost 40 percent. This means that most enterprises pay over 40 percent more than they should for cloud services. This does not account for the servers that are left in production by mistake, or the cost of applications that fail because not all of the cloud resources needed for that workload have been allocated.
PaaS clouds really were the inspiration for serverless systems, such as AWS Lambda and Microsoft Functions. PaaS, which began life as a service, automatically provisioned the services you needed. It worked behind the scenes, and removed the developers and operations staffers from having to constantly figure that out.
At the core of the IaaS serverless offerings, we have a few common patterns:
- The ability to remove developers from having to allocate the correct amount of resources for the workload, as well as keep up with what’s running, and what resources need to be de-provisioned. You only pay for what you use, when you use it, down to the function that you write within the serverless subsystem.
- The ability to link serverless computing with both net-new and traditional applications. While you can write entire applications using serverless systems, most choose to do tactical things and invoke from the net-new or traditional workloads.
- The ability to have an exact accounting of what resources a workload consumes. In the past, we had to pro-rate and allocate the cost of cloud servers to the departments. Even if departments only used 3 percent of the allocated cloud servers, they may have had to pay 33.33 percent of the bill. Serverless makes cost accounting and chargebacks much more accurate and fair.
- The ability to create workloads that are sets of functions, all with their own automation around resource allocations, costs, and the ability to leverage whatever function is needed to complete its work. This means returning to applications that are a collection of services, thus there needs to be some good design work that goes into function-oriented serverless applications.
For many, these serverless functions are also known as functions as a service, or FaaS. FaaS do not require coding to a certain framework or library. Instead, the functions are built as regular applications, when it comes to language and environment.
Creating a Serverless Strategy
Beyond the implementation of the technology, which will differ from cloud-to-cloud, enterprises need to understand what exactly serverless development means for them.
First, I would not fall for the hype around this technology. While the tech press has some great things to say about serverless technology, it’s really more tactical rather than strategic, in terms of the value that it brings. Thus, while there is some value here, in terms of removing humans from figuring out the number of cloud resources needed, the result is not game-changing, but certainly an improvement.
Second, this is more about net-new and smaller applications, rather than refactoring legacy applications. Just as with containers, we were looking to push everything into them, and found that it’s harder—in some cases, impossible—considering the amount of work that needs to occur. Serverless-based applications are best as purpose-built for serverless, thus net-new applications, and applications with smaller and more tactical purposes will benefit most from serverless technology.
Finally, the lock-in factor raises its ugly head again. Considering that serverless differs from Google, to Microsoft, to AWS, you can count on those platforms building serverless systems that support their customers and cloud. Portability is something that may be difficult to build into serverless-based applications. There are no viable standards, or close coordination between IaaS serverless cloud providers.
So, is serverless changing the cloud? Indeed it is, but not much more than any other cloud technology has in the last few years.
At the end of the day, serverless is about doing something that public clouds should have done from the start. It’s more about evolution than innovation, and sometimes that’s a much more desirable concept to pursue.