What’s the friction with Serverless?
Three pain points of serverless adoption from The Agile Monkeys
The team at The Agile Monkeys has worked on non-trivial applications with a wide range of technologies for more than a decade — mainly in the retail sector on solutions from e-commerce management to warehouse automation and everything in between. Our engineers are very aware of the enormous challenges of scalability, reliability, and codebase management that many companies face when developing business solutions.
Based on our experience, we’re convinced that serverless is the execution paradigm of the future that solves many challenges of modern application development. But we still see friction in the currently available abstractions — and available tooling still makes it hard to take advantage of the true potential of Serverless.
In the past decade, most successful retail companies opted for using pre-built monolithic e-commerce platforms that they customized for their needs. But with the growth of their user base, those platforms can no longer manage peak load (like Black Friday) anymore.
As a result, we’ve repeatedly been involved in “brain-surgery projects” to split their big monolithic codebases into microservices over the past few years. But the architecture change came with new challenges: handling synchronization and communication between services efficiently, and a huge increase in operational complexity.
We started researching Serverless as a potential solution for those challenges two years ago and we saw its tremendous possibilities.
Serverless not only removes most of the operational complexity but, thanks to the many hosted service offerings, it allows us to deprecate part of the glue code required to deal with coordinating services. And for companies that are already selling, it can be smoothly introduced when implementing new features or when a redesign of a service is needed, without affecting the original codebase.
It’s very easy to deploy a lambda function and implement basic use cases, going beyond that requires a lot of knowledge about the cloud service offerings.
But while Serverless is evolving very quickly, it’s still a relatively new idea. Many VPs and Senior Engineers are still hesitant to introduce it into their production systems because of the mindset change and the training it would require for teams that are already working as well-oiled machines.
While it’s very easy to deploy a lambda function and implement basic use cases with the existing tools, going beyond the basics requires a lot of knowledge about the cloud, managed service offerings, and their guarantees and limitations.
Faster time to market?
It’s a common mantra in Serverless forums to say that Serverless means “faster time to market,” and we’ve found this can be true for well-trained teams. However, teams that are just starting the journey may not find it to be the case, and can easily become frustrated and end up dropping Serverless in favor of better-known tools.
Both from our experiences with clients adopting (or rejecting) Serverless, and our own experience releasing applications like Made for Serverless ourselves, we’ve found the following three pain points along the way:
Pain Point #1: Engineers starting with Serverless might need more time than you’d expect to be productive.
It requires a paradigm shift. You have to switch to “the Serverless way,” start thinking in a more event-driven way, and resist the temptation to build the same kind of backend code you always have but deploy it on lambda.
Serverless is still in a relatively early stage, so we don’t have well-known and established application-level design patterns in the same way that we have MVC for classic database-driven applications.
For instance, if you google “CQRS in AWS” you’ll find half a dozen articles with half a dozen different designs, all of them valid under certain circumstances and offering different guarantees.
As tools are under heavy development, new utilities that look amazing in demos and getting-started guides may have more bugs and hidden limitations than we’d like to admit, requiring some trial, error, and troubleshooting (oh! the price of being on the cutting edge of technology).
Pain Point #2: You definitely need cloud knowledge to succeed.
The existing frameworks provide handy abstractions to significantly reduce the configuration burden, but you still have to know what you’re doing and understand the basics of roles, managed cloud services, and lambdas in order to build anything non-trivial. You need to pick the right services and configure them properly, which requires a lot of knowledge beyond lambda functions.
We see a trend on current frameworks for serverless where they’re providing higher-level abstractions and building blocks. But, when it’s time to build an application, we miss an experience like Ruby on Rails or Spring Boot, which help developers write business logic and provide some basic structure to their programs.
Existing tools are optimizing the process of configuring the cloud, but a team can’t safely ignore that to fully focus on modeling their domain.
Is a sense, we’re still at a point where the tools are optimizing the process of configuring the cloud (and they’re doing great work there!), but we haven’t yet reached the point where a team can safely forget about that and focus on modeling their domain.
Pain Point #3: Functions are actually a pretty low-level abstraction.
I know this might be a hot take, but for us, functions are a very low-level abstraction that might make it challenging to properly architect your project as your services grow.
When you’re starting with Serverless, the idea of splitting your code into small, manageable functions is compelling. But since there are no clear guides on properly architecting the code in a lambda function, we rely on engineers to manage this every time.
And while more experienced engineers will figure out solutions, less experienced ones might find this difficult. In any case, moving from one project to another will require reinventing the wheel, because there are no well-established conventions.
Identifying the challenges is just the first step to improvement. We strongly believe in a Serverless future where everyone is using this technology, because it’s what makes sense from a business perspective (companies need to focus on what makes them special and externalize everything else).
So what do we think is needed to get to that point?
Our innovation team has been working on some ideas that they shared in Serverlessconf NYC. Read our follow-up article about designing a more approachable serverless experience to learn more about Booster, our boldest project to date!
This is a guest article written by The Agile Monkeys’ innovation team: Javier Toledo, Álvaro López Espinosa and Nick Tchayka, with reviews, ideas and contributions from many other people in our company. Thank you, folks!
