Thread by @tmclaughbos

Serverless is not going to solve your org’s existing skills gap. And for many devs it’s actually going INCREASE the amount of infrastructure and operations complexity they’re responsible for. 1/

Many of the benefits we tout such as reduced infrastructure and operations complexity only apply to certain orgs that were already high performing and cloud native. 2/

That’s because reduction of complexity is actually a giant shell game of shifting it to different parties. Ideally the complexity is shifted to someone outside of the organization. A cloud provider, SaaS provider, etc.

But sometimes complexity shifts within an organization. 3/

To understand what I’m talking about you need to realize that what is observed at the macro level can be the opposite of what is observed at individual micro levels.

Seriously, this seems to be the hardest concept for me to get people to understand. 4/

To illustrate this, let’s take an organization running applications on a container runtime platform. And they have an ops/infra/platform team(s) responsible for the platform. 5/

They’ve taken care of all the infrastructure and pipeline to the point a dev shoves some code into a container with a little bit of config for their app and things Just Work™️.

Dev doesn’t have to know how a biz transaction reaches their app. 6/

Doesn’t matter whether you think this is a good idea or not. This is the reality of many organizations. 7/

So now you decide, “We’re gonna go serverless because we want to reduce our infrastructure and operational complexity and focus our time on biz logic that creates value for our company!”

And the shell game begins... 8/

Immediately you think, “We’ve reduced infrastructure and operations complexity by eliminating management of the runtime platform and transferring much of it to our cloud provider!”

From an organization macro level you are correct in that statement. 9/

But the key part of that statement is, “much of it to our cloud provider”.

Why? Because you didn’t transfer all of the complexity from your ops/infra/platform team(s) to the cloud provider. 10/

Go back to how a biz txn reaches that developer’s app. That ops/infra/platform team(s) handled things like networking, load balancers, etc. and the related responsibilities such as monitoring, security, compliance, etc. so the app Just Works™️.

Where did that complexity go? 11/

You are correct if you guessed the dev.

Your dev’s world at the micro level just INCREASED in complexity even while overall complexity decreased at the macro level.

Your dev just became responsible for an entirely new layer of the stack someone previously handled for them. 12/

People not understanding these concepts of the complexity shell game and the ability for simultaneous opposite phenomena to occur based on your point of observation are why I think some are going wrong with serverless and not seeing the gains they should. 13/

So let’s go back to this tweet. Serverless is not a panacea to your existing issues within your organization.

Just like containers wasn’t…

Just like microservices wasn’t… 14/

https://twitter.com/tmclaughbos/status/1437128777306419205

There are small teams that can own the entire stack from app to infra and be successful at their primary objective of creating value.

If that’s your team then congrats! You have a lot of skills and maybe would quickly benefit from a serverless transition.

That not you?.. 15/

https://twitter.com/tmclaughbos/status/1437128780296949761

If that’s not you and you’re deciding on or have decided on going serverless then a realistic assessment of skills is in order along with a discussion of how much effort and time you’re willing to put in and expect devs to put in to transition to the new approach. 16/

You’re going to have to be willing to afford time for people to learn and accept the temporary, but possibly extended, hit in productivity.

If you’re not willing to do that then stop right there and give up on your serverless transformation. 17/

Next, you need to fill your skills gap as devs learn. That means finding places for people with the missing skills even if they don’t fit your standard developer role expectations.

(With some careful consideration) Just make a new role description and begin filling it. 18/

There’s a lot more to enabling serverless at the team or department level but let’s segue into adoption at the organizational level. This thread spurred additional thoughts. 19/

In orgs where that have a, or the remnants of, a development and operations (or whatever they call themselves after that transformation) split, serverless adoption buy-in will be more difficult.

If you have an interest in serverless adoption this is worth thinking about. 20/

In an engineering organization that is still split brain between development and operations start thinking about the politics and rational self-interest of each individually deciding what’s best for themself. 21/

For ops serverless is a long-term reduction in influence, headcount, budget, etc. That’s easy to figure out and has always been the spot I’ve worried about opposition from the most. 22/

And for dev, once all their problems didn’t go away and people realize they ended up with increased responsibility in the complexity shell game, people start to question what they actually gained over what they had. 23/

Identifying this opposition has taken me a long time to truly see and understand.

Devs went from putting code into a container and it Just Working™️ to being slowed down by owning more work in a layer of the stack they’re not familiar with. 24/

If you don’t actively address the new complexity devs just assumed responsibility for you’re going to have a new and unexpected opposition front. 25/

It’s devs who “just want to code and not worry about infrastructure”.

And dev leadership who are questioning losses in productivity. 26/

Btw, don’t read this as an anti-serverless thread. I mean, read my bio. This was to help people understand real world adoption.

Nothing lands bigger death blows to a promising new technology than failed adoption experiences. 27/

I have unfortunately recommended containers more often than serverless on the grounds that if you’re not going to do it well you shouldn’t do it at all. 28/

If you are serious about serverless adoption and want to do it successfully, reach out to me and let’s chat. I can tell you most of your problems won’t be technical and their solutions will only be partially technical. It’ll be the people and process that make or break you. 29/29