Myles's Blog
Ah, Serverless.
That name of technology which strikes anger into Ops Engineers and ideas of unicorns and fairies to Devs. The very idea of something executing without physical servers is a foreign and absurd concept to many seasoned engineers in both Ops, Dev, and even in Management. To be honest, they are not wrong either. Serverless is currently poorly known but is at least getting better defined which allows architect-level engineering to understand the benefits and drawbacks to the entire continuum of adopting a Serverless-based systems architecture.
So, what even is this thing?
As described and laid out well by Nawaz Dhandala over at cloudboost.io Serverless consists of two main offerings:
Backend-as-a-Service (BaaS):
For those who remember the days of Parse.io, this is similar (and as terrifying to me as that shutdown was for many) and provides direct access from the client to “backend” services like databases, message queues, object storage, etc. This has an incredible amount of interesting use-cases, specifically in the “fully serverless” deployment models where even a FaaS may not be used. However, my personal opinion of giving direct access to clients to any backend resources is a security stance I cannot support. In due time, I hope someone is able to convince me this is acceptable.
Function-as-a-Service (FaaS):
FaaS is the far more interesting aspect of Serverless to me. AWS Lambda was the first large scale and well known offering available in the public cloud space released in November, 2014. FaaS is interesting as, yes, you are beholden to the execution provider, but you are still in control of the functions contents and any parsing, request/response modification, etc.
FaaS and BaaS do not depend on each other but get better in combination.
Okay, it’s cool, but why should I care?
Exactly, it’s just another piece of shiny new unicorn tech to hit the market, right?
Well, maybe.
I believe the move to large scale deployments of microservices we have seen over the last few years coupled with the wide adoption of DevOps oriented practices and Systems Thinking is leading us higher up the abstraction stack.
This might not be a good thing.
But, I disagree. I see these changes and adoptions in software architecture of late as the change we need, but we don’t yet deserve.
Let’s break that down, shall we?
As we have migrated from analog computing (yes, humans) to digital mainframes, the client/server model built around the Internet, and now finally this whole Cloud thing… at every change in computing history we see an explosion of new business models and value unlike ever built before.
I fundamentally believe we will see the same thing with Serverless in the next 5 years.
Specifically, I see Serverless as further decoupling Operations from Development and allowing each of them to move at their own cadence and provide their own Development and/or Operations oriented features and deliverables.
I also believe that far more importantly this will decouple “Business Experiments” and long-term projects. Ideally, this will be used in a Lean Product development and fast-feedback cycle to quickly tailor to the market as explained in The Four Steps to the Epiphany and The Lean Startup
But, what about Containers?
Serverless, like all technology, is simply another tool available to us use as problem solvers. Currently, I see containers assisting serverless just like VMs or bare-metal hosts have in the past for long-lived processes, resource intensive execution, and other technical uses that FaaS or BaaS simply cannot handle at this time. In fact, containers even provide a good method of deploying serverless functions in systems like OpenWhisk and possibly even Lambda in the near future.
As new technology is developed, rarely do we actually see a new “paradigm” fully replace what is currently used and supersede all of the experience earned and lessons learned from the trenches operating something that is often suddenly considered old and boring tech.
Where do we go from here?
Now we get to the fun part! Watching what engineers, architects, and providers are dreaming up and implementing we will continue to see more patterns emerge, understanding develop, and confusion amongst everyone. It isn’t now, nor will it be in the future, the answer to all problems and will actually create plenty of its own.
Again, this is expected.
Now is the time to dive in and get dirty. Things are still greatly in flux, but if you are an early adopter I highly recommend spending some time to learn the space, research others opinions, and see for yourself what is and isn’t possible right now for the problems you solve.
As for me, I’ll be out designing and building interesting architectures on Lambda, Google Cloud Functions, and even Azure Functions to understand the impressive tools we have at our immediate disposal with so little cost.
Oh, and thinking of the waning days of needing to worry about all my own hardware and servers. Now I get to worry about someone else’s! 