The Importance of DevOps to Serverless
DevOpsCon in Berlin was a pretty well attended European conference. The crowd was developer heavy (about 80% devs) with the rest being either pure ops or self-identified management. I was given the opportunity to give a keynote talk on day 2, so I made the trip to unusually hot Berlin in May.
For my talk, I spent a fair amount of time researching serverless devops strategies and came to the conclusion that the industry has produced very little in the way of best practices outside of AWS-specific content for Lambda and their stack (codestar, codedeploy, cloud formation, serverless application model / CloudFormations, etc).
The real [not so] groundbreaking takeaway from my talk (and others I attended) was that devops isn’t going away with serverless, it’s actually becoming even more important. No longer can we walk down the hall to the ops teams and work with them to keep services up, smoothing out whatever gaps we have in our devops practices. Ops as we know it is being pushed out to the other side of API’s, opening up all sorts of new and complex scaling challenges, particularly when it comes to data and upstream infra services. Many of the nuances of service health and performance have changed and devops must adapt yet again, feeling barely up to speed with the cultural changes necessary for “cloud native”.
In part, the lack of best practices for serverless is why SAM (CloudFormation++) has been successful despite its reportedly not-always-great user experience. They offer a declarative language that can build and rebuild “cloud-native” environments for the purpose of CICD workflows across teams. It seems that if we as an industry want real adoption of serverless outside of some simple trigger-like use cases between cloud provider integrations, we’ll need to have stronger opinions around this workflow — not just leave it up to customers to figure out (although some sophisticated ones will of course). I also think this is part of moving through the trough of disillusionment.
This is why I was interested in doing a demo of deploying Fn Functions with Spinnaker, a CI/CD tool released by Netflix and Google a few years ago. The end result was an Fn Deploy triggering a 10% rollout of the new version of the function, followed by a series of “manual steps” to rollout 50%, and then 100% of traffic completing a “weighted blue green” deployment. We used Istio to act as the servish mesh routing traffic between versions of the functions (Thanks Peter Jausovec for help on this!).
I really wanted to surface some native metrics from Istio itself to do auto-rollbacks, but there wasn’t enough time partially due to some sneaky crypto miners finding my Kubernetes clusters due to open Kubelet API’s (make sure to close port 10250).
The demo came out pretty neat. There are a few hacks, so there’s some work to do before Istio/Spinnaker are ready to work with serverless projects like Fn, but we can get there. I think we have an obligation to do so.
I’d love to hear your thoughts on the state of devops and serverless. You can reach me here in the comments or on Twitter.
Chad
