Every now and then we find a technology that feels like the future, letting you achieve what you want to without getting in the way. Automatic and dual-clutch (semi-automatic) transmissions fall into this category, and some programmers occasionally get the bug from the latest experimental programming language or when rediscovering functional programming.

I'm getting that next-big-thing feeling from Amazon's AWS Lambda service. I've been building enterprise data munging applications in Java and C++ for years and have done the usual little glue scripts in Python, Ruby, Bash, CMD just like most other software developers. As we all know, the code is the fun part that takes very little time compared to the brain-numbing effort of messing around with operating systems, deployment, scaling considerations, TLS (SSL) termination, fiddling with CORS settings etc.

When you move to cloud-rented servers, the configuration only gets worse, as the dev team has to micromanage details traditionally dealt with by operations staff running a data centre. At this level of abstraction you need to cake care of monitoring, availability and fault-tollerance while taking account of how to scale up and down with the load. And you always end up paying to leave at least one idle server sitting there waiting for something to do.

The beauty of Lambda is that it does most of the boring infrastructure stuff for you magically. You don't have to think about how many hosts might be running and how to scale them up and down. You don't have to pay for a running host when the application is sitting idle. You don't even have to fiddle with the half-working settings of a Java Servlvet Container or the massive weight of the Spring framework.

All you have to do with Lambda is write a single-purpose application (currently in Java, Python or NodeJS), deploy it and trigger it to run. It can be given an endpoint with API Gateway or receive notifications from other Amazon services or from any SNS topic. You only pay for executing runtime and reserved memory capacity during execution.

The trade-off is obvious. Sacrifice some flexibility in exchange for a simpler life in which you can spend more of your time working on the code and delivering value. The biggest gain from adopting Lambda is the cost of developers' time. The business saves money by paying developers to think about, design and write code full-time, not spend hours trying to wrap our heads around complex, multi-faceted configuration for a fleet of servers we don't even need half the time. Configuration which inevitably contains faults and goes wrong in production at inconvenient times.

AWS Lambda isn't best suited to monolithic applications. It works best if you build many small, single-purpose applications. This might mean each endpoint of your traditional monolith has a separate codebase, perhaps sharing a small library of common abstractions. The composable, single-purpose model encourages a scripting-like mindset, so complex frameworks become a hindrance. Even a basic CRUD application quickly decomposes into 4 or 5 tiny scripts. The Python and NodeJS support are ideal for supporting this approach, but it's easy enough to extract functionality from existing Java monoliths as well.

In summary, AWS Lambda feels like the future of software development in ways that promising new programming languages don't. It provides a great deal of flexibility within the problem domain while taking away most of the undifferentiated wastes of time in the software development process (internal corporate noise excepted). It encourages keeping delivered software very small and single-purpose, which makes it easy to keep the quality bar fairly high through peer reviews. I'm pretty excited to see how Lambda evolves over the next few years and what the competitors do to up their game.