Serverless: A Promise Not Yet Fully Delivered

Serverless computing is one of the hottest trends in cloud today. All of the public cloud providers have invested heavily in powerful serverless offerings to their partners and consumers.

The serverless architectural paradigm promises that all compute resource allocation, resource management, high availability and fault tolerance will be handled by the cloud provider on behalf of the technical user. The consumer is not required to provision or scale any of the back-end servers, virtual machines or platform services normally needed to run their code. 

Rather, deployed serverless functions are simply spun up and accessed when they are needed, and all of the infrastructure provisioning is handled by the provider.

This is a compelling proposition.

Moreover, every quarter we see AWS, Azure and Google Cloud enhance and release key features, new offerings and improved documentation for their serverless products that only make the appearance of an entirely serverless architecture ever more enticing.

Let's use Amazon Web Services as just one example. Today a developer can build a simple web application or service in a weekend and deploy it to AWS using Lambda, S3, DynamoDB and API Gateway. Done this way, such an application could be as resilient, scalable and fault-tolerant as the majority of commercial applications we interact with every day. And with the favorable pricing model of serverless computing, this could all be accomplished with an expected hosting cost of a few dollars per month for low-utilization applications.

Given the seemingly obvious benefits to serverless cloud architecture, this raises an important question.

Where's the adoption?

In our experience today, we are not seeing medium-to-large enterprises dropping their existing custom software design paradigms for entirely serverless architectures. Why not?

We know that organizations are willing to make substantial technology pivots. For example, we are seeing a large adoption of other cloud-led technologies, both in the infrastructure-as-code and application orchestration space. So the issue cannot be a generalized fear of cloud migration and enablement or or moving toward cloud-native solutions.

It is important to note that serverless is not being ignored entirely by enterprise consumers, and we would never suggest that serverless is a total bust for business. For example, one would be hard-pressed to identify an AWS enterprise customer who does not use Amazon S3 or at least move some workflows to DynamoDB and AWS Lambda.

We believe enterprise is not going all-in on full serverless due to a mix of a few different independent but equally important factors:

• the availability of robust and powerful commercial off-the-shelf (COTS) applications that integrate poorly with serverless cloud services;
• a relative lack of technical control over both the infrastructure and software components constituting the serverless solution; and
• the steep learning curve facing existing the company's internal IT organization.

Taking these factors into consideration, perhaps it is a good thing that large organizations are not rushing to drop existing patterns to adopt serverless enterprise architectures more widely.

Taking a closer look

Let us dive a bit deeper into each of the three reasons we suggest that serverless has not taken a larger market share of the custom software world.

Availability of COTS products

Despite the increasing prevalence of cloud—or perhaps because of it—the industry is experiencing an ever-growing trend toward running businesses with large, commercial software having broad support and market share. These software suites can run a company's backend system, sales cycle, supply chain and human resources.

While the upfront cost of this software is often high, the risk is low and the features are abundant.

If you will be using such a COTS product, then the software you purchase needs to integrate well with your core applications. Payment of developers for custom software represents an expensive cost center, and efforts toward integration likely offer little to further core business objectives. It would be far better to apply such costs and efforts to areas that can differentiate your company from your competition.

This kind of competitive pressure limits the scope of custom development—and in turn reduces the use of serverless technologies—instead incentivizing the use of more familiar, existing platforms. Many large COTS products can achieve the majority of the integrations for you, after all, and they simply do not yet integrate easily or cleanly with serverless cloud architectures.

Limited technical control

External and commercial applications are not the only concerns. An organization also has to consider how constrained its IT organization will be once inside a serverless architecture.

Imagine that you have an application using a common, traditional architecture with a REST API to insert, retrieve, update and delete data in a database. Assuming a mature internal IT organization, you would generally build the application using your organization's preferred programming language and framework. You likely have a catalog of databases from which to choose, perhaps with a preference towards SQL. 

When it comes time to deploy, you might spin up a server, create the database using infrastructure as code, ship logs to a centralized logging tool, use an API proxy hosted by your centralized IT organization, and so on.

In this scenario, everything you are doing will have been vetted preemptively by your security and infrastructure teams. This application likely will plug automatically into existing systems that can monitor logs and conduct general oversight. These are all large value-adds for an organization.

Now instead, let's say you want to build that same architecture in AWS using only serverless technologies. Every integration will need to be with a Lambda-supported AWS service. If you want to get logs back to your organization's central logging system, for instance, they first must go to AWS CloudWatch, and from there you need to integrate your enterprise tool. The API gateway your organization uses will be unable to trigger Lambda, and so you may have to work with your security team to update policies and procedures.

Depending on your circumstances, all of this adds up to a lot of additional effort for limited benefit.

The need to learn new things

One final factor that we believe is leading to restrained adoption of serverless technology in existing enterprises is a simple one. Effective use of a cloud provider's serverless offerings requires that you be highly knowledgeable in many of that provider's services.

We are talking about a production-worthy level of knowledge. And not only in AWS Lambda—or Azure Functions or Google Cloud Functions—but in all of the other services that will connect into your serverless application's architecture. You must be able to manage these integrations at a high level. You need to follow best practices around deployment automation and infrastructure-as-code or you will quickly find yourself underwater.

You may have an experienced and highly capable IT organization and software development team. They may have been using a framework for years, with deep and intricate knowledge of its workings, its capabilities and its limitations. None of that will help you. Moving to a fully serverless architecture requires that you commit to a cloud provider and know it well enough to gain the desired rewards.

Where does that leave us?

We realize that this article reads as a negative take on serverless, even though serverless is fact is one of our favorite current cloud technology trends. We stand by our assessment at the outset of this article that the promises of serverless architecture are compelling indeed.

Taken holistically, however, the drawbacks of serverless architecture may be amplified more rapidly than the gains in a large enterprise setting. We are seeing startups, smaller organizations and even larger ones who are new to the IT space have more flexibility, with correspondingly wider adoption of serverless paradigms to their advantage.

This is something we hope to see continuing to improve. Fully serverless architectures, once adopted, have amazing potential. If your goal is digital transformation and increasing the pace of innovation, then offloading infrastructure work to a cloud provider while maintaining a low cost is a hard opportunity to ignore.

We know that all of the major cloud providers will continue to invest in serverless, and there is constant innovation happening in this space. For example, over the second half of 2019, AWS introduced improved serverless offerings with better and broader integration capabilities, such as using Fargate over Amazon Elastic Kubernetes Service (EKS). Similarly, Microsoft has made big investments over the last couple years in serverless container capabilities with Azure Container Instances (ACI).

Moving forward, as serverless continues to become more enterprise-ready, we hope to see increased enterprise adoption of these and other services.

No matter the size of your organization, if you want to investigate the areas where serverless cloud computing may provide you with benefits today, our team of multicloud consultants are able to help you. We can help identify the right serverless products to help you move your IT organization toward the future, while also ensuring you remain prepared to integrate and migrate other elements of your enterprise architecture over time.

To start the conversation, contact your WWT account manager directly or reach out to us here.