The Serverless Framework Landscape
Approaches, considerations, and the state of affairs in 2018
We’re just over half way through the year, but I feel it’s a fair time to reflect on the serverless space. I will also make some predictions.
I’ve been researching and using serverless in production since AWS Lambda was announced. I follow many frameworks out there. My work has also included personal research and development of an application framework called Aegis.
So where are we at with the frameworks? I’m an advocate for many projects. I believe everyone is doing something very important — there’s a huge change occurring in the industry right now.
The Number of Serverless Frameworks
It’s been increasing. I think one of the first (April 2015?), and most well known, is Serverless. Another early one was Apex (December 2015?). If you were into Go then you may have heard of Sparta (October 2015?). In fact, Tim Wagner told me about some collaboration with Sparta’s Matt Weagle for Go in AWS Lambda. Clearly AWS was working with the community from very early on. Another early framework was Gordon; also started in 2015. I consider these some of the earliest contributors to the movement that also had big impact.
Sorry if I left anyone out. Of course there are others. I could rattle off a list, or simply link a few “awesome” repositories that have tons of resources. Here’s one. Here’s another about Serverless framework specifically and another specific to Golang that I maintain.
By the following year, 2016, the number of frameworks certainly more than doubled. ClaudiaJS, Chalice, and Zappa were quick out of the gate that year following on the heels of 2015’s frameworks.
By this point I had been using Apex, Serverless, and tinkered with Sparta and some others. I think TJ Holowaychuk’s work with Apex spoke to me the most then. However, I wasn’t finding exactly what I was after so I created Aegis toward the end of 2016. This was before official Golang support so there were inherit bugs and inconsistencies when using shims (all fixed with official Go support).
Today, I now count at least 20 different serverless frameworks.
For more usage statistics, Serverless released an article recently that has some in depth metrics based on their observations.
So why use a framework? The biggest reason, in my mind, is convention. You want to work with others and follow a certain paradigm. You also want to ship applications faster.
The Considerations of Serverless Frameworks
There is a lot to consider. It’s no surprise there’s so many frameworks. What exactly are they trying to solve though?
For many of these frameworks, a big consideration is language support. Everyone wants a serverless framework in the language they feel most comfortable with and this is one way to get just that.
Cloud providers are doing a fair job of supporting more languages. Amazon is in the lead, Microsoft supports some that others don’t (like F#, C#, and PHP). Google Cloud Functions surprise me. There’s a hack to run Go binaries, but why they aren’t officially supporting the language? Bonkers to me.
The most universally supported language is Node.js.
At this point you can write serverless functions in Java, C#, Python, Go, PHP, Rust, Swift, and more. It’s just a matter of finding the right framework and/or cloud provider.
Infrastructure Management
Perhaps the biggest concern for the majority of frameworks is infrastructure management. Many frameworks could care less about your code. Their goal is remove the complexities of infrastructure. A favorite passage comes to mind:
No slave in the Roman galleys could have toiled so frightfully and lived, for this man thought himself a free man, and that he was working for his wife and babes. — Hamlin Garland
Right? We go on about how much easier it is without servers and start coining phrases like NoOps…Yet, ironically, it’s not so simple. We need these frameworks and tools to help configure, deploy, and maintain the stack.
I think Terraform is perhaps the leader in the infrastructure management. Certainly at least when it comes to supporting multiple cloud providers.
The infrastructure as code movement has been well adopted by people in the serverless space. In fact, I think the newer framework, Pulumi got a lot of things right when it decided to leverage Terraform.
Of course for AWS, there CloudFormation. Many frameworks, like Serverless, leverage that too. Others have taken to SDKs. Then Amazon spotted this growing concern and gave us SAM.
Clearly, we’re still searching for something here.
I’m not sure anyone has cracked the code yet. I think it boils down to the approach you’re most comfortable with. That varies a great deal depending on your role.
A few frameworks, like Pulumi and Sparta, are taking a different approach to infrastructure. They use application code to provision and manage infrastructure. Sparta is about “self deploying” applications and I think Pulumi may not be far behind in this concept as well.
I do think self deploying, self updating, serverless apps are important. Great opportunities exist for licensed apps that run in the cloud based off this idea.
The Divide Between Application & Infrastructure
Or is it a blend? Again, frameworks like Pulumi and Sparta are designed to allow the application provision infrastructure itself.
So what does your serverless application look like? Should it define the infrastructure it needs? Or do you consider that a separate concern?
I think, in 2018, we’re beginning to test this marriage of infrastructure and application through code.
I think that’s where we’re at. People are going to weigh in with their opinions and I think the masses will give us an answer. Perhaps even before the year is through. It could be a divided opinion, or preference, too and that’s perfectly fine and healthy.
Where does this leave the application developer?
For starters, it’s a lot easier for them to manage infrastructure. Whether it’s through their code or through configuration files, there’s an abundance of tooling now.
However, what I see lacking in the serverless landscape right now is a focus on the application development. It’s all about infrastructure management, monitoring, and debugging.
That’s part of why I created Aegis. I wanted to consider the application architecture and make the actual coding of serverless functions faster (well, at least if you’re using Go and AWS).
A History of Web Application Frameworks
I have a long history with RAD, or rapid application development, frameworks. I started with CakePHP in alpha (2005), quickly followed the Li3 (Lithium) gang, then went on to be exposed to and used several other frameworks since. A lot of this history is steeped in the convention over configuration movement and Ruby on Rails.
Honestly, that’s almost as far back as web application frameworks go (not forgetting about ColdFusion). There were various projects that helped you out before the whole RoR stuff…But that was a big change in the industry. Just like right now.
Simultaneously, Flash/ActionScript was in hyper growth. It slowed JavaScript progress for a few years. That made it all the more easy for these MVC frameworks to handle the “view” aspect of things.
Every language then jumped on that bandwagon. From Django to Grails (formerly Groovy on Rails) to Sails (much later on). It was ORM, MVC, “monolith” nirvana. You could use practically any database you wanted right out of the box. There was support for everything; if there wasn’t, it was often considered a “bad” framework.
Though Sails was among one of the only such frameworks for Node.js, something started to change by then. Before serverless, people were fearing the monolith. So package managers became more important; Composer, NPM, Ruby Gems, Bower, and so on. SVN and submodules were out. Git was in. We began to break things apart.
About the time Node.js came around (2009, 2010), many frameworks started to take a more minimalist approach.
As the years went on and the rise of SPAs (single page applications) became evident, more backend frameworks slimmed down and changed their approach. Everything was mainly API focused. A separation of frontend and backend code. It was a change from rendering HTML and serving JavaScript from the web server. In fact, S3/CloudFront was foreshadowing the serverless movement at this time.
Around 2012, the monolith began to fall out of favor.
JavaScript frameworks were here to stay and sprinkles of jQuery on various pages was out. AngularJS (2010) led the charge, but here we are now with Vue.js and React.js among others. We realized we didn’t need to configure and load balance a web server for the frontend. Then the Heroku era pondered, was it required for the backend?
Tying it all Together
So how would you tie all these things together in the serverless era? The “frontend” isn’t really just about JavaScript. Think about IoT and mobile. Of course it may not even be a user or device’s interaction with the backend at all. There can be many “actors” in the cloud.
It boils down to events. Events are the messages that act as the glue between the frontend, backend, our IoT devices, automated processes, and more.
There’s no shortage of clever names in technology so we have projects like Gloo that take aim at this consideration.
Serverless again pushes forward with research here too in their Event Gateway.
I think technologies like Envoy are going to become increasingly important here. Though many of us won’t realize it because only few will need to work at that level. The idea of being “cloud native” is taking off and as such we have organizations like the Cloud Native Computing Foundation.
These kind of committees remind me of PHP-FIG; it’s a sign of maturity.
The CNCF is helping to draft some specs and put some definition around cloud events as well.
More and more I see serverless finding its spot in this cloud ecosystem. I’m aware of the debate between serverless and containers, but I don’t see these technologies as competing at all. I see them as complimentary and I see everything being tied together.
The Future
So we now have this third type of framework for infrastructure.
Yes, Salt, Chef, Ansible, Puppet, and others existed well before serverless, but I feel that configuration and infrastructure frameworks are broadening their audience now.
I was recently asked by both Austen Collins and Ganesh RK of Serverless where I thought serverless was going. I mostly agreed with them about “events,” but to each of them I also said there’s a lot of maturation, growth, and adoption ahead of us still.
I promised my prediction and here it is summed up: Convention over configuration.
Eventually, the configuration gets so complex and detailed that it stands out as an issue. I’ve seen configuration files that end up being longer than code in some cases. That’s a problem.
Anything is well organized if you’re the only one using it.
The challenge is in how we communicate and work with one another. Same goes for services. The more services needing to “talk” to each other, the more complex and disorganized things get.
I believe that these experiments in using code to define and provision infrastructure needed will be critical in guiding the future.
Think about those RAD frameworks — they took years of fragmented pieces of code and helped bring convention and speed to the table.
I believe convention over configuration, along with some other themes, has a bigger role to play here too.
The things I’m looking for in the future:
- A reduction of lengthy, over engineered, static configuration
- Code to provision infrastructure (perhaps even some clever introspection, generators, scaffolding)
- Self deploying and updating functions
- Self managed/healing functions (automatic rollbacks, circuit breakers)
- A potential move away from all the CLI “deploy” commands and change in toolchains
- Conventions in messaging and “events”
This is the dawn of a new era. There will always be variations in features and approaches, but I think the future does hold some sort of consensus or pattern that stands out the most. History has a way of repeating itself.
