The AWS architect and Developer Day recently came to town, and I was lucky enough to attend. The conference was timed well, as we had just completed a migration from on-premise web infrastructure to AWS, and this was the perfect opportunity to see what next steps to take into the cloud. And if AWS has anything to say about it, those next steps are in the form of microservices.
I can appreciate why AWS is pushing so hard for the adoption of microservices. If you decompose any traditional enterprise software solution, you’ll no doubt see a lot of recurring themes: user management, persistent storage, messaging, security, search, and logging are just a few cross-cutting concerns that come to mind.
None of these ideas are new, and all have a decent level of support in any modern software stack. But it is one thing to have support for these cross-cutting concerns and quite another to be able to spin up a supporting highly available and scalable infrastructure in a matter of minutes. JPA gives you a power ORM, but it doesn’t give you a database. SLF4J gives you a great deal of flexibility when it comes to what and how you generate logs, but it doesn’t give you a service to store, search and report on them. Servlet security can lock down access to your webpages, but it doesn’t give you a user database or social logins.
AWS believes that traditional enterprise software needs to focus less on reimplementing these commodity services and focus more on writing code that combines services provided by AWS in ways that add value for your customers.
Still, this idea of outsourcing commodity services to cloud providers is not new. What was new was the way that these services are combined. If this conference was any indication, the future of enterprise applications development is in Lambdas.
I have some mixed feelings about Lambdas.
On one hand, discreet units of stateless and versioned code have a lot of benefits. In theory, Lambdas are easy to test and, by their very nature, lend themselves to creating microservices. If microservices are the future, exposing Lambdas behind API Gateways, securing access with Cognito, persisting data to DynamoDB tables, monitoring with Cloud Watch, and logging to Elasticsearch seems like a natural progression.
But there are some significant downsides to Lambdas.
I fear that a lack of tooling and best practices would make a pool of Lambdas difficult to manage. Werner Vogels (AWS CTO) was quite candid in the Q&A session about wanting feedback from customers because AWS doesn’t actually know how people will use Lambdas in the real world. This is a service that was made available locally only a few months ago, so there are not a lot of large-scale, battle-tested implementations out there.
Meanwhile, Lambdas, and the microservices they lend themselves to, are no free lunch. This post in hacker news is a wake-up call to anyone looking to embrace microservices, and right now, simply writing Lambdas doesn’t automatically provide you with all the supporting engineering practices that are required to make them work at scale. If you find deploying a handful of more monolithic applications a pain, imagine how much worse it is deploying individual functions.
Overall, though, the information provided during the sessions was excellent. The architectural ideas and practical advice were enlightening, even outside of code running on AWS. It is fascinating to hear how AWS envisages the future of software development, and I suspect one day, I’ll look back to events like this as the foundation for production systems running 20 or 30 years from now. I may not quite be able to wrap my head around some of the practicalities just yet, but I expect Amazon will have those sorted out in the not too distant future.