No Servers? No Ops? No.
At the end of May we ran the first conference on serverless technologies and architectures in Brooklyn, New York. The conference was hot. We sold out and had around 100 people on the waiting list. I’ll spare you a summary but I think that all attendees and speakers enjoyed the event (all talks will be available online soon on A Cloud Guru).
We also received a lot of positive (and constructive) feedback for which we are grateful. Thank you to all the amazing, interesting, and passionate people who made this conference possible.
Serverless is still something that’s being discussed. The term itself (“serverless”) is ambiguous and has led to many twitter storms before, during, and after our conference. I think that right now it’s necessary to dispel a few rumours. If you feel that I haven’t addressed all of the myths — let me know and I’ll be happy to add to the list below.
Serverless is about AWS Lambda
Absolutely not. First of all, apart from Lambda there are other serverless compute services such as Azure Functions, Google Cloud Functions, Auth0 Webtask, and IBM OpenWhisk. Lambda may offer (IMHO) a more mature solution at the moment but it’s not the only player in town.
Second, serverless is not just about running code in a stateless compute service like Lambda. It’s also about simplifying the entire system and helping developers move faster (this is done by using more third-party services, reducing the amount of backend code and moving more logic in to the front end).
Fundamentally serverless is concerned with:
- streamlining the complexity of traditional systems by abolishing the need to run servers and manage infrastructure.
- helping developers focus on their core problem and reduce the amount of code they need to write.
There are no servers
I hear this a lot: “this serverless thing doesn’t make any sense. There are still servers. You are wrong and you should feel bad”. If I had a dollar every time I heard this I’d probably have around 38 dollars so I do feel bad.
Of course there are servers. In fact these glorious beasts are what makes cloud and serverless possible. If you use a serverless compute service like Lambda, or invoke a third-party API —there’s always a server executing code.
The point of calling something serverless is to say that we no longer need to run, and manage (virtual or physical) servers ourselves. We do not even have access to them. We deploy code that runs in a stateless compute service or invoke a service managed by someone else.
This one makes me a little bit sad. There are people who have proclaimed that serverless means that DevOps/Operations are no longer necessary. You can see where they are coming from — if you embody a purely serverless approach you no longer need to worry about infrastructure, operating systems, network config, server patching, and so on.
But —hold on a minute! You still need to code, build, test, package, release, and monitor your application. There is still a need to consider resiliency, and availability, and instrumentation. Yes, you don’t need to provision, configure, load-balance, and look after machines but it’s not like infrastructure management is the only task that DevOps is concerned with.
Some one needs to be responsible for quality and smooth running of the entire system. It won’t happen by itself. If the engineering team can handle it then that’s great. But there is still a need to address automation, deployment, testing, security, and monitoring — to name a few non-dev tasks. The problem that DevOps is trying to solve is still there… just without the servers.
Please don’t let this myth go unchallenged.
Serverless is a silver bullet
No, it’s not a silver bullet. Serverless solves some problems; it can reduce complexity and make scaling easier for a number of applications. But, it doesn’t solve your business problem. Serverless technologies and architectures offer a possible approach to design and implementation of systems but you still need to do the work.
Serverless has its challenges too. Instead of basking in relative robustness of in-process calls of a monolithic system you have a distributed system to deal with. Then there are these problems:
- Serverless tooling needs to be improved. Thank you to the serverless framework for making the situation more bearable. Back when we started we had to roll our own framework — that was painful.
- Existing serverless compute services have different limitations and constraints.
- More maturation & thinking (in terms of architectures and patterns) still needs to happens.
Serverless technologies and architecture can provide a great approach for your application. Our entire platform is serverless. It supports thousands of simultaneous users streaming videos and interacting in real-time — without breaking a sweat and costing very little. But, serverless could be wrong for your class of application and that’s OK!
Technology is architecture
This is a pretty simple one and is not really a myth. However, I’ve seen people confused by this. Serverless technologies are specific services, such as Lambda, that allow us to execute code without running a server. Serverless technologies can also refer to services such as Firebase (a real-time streaming database service) or Auth0 (managed authentication service) that can enable serverless applications. Serverless architectures are patterns that leverage serverless technologies to build applications.
Have I missed a myth? Is there anything else that needs addressing? Let me know and I’ll gladly add it here.
A Cloud Guru
The mission of A Cloud Guru is to engage individuals in a journey to level-up their cloud computing skills by delivering the world’s leading educational content designed to evolve both mindsets and careers.
Our courses are delivered by industry experts with a shared passion for cloud computing. We strive to serve our growing community of cloud gurus, who generously contribute their insights in our forums, workshops, meet-ups, and conferences.
Keep up with the A Cloud Guru crew @acloudguru.