Thread by @jeremy_daly

Excellent post by @mipsytipsy on the future of Ops careers, even if it’s a bit critical of "Lambda: A Serverless Musical". 😉

While I 100% agree that #serverless isn’t headed towards the ridiculous notion of #NoOps, I have some thoughts on the article. 🧵
thenewstack.io/the-future-of-…

Context is *extremely* important. The repeating line in the musical of "I'm going to reduce your… ops!" is in the context of setting up and maintaining a Kubernetes cluster. If it's not obvious the first time with "Hey yo, I'm unlike containers, no patching, no maintainers"...

…then the second time around adding "No pods or orchestrators" should make it abundantly clear. Since I consider myself a #serverless purist, I try to avoid the "K" word, but the line "I know all this stuff with K8s is excitin'" should settle any further misunderstanding.

This context is important because Charity incorrectly states that "the chorus chose to double-down on one of the stupidest and most dangerous tendencies the serverless movement has had from day one: misunderstanding and trash-talking operations."

It's true that some in the #serverless movement have taken operational outsourcing to the extreme, i.e. #NoOps, but the vast majority of us DON'T think of it as an elimination of ops, but instead, as a reduction in operational burden that allows us to do more important tasks.

MORE IMPORTANT TASKS, e.g. "write libraries, generate examples, drive standardization", "evaluate use cases" or "write glue code & helper modules to connect disparate data sources." As Charity says, become "an integration point between your organization and the outsourced work."

In addition, ops engineers must work on "evolving release engineering to fulfill the delivery part of CI/CD", they need to take ownership of infrastructure and application observability, and they should extend their skillsets to understand, implement and enforce cloud security.

All of these things need to be done in any organization, regardless of whether you're #serverless or not. However, by going serverless, you dramatically *reduce* the amount of undifferentiated work needed to create the table stakes of infrastructure to run your applications.

Now, if you're looking at #serverless to eliminate your ops entirely, then Charity is right that you're wrong. I stress this so much that I add this slide to every presentation I give. Somebody in your org needs to understand all those configs and the nuances of cloud services.

I've seen orgs (most unsuccessfully) put this pressure on developers. And while, yes, devs should know the APIs and limits of the cloud services they are using, setting up & maintaining CI/CD pipelines, VPCs, security groups, orgs/accounts, etc. are better left up to specialists.

The article also subtly points out the humanitarian aspect of ops reduction. In my recent chat w/ @xavi_lefevre, we discuss the #TCO benefits of a reduced infrastructure staff, but both point out the need to refocus those engineers to higher value tasks. serverlesschats.com/70/

I too was a "jack-of-all-trades" systems person for many years. But times and needs change. Roles and technologies evolve. An ops person of today is not the ops person of tomorrow. Nor will the developer of today be the developer of tomorrow. Evolution is the key to survival.

So, no! #Serverless is not trash-talking, diminishing, or misunderstanding ops. It’s differentiating between what’s important & what's a waste of your team's time. Now, hopefully your org spends that extra time on those *important* ops tasks. #Serverless can't help you with that.