A little over a month ago, Jeremy Daly introduced the concept of the #serverless bubble coming out of #ServerlessNYC. In his tweet he said “if you’re in it, a serverless solution seems intuitive. If you’re not, the paradigm shift can seem overwhelming (& unapproachable).”

Tom McLaughlin at ServerlessOps then went on to explore this concept further and shared a twitter thread by Gal Bashan of Epsagon in his weekly Cold Start.

Intersection of DevOps and Serverless - Does it Make Sense?

Gal started by saying the trigger for the thread was at a talk he gave at DevOpsDays Edinburgh, he was with around 200 people who really care about DevOps culture and practices yet so little of them have any experience with serverless tech…and this “blew his mind”.

He said that when they hold serverless conferences most of the attendees are already sold on serverless - thus the bubble - those who have bought in fail to see what’s going on outside of it, yet people who embrace the DevOps culture can be the greatest advocates for serverless - there is a cultural fit with the shared responsibility model and you can’t get any leaner than serverless. So why the disconnect?

We see DevOps as a movement, a culture shift that some organizations have embraced and others haven’t, while serverless is a technology. From an adoption perspective, we view Serverless as a Spectrum… 

Serverless is more than FaaS — it is a spectrum — with every AWS service falling somewhere on that spectrum.

where some organizations have embraced it and others are either deploying varying degrees of cloud technologies or not at all, yet.

Ben Kehoe started this conversation in The Serverless Spectrum (blog at A Cloud Guru). It's a great read on why.

We also saw a great slide presented recently by AWS at re:Invent talking about Serverless as an Operational Construct.

Serverless is a Construct slide taken from AWS re:Invent presentation.

Where a company may fall on the spectrum - or the construct - depends on where they have come from and where they are going. Large organizations with lots of legacy technology may take longer to optimize for serverless than a small, lean startup getting to market quickly.

Intersection of Culture and Technology: A Shared Responsibility Model

There is some intersection of those organizations that have embraced the culture of DevOps and serverless as a technology, but it’s probably hard to identify the drivers that made it occur, or more importantly predict where it is yet to occur. Yet, to truly leverage and benefit from serverless technology we believe and agree with a New Stack statement that DevOps is “increasingly seen as the essential framework on which to build cloud native applications and architectures”.

So what is a key driver whereby serverless will encourage an even greater practice of DevOps? Shared responsibility for cloud cost management. We have seen an interesting phenomenon when talking to financial managers - outside of the development or operations environments. They are desperately seeking to better understand - in real time - the true cost of their cloud deployments, because they are being held accountable but do not have control of what they need to manage. Often times, DevOps can’t answer the questions they are asked, nor can they understand the implications of their actions on cost because they don’t have the right cloud cost management solution.

Will Finance Be The Driver that Brings Serverless and DevOps Together?

We predict that the time is coming where companies will no longer be moving to cloud native and serverless just because “there are no servers to manage” and they can get to market faster. The time is coming where organizations can no longer tolerate the surprise bills at the end of the month. The time is coming where cloud cost must be the number 1 KPI that will unite those who develop and manage cloud applications and the financial organization so that they will work together - relying on one view of true costs in real time. We call this next cultural shift FinDevOps. It’s here today, it’s happening, it just hasn’t yet been called the next cultural shift for DevOps. Yet.