Lambda, APIs, microservices - AWS bets on serverless app dev

Phil Wainewright Profile picture for user pwainewright August 24, 2016
What happens to Amazon's $10bn revenues from pay-as-you-go servers if serverless app dev takes hold? With Lambda, AWS bets it can win either way

Computing concept, light source on blue © Frank Rohde -
There's an old adage in the technology industry that you must 'eat your own children' to survive. Today's less gruesome equivalent is the frequent exhortation to 'disrupt yourself before someone else does' — fear of Uberization drives digital innovation.

Even the disruptors have to be wary of future challengers, and constantly test out ways of reinventing themselves before someone else gets there first. So even though Amazon Web Services this year became the fastest technology business to reach $10 billion in annual revenues, the company is already promoting a new way of building computing in the cloud that could cannibalize those revenues.

Today, most Amazon Web Services customers see the cloud infrastructure provider as an on-demand source of virtualized server instances, and it excels at delivering them efficiently and profitably. But in recent months AWS has begun promoting a new way of building applications which eliminates the need for a number of those servers.

Serverless app dev

Instead of having to set up and maintain their own virtual servers, developers use a service called Lambda to call and respond to other services within the AWS infrastructure — or, via the AWS API Gateway, to call or react to external services. In this "serverless" approach to application development, as CTO Werner Vogels told an audience in London last month:

Complete apps are being stripped of all their servers and only code’s being run.

Intrigued by a vision that supplants Amazon's infrastructure-as-a-service origins with a radical, microservices-based platform-as-a-service alternative, I asked EMEA regional technology officer Dob Todorov to elaborate on this new thinking. He told me he sees serverless app dev as an evolution from the historic approach of coding everything from scratch to a more event-driven way of building applications:

If you look at the way we have been building applications for the last 50-60 years, ever since computing came to exist, I think we have always been very focused on the fact that there is a server. Then we write a piece of code, and then we throw that piece of code onto the server, and then it gets executed, and hopefully it all works as it's supposed to work.

Clearly, it's evolved into us running multiple applications at the same time, and multi-tasking was invented, and obviously we ended up clustering systems together. We ended up with parallel computing, and various other technologies as well. In each and every one of these technologies we still have a piece of server, a piece of kit running your code.

While it was very important back in the days to be able to identify the piece of kit, it's less and less important these days. We've got lots of applications which are event-driven in nature. It's far less important that you've got a stream of commands, a piece of code, that you need to execute on a specific server. It's far more important that you focus on how do you react to specific events happening around you?

Lambda's origins

Lambda originated a couple of years ago when AWS started allowing customers to use its own infrastructure to trigger actions rather than have them set up their own mechanism for discovering changes — for example, passing a threshold in processing load or network traffic, noticing a field has been updated in a Dynamo database, or receiving a new file in S3. Todorov explains:

We're in a very good position to actually go and execute that call-back function of yours, and then really spare you all the polling that you would have otherwise been doing anyway.

It made no sense for each customer to have an entire server instance running just to poll for these events — especially if that instance then had to be replicated and managed across multiple availability regions.

Customers were telling us, in order to even run a few lines of code, I still need to bring up an entire operating system, and I need to pay for it all the time. Plus it's probably polling, so it's doing something, I can't shut it down either.

Then I need to patch the operating system, I need to make sure that the implementation is secure. Plus, in order to build a highly available application, we probably need to have such instances for all the different availability regions ...

You, AWS, you're sitting in the middle, it's your platform, and therefore you have visibility into all these events. Perhaps you can do it much more efficiently than us.

General-purpose app dev platform

From those small beginnings, Lambda has evolved into a general-purpose platform for serverless development, says Todorov.

It is through such questions that we have been getting from customers that Lambda was created, and yes, we are going to continue to evolve it. Yes, it's going to become a general purpose platform for server-less code execution.

We're seeing more and more customers today bring not just very simple scripts, not just a couple of lines of code, but entire applications on Lambda.

That's not to say Lambda will support every kind of application — it's architected to process microservices and therefore the amount of data it will handle within a process and the length of time the process will run are both limited. It has limited error-handling capabilities, which means applications require careful scoping and testing. And as it's relatively new, the amount and detail of documentation can be lacking.

It has competition, now, too. Since it first came to market, Microsoft and Google have each brought out similar services — Azure Functions and Google Cloud Functions. There's also an open-source project for those worried about cloud lock-in.

Enterprise use cases

But AWS was first to market, and Todorov cites a wide range of use cases in which enterprises are using Lambda either to manage other AWS services and resources, or to act as the 'glue' between different components of the AWS infrastructure. Amazon would also like to see customers using it to call its newer functions, too, such as its machine learning service or IoT hub.

I think the opportunities for using Lambda are endless. Virtually anything that looks like a piece of code running on a server today, can one day run on Lambda.

Through the mediation of Amazon's API gateway, Lambda can also interact with resources outside of the Amazon infrastructure, including an organization's own in-house computing. This means it can act as the glue between those existing applications and the outside world, says Todorov. The gateway can perform transformation between back-end resources and APIs, or translate between different flavors to expose a single API to other endpoints. It also has the ability to offer different versions to different clients and monitor their usage. This is all based on the experience AWS has garnered from providing services over the past decade, he says.

[This] functionality all comes on the back of us running API-capable infrastructure at scale for the last ten years, and even more internally. We're making it available for customers to use.

Lambda provides a fertile ground for testing out new ideas, he suggests:

If you have a team that has an idea, Lambda is the ideal platform which will allow them to simply script the structure of that idea, and be able to experiment, without necessarily spending months in planning all the different components. When it comes to experimentation, Lambda is such a very powerful tool in the hands of data driven organizations.

Opportunity for all

Stripping out servers is just the latest evolution of Amazon's mission with AWS, he adds, and as such Lambda also becomes a great leveler of opportunity:

It is really a question of abstracting away from the physical. To a large extent, given the scale, and given the innovation that we're providing as well, it is a question of abstracting away from your financial capabilities as well.

As long as you can be creative, as long as you are brave, you've got at your fingertips technologies that, back in the days, only the biggest ones could afford. Which is very disruptive to businesses that are large, international enterprises.

Nevertheless, AWS wants to see established enterprises build serverless apps on Lambda too.

It's a brave new world out there for everyone to innovate. The majority of our large enterprise customers, you are probably going to find that they run hybrid types of models. They have to bridge between the small, individual newly created workloads, and all the legacy applications as well. Obviously it's going to take some time.

They are not all in the cloud, they are running specific applications on AWS, and moving even more applications, and becoming very brave in terms of what they run on AWS. Which is great, because AWS is a platform ready for mission critical, it's waiting for them to come to us.

My take

I have always been predisposed to favor services over servers, so perhaps I'm biased. But It seems to me that the way this new concept of serverless computing is evolving is similar to how cloud computing first emerged. It's only for early adopters, it's poorly documented and in several respects not fully enterprise-ready. It's accepted by small businesses, startups and for dev & test in large businesses, but no one is considering it for anything mission-critical.

In other words, it's a classic disruptive technology — and in a few years' time it will have shed all its shortcomings and become an accepted part of the enterprise IT landscape.

A grey colored placeholder image