Serverless is SuperOps
and this could be why there’s an adoption problem
(SuperOps as in “OPS(dev)” not DevOps or #NoOps)
I was reading a post from James Governor (aka monkchips) last week about “Serverless and the death of DevOps” (or not)
It’s worth reading the article (if only because he gently berates swardley for stuff 😉) and if you can get to a CloudCamp then do go as there are awesome people there.
I commented on the article with some thoughts, and have been mulling over my response ever since (people seemed to like it).
So Why is Serverless “SuperOps”?
We have been running a Serverless style solution based on AWS Lambda for almost 2 years. It’s still my preferred way of developing things, and we’re constantly coming up with ways of both refining our approach and also limiting our need for maintenance by utilising Cloud services.
In this way, we’ve really gone “all in” on AWS, and the associated services. This is no bad thing in my book either.
Why?
We’re a startup!
And until we have Product-Market Fit, then I want to limit my exposure to unnecessary maintenance tasks on the tech as much as possible.
And that is where the most interesting observation of the recent months comes in.
Serverless is all about Ops
It’s definitely not #NoOps
I’ve previously said that going Serverless is like doing “Super Advanced Cloud” and it is.
But what I didn’t grasp until now, is how utterly reliant you are on a really good Ops approach
It is DifferentOps
It is also “Someone else’s” Ops
Because you’re main concern is the infrastructure, and how it works, and not the development.
The development is relatively trivial in comparison.
“Death of DevOps” or “Born again OpsDev”?
Over the past few years, I’ve watched the DevOps community with an amount of uncertainty. DevOps is an interesting concept that has made itself into a very valuable term in meetings and teams.
And often Serverless is seen as a way of not having to do Ops hence why the #NoOps idea.
But DevOps has mainly been pushed towards the margins as a concept by Developers and Companies I think (unfortunately). It seems that it’s often an afterthought of the development process.
And as I look at the word “DevOps”, how it’s formed as a word strikes me as important in how the community and practices have grown.
It’s Dev then Ops
In other words, Developers are primary, and Ops is secondary.
Developers rule in DevOps
When Developers say something, then Ops has to deliver it.
I think Serverless shifts this around almost completely.
Because the Dev is genuinely the easy part
And the Dev is reliant on how the Ops is delivered.
Serverless is Ops first by default.
Which is why I call it OpsDev. Although I think OPS(dev) makes more sense, because it shows a clearer priority division, with a big OPS and a much smaller and in brackets (dev)
Ops says: Which cloud? What approach? Which data storage solution? What is the method of interaction with third parties?
These development questions are heavily reliant on the Ops elements of the solution, and the Developers cannot easily dictate prior to actual coding how the system works.
DevOps is Dev then Ops Monolith/Instance/Container
Serverless is SuperOps then (dev)
Adoption of Serverless
When I have a conversation about Serverless with someone who is sceptical about it, most of the time the argument comes from the developer side.
The comments are often that Developers need some sort of abstraction or framework to help them understand how it can be used.
Developers definitely struggle with the switch to Serverless concepts. I think it might be something to do with the need to bring in an Ops perspective to development, when that hasn’t been necessary up until recently.
As a community we’ve given Developers essentially a free rein to do what they want, and “someone” will deploy it and manage it in some form. When you build a container based solution, you pick your way of deploying and go from there.
And when you look at the “frameworks” around Serverless, you see that they are approaching the problem from a Dev point of view, and abstracting away the Ops.
“Abstracting the Ops” … it’s what Developers always try to do.
Because it’s much easier to not have to think about the deployment of a system and it makes the solution “simpler” for them to deliver.
The more you don’t have to think, the easier your job becomes.
Which is why I think we haven’t quite got Serverless frameworks right yet.
In my mind, Serverless is more about fitting Development “Pegs” into the Ops framework’s “Holes”, and not about throwing a Big Ball of Mud at the Ops team and telling them to get on with it.
Which means that the Developer’s role is actually more collaborative with the Infrastructure than it ever used to be.
Note: This isn’t to say that you can’t create a Big Ball of Mud with Serverless concepts, because you most definitely can. But it’s more uncoupled, so it’s probably more like lots of small balls of mud on a cloud framework.
Serverless is SuperOps
In my mind, Serverless is about being Cloud Native in approach, and strategy.
Serverless is also about Developers needing to get to grips with Cloud, and Ops and Infrastructure, where before they didn’t need to worry.
Because when you grasp that Serverless is all about the Ops, then you change your processes and procedures internally to ensure that people are much more aware of the Infrastructure before they develop anything.
Ops becomes your primary task, and Dev becomes a the tool to deliver the custom business logic the system needs.
Serverless is OPS(dev)
SuperOps ftw
