The Serverless Engineering Manager: Part 1

Olan, Tue Jan 10 2023 • serverless

This is a great title. Snappy. Vague. An undiscovered EM niche that might just revolutionise how you think.

Beyond a title, I have no content in mind for this post. I have been an EM on a serverless team for a year or so now. In most ways, it's exactly the same as any other team (surprisingly, serverless software developers are similar to non-serverless ones). However serverless still seems to require a leap of faith from some of the more "established" staff, so you may find yourself working with people willing to roll the dice on their career, hoping the serverless cult pans out.

There's a cult?!

Yep. In fact, that's probably not a bad place to start my highly opinionated and poorly sourced advice on being EM of a serverless team.

The cult of serverless

The cult exists, let there be no doubt. It's not surprising really - "serverless" is essentially a marketing term AWS, M$ and Google have manipulated for their purposes. Of the big three, AWS is blazing the path and investing heavily in the success of serverless.

One of the many AWS genius moves was motivating it's customers to advocate of it's behalf via AWS Community Builder and AWS Hero programmes. Combined with their extensive evangelist network and (tbf, genuine) engagement of staff of social media/slack/discord, AWS has the ability to bombard your team with multiple ways to use their many, many products, all neatly tied up in a "serverless" bow.

If the above paragraph sounds cynical, well, fine. To be honest, I love getting caught up in a wave of cultish optimism. The community is great, the builders and heroes are often keen to engage and people are sharing some great stuff. "Serverless" (the good parts) is undeniably the future. But who exactly is deciding what that future looks like? AWS have made some very good products, and you should probably use them, but AWS is not serverless... so why does it feel that way?

I see this as a risk. Jumping down the AWS rabbit hole, being gently serenaded by a flock of tweeting heroes as you descend, landing softly on a mound of AWS branded swag, encouraged to the tea party by top hatted DevRels; it's an adventure - but when you get to the table look beyond the kool-aid.

(Also, ask them what their definition of "serverless" is now, and let me know.)

Looking beyond the Kool-aid..

Look, we're at a stage in software marketing that hype is everywhere. It's impossible to get away from. Look beyond the AWS kool-aid and you'll just see more. Surfing the hype-waves that flow through twitter and hackernews is part of the job now. Serverless demands continuous learning, and part of that is understanding the landscape.

If you were hoping this post would give you a sense of that, this is where I disappoint you (and to be fair, CNCF Serverless Landscape already does a decent job of that).

Questions I would ask myself again before starting a serverless project are:

Is the team ready to embrace the serverless mindset?

Crucial. This may need some actual leadership.

Is there any reason we shouldn't use a framework (like SST)?

I would work back from this point. Everyone likes to figure things out for themselves, but it's not all about you. A framework will likely speed your team up.

Have we considered services outside our cloud provider?

Thinking of implementing search? Tempted by that shiny OpenSearch Serverless button? I'd think again. Something like algolia or typesense actually fits the serverless pricing model and has an infinitely better developer and user experience. Maybe you should consider fauna or planetscale instead of Aurora?

Is your org holding you back?

We get AWS/Google/M$ tunnel vision sometimes because of the inertia around adding on anything external. One of the main reasons I loved AWS at the start was that we had all these services I could ask forgiveness for using, instead of permission to buy. The kakfa vs rabbitmq planning meetings with the ops team quickly stopped once we started just using SQS. But your org may have become too comfortable with this and "just use the AWS service" likely makes the someone elses job easier. Your responsibility is to your team and business goals, and this is one of those times you may have to flex your company-politics muscle.

The truth is, the answers to the question above don't even matter - but having an answer does. If you've dug in to the hype, seen how the components of the serverless landscape have positioned themselves, changed your opinion multiple times, then you are probably on th right track.