James Governor's Monkchips

AWS Lambda: driven by the laggards.

Share via Twitter Share via Facebook Share via Linkedin Share via Reddit

I had a fascinating call with Stackery recently. The founding team of seasoned New Relic alumni is building an ops console for serverless development. One reason I found the call so interesting was that Stackery helped crystallise some thoughts about the rapid enterprise adoption of serverless with a somewhat contrarian argument. Sure there are plenty of the cool kids using Amazon Web Services (AWS) Lambda, but the rate of adoption by mainstream, mainstreet enterprises has been surprising.

So what is going on? The need for greater software development velocity is having an impact on people, process and tools, with a need for greater infrastructure disposability to support CI/CD, and microservices-style development. Today there are a couple of primary approaches to (ephemeral) compute as a managed service – containers or serverless.

Containers can help with IT cost reduction, but the main driver of adoption is velocity and the efficient management of infrastructure. The problem with container infrastructures is that this efficient management also calls for highly skilled developers and operators. Talent is a scarce resource. Even if you can afford the people, they may prefer to work for cooler companies.

So serverless emerged, which also enables greater development velocity, without the need to hire a crack team of Go engineers to manage the infrastructure. Serverless is the new PaaS.

And so, as Stackery sees it:

The serverless landscape is being driven by tech laggards. If IT is really seen as critical you probably have a devops team, agile, nuanced and specialised for running container infrastructures. but for most of the market infrastructure is a commodity. You have so much control, there are some advantages to containers.

But serverless is being driven by mainstream enterprises. We see them leapfrogging containers so they can take something off the shelf and move quickly.

That said, the tradeoff there however is that serverless is essentially a black box – you can’t just SSH in – so while with AWS Lambda you gain development velocity, you lose visibility. That’s the problem space Stackery is focusing on – audit and control of resources, to allow for consistency and reliability in development and deployment of Lambda-based apps, for example by automatically configuring AWS CloudWatch and generating an architecture diagram of the stack. Rather than having one or two people whose job it is to set up Cloudwatch and notifications.

I asked whether it made sense for a startup to be building extensions to Lambda, given AWS was likely to build its own into the core product. Stackery is betting that it can continue to move up the stack as AWS does so, and that AWS will leave some headroom for partners in workflow, and automation of best practices for deployment and management.

In any tech wave the best packager wins, and wins big. AWS has taken many of the core patterns being established by the leading edge containery folks and made them accessible for the mainstream with Lambda. We’re going to see both serverless and container-based computing establish solid markets. We’ll also see convergence – for example with serverless implementations running on containers (OpenFaaS, OpenWhisk, Kubeless, Fn, Riff etc), and then the new serverless/managed infrastructure tools such as AWS Fargate and Azure Container Instances.

When the real shortage is in skills, and “laggards” want to move quickly to new ways of working and developing software, then yes Lambda is going to win, and it’s going to be an ecosystem, not an AWS only play. That’s why there is a market for plays like Serverless or Stackery. We’ve been through this before – when Microsoft was in its pomp you could have argued it made no sense to develop infrastructure products for Windows. But a lot of companies successfully did – anyone remember VMware and Citrix? Serverless is not an Amazon only phenomenon, though it’s the clear market leader obviously. Azure Functions is also seeing adoption, and Google Cloud Functions should start to see some enterprise adoption once the product hit general availability (GA).

 

related:

Serverless and the the death of devops. Can you not?

The serverless economy – why you should care about serverless

Why Serverless, Inc is crushing it right now

Serverless is the New PaaS

Serverless: Redefining DevOps

 

disclosure statement: AWS, Bitnami, Google Cloud Platform, IBM, Oracle, Microsoft and VMware are all RedMonk clients.

 

2 comments

  1. I remain unconvinced that FaaS adoption reduces operational costs. For one it is not suited to all the workloads you would see on an enterprise shop, therefore it adds to existing complexity rather than being a replacement.

    Second, debugging of eventual problems is arguably worse, with large portions of context and system state often gone by the time anyone gets to it.

Leave a Reply

Your email address will not be published. Required fields are marked *