Hi, I’m Forrest Brazeal at Trek10, and this is ‘Think FaaS’, where we learn about the world of serverless computing in less time than it takes to run a Lambda function. So put five minutes on the clock - it’s time to ‘Think FaaS’.
If you’ve listened to our podcast this far, I know you’re excited about building serverless applications. Today I want to talk about a higher level issue: how do you build the kind of team that will set your serverless projects up for success? What does a serverless team looks like?
We’re early enough into the serverless revolution that there’s not a simple answer to this question. But I’ll provide some thoughts based on my experience building this kind of team in the past.
First, a team using serverless technologies contains a relatively small number of people.
Serverless computing is a phenomenal force multiplier for your technical talent. It’s entirely possible, leveraging the amazing array of cloud services that are out there, to deliver an MVP for a green field application in a weekend with just a couple of developers. But because the size of your team is smaller, the individual impact of those folks is a whole lot greater.
For that reason, your team may not look like a traditional development or operations team.
The people I’ve worked with that have thrived on serverless systems are not folks who want to write code on their laptop for eight hours and throw it over the wall to an ops team at the end of the day. But at the same time, the whole point of serverless is that there’s no low-level operational toil. There are no VMs you can SSH into, no Windows patches you can apply.
Instead, the skill set your engineers need to succeed in this space is some kind of unholy combination of Javascript wizardry, vendor management, and most importantly, willingness to own their work all the way into production.
I talked to Kelsey Hightower about this recently for my “Serverless Superheroes” series over at A Cloud Guru. He makes the point that serverless systems really require SRE skills - site reliability engineering. You spend less time focusing on “How do I install antivirus on this box?” and more time on “Where is this latency coming from for one percent of my users, and how can I resolve it given my limited access to the service provider’s logs?” And the people who are good at solving those kind of problems have never been cheap or easy to find. The reason they’re especially critical on serverless projects is that serverless systems abstract away so many of the lower-level tasks, and these more advanced problems consume a larger portion of your team’s attention.
Everybody on the team also has to be a little bit of an architect, and that’s partly due to the lack of well-defined best practices right now. There aren’t a ton of plug-and-play serverless architectures that fit the majority of use cases. I think we’ll get there in the next few years, if not sooner. But in the meantime, that type of higher order problem solving devolves on everybody. I’ve seen summer interns come in to work on a serverless project, and in just a few weeks they’re addressing questions like “what type of caching should I use to increase performance on this API call?” And obviously that’s a very open-ended question, and even with experienced people it can lead to systems that are a bit of a mess.
The flip side of this is that serverless teams tend to be hyper-agile, because the cost of failure is so low. You want to try out three different caching strategies? Go for it - the barrier to deployment and testing in the cloud is essentially nonexistent, and the low price of FaaS means you can easily have multiple flavors of your app running for A/B testing. And that allows your team to rapidly iterate toward success.
So to conclude, a serverless team collapses the traditional roles of “Dev” and “Ops” into a small group of highly technical, generalized problem solvers. We wind up seeing people concerned less about putting labels on the work they are doing, and taking much more responsibility and ownership over the systems they develop, which is the true meaning of those silly “NoOps” and “NoDevs” memes from a couple of years ago.
With serverless, anyone on your team should be able to deploy code. But honestly, nobody should really want to. Writing code becomes a method of last resort when a service doesn’t work for you out of the box. When you know a piece of code is yours to support at three in the morning, you think long and hard before writing something particularly clever. You place higher value on delivering systems that work, not writing code for its own sake. As with any technology, serverless computing isn’t an end in itself. Instead, you and your team should be asking the question “How can we, as a business, use this technology to create the most value?”
That’s it from me! Hope you’ll join me next time for another episode of ‘Think FaaS’.
