Dave, Mark and Mike talk about Rapid Delivery this week:
There's been a lot of chat recently about serverless and speed. And something that we've been talking about for many years is Rapid Delivery. Serverless isn't faster, but Serverless First feeds rapid delivery. A lot of people, when they hear 'Serverless' just think 'Function'. But Serverless First is a whole mindset.
Our experience has always been around discipline. We always used to say: slow is smooth and smooth is fast. Serverless isn't faster, but Serverless First feeds rapid delivery. What I mean by that is we take our time, we'll design systems that get into the well architected side of things and the five pillars. So before we go into production, we're looking at our observability, we're looking at what we're doing around performance and we're looking at resiliency and reliability. All that takes a lot of maturity and engineering rigour.
With a lot of our squads, the first thing they do is assemble their observability and dashboards to get in front of their metrics and begin that iteration process. When you get through this, that can take a number of weeks to just get up and running. But once you get through that process, and you've got that rigour, and you're actually in the environments, that's the rapid delivery piece. You can rapidly increment, you can rapidly experiment and you can get instant feedback on what you're doing.
And the good thing is with serverless is that cloud providers have observed a lot of common patterns and abstracted them up into managed services. So Amazon API gateway is a gateway managed service and a gateway pattern.
So if you give them the time and the psychological safety, then any developer could be very effective in a serverless first team. That being said, you are shifting a lot of stuff left onto that team. So the team is now responsible for security, for performance, for testing and for their CI CD pipelines. So in many cases, there's more responsibility. But that burden is lessened by those building blocks under managed services. By using that severless first mindset you are offloading the liabilities as much as possible. There's probably a lot more concerns that they're dealing with as a team so they need to be able to do that, be adaptable and have that mindset. But the actual liabilities that they're looking after are probably less than for a traditional team
I think it takes less developers to do similar things, but the idea would be to use your developers on new emergent stuff. I've liked working with squads in this capacity over the last 20 years because there's more capacity to learn in these environments and be creative in new ways. Serverless has brought life back into architectural design again that we hadn't really seen in enterprises over the last 10 years.
There's a different set of skills that you're starting to see in teams. Collaboration is a big requirement. They need to get into product development mindset. The most senior person on the team is making sure we're following certain processes, keeping our quality reasonably high, making sure that our well architected reviews are done and managing relationships with the product owners. Use their experience to help prioritise as opposed to being the smartest person in the team.
That well architected, serverless first structure and that discipline gives you greater freedom. It gives you freedom to go f
Serverless Craic from The Serverless Edge
Check out our book The Value Flywheel Effect
Follow us on X @ServerlessEdge
Follow us on LinkedIn
Subscribe on YouTube
Serverless Craic Ep5 Rapid Delivery