Many people think of ‘Function’ when they hear ‘Serverless’. But Serverless is a whole mindset. Our experience tells us to focus on discipline. We say: slow is smooth, and smooth is fast. Serverless isn’t faster, but Serverless feeds rapid delivery.
Serverless is a mindset
In the past, squads operated with the attitude that you could spin stuff up quickly and get things out fast. Our experience tells us to focus on discipline. Slow is smooth, and smooth is fast. Serverless isn’t faster but feeds rapid delivery if you have designed your system or modern application using a well-architected framework.
Before we go into production, we look at our observability, resiliency and reliability and what we’re doing around performance. It takes maturity and engineering rigour. Our squads assemble their observability and dashboards first to get in front of their metrics and begin the iteration process. It can take several weeks to get up and running.
Squads can achieve rapid delivery.
But once you get through that process, you have rigour and are in the environment. You’ve made that rapid delivery piece. You can rapidly increment, experiment, and get instant feedback on what you’re doing.
And the good thing with serverless is that cloud providers have observed many common patterns and abstracted them into managed services. So Amazon API gateway is a gateway-managed service and a gateway pattern. Lambda is ephemeral compute and DynamoDB database. They’re all highly interoperable. You can join those things in so many ways, so you can avoid getting caught up in design or overthinking how you will hook this stuff up. Your options are finite, so that keeps you moving, so it is rapid.
We published a blog article on how Rapid Delivery is like working with Lego blocks, e.g. just connecting the different blocks. You reach ‘slow is smooth and smooth is fast’ because you’ve got rigour. You have also invested in well-architected, and your team has a disciplined approach. So when your modern application is up and running, it’s like lightning.
The Value Flywheel
We use a Value Flywheel analogy when discussing modern applications: the value flywheel builds up a head of steam, similar to a steam train. You start slowly, the flywheel turns, and it gets faster and faster. And then, eventually, it’s flying along.
I remember talking to Dan North years ago about software development; he said something brilliant. He said, ‘Software development needs to be rapid impact’. Every time I talked to executives about ‘rapid’, they used to panic because they didn’t want to rush people. My response is that we’re still going to do it slow, but we’re going to build up a head of steam.
Then, we will go in fast when we reach full speed. You’re not rushing anyone; you’re just slowly building momentum. And then you’re getting that rapid delivery. You adopt a mindset of breaking stuff up into small chunks of value. So you can get them into the hands of real users quickly. We all have pipelines and patterns. But if you don’t deliver value to an absolute end user and get that feedback soon, then it’s all for nothing. It’s just vanity.
You need a product design approach.
We have the capabilities at our fingertips. And pathways to production or golden paths. We have the serverless first building blocks and all of the managed services. But it only works if you have a product-thinking mindset. And the product design mindset of let’s get something in front of a real user to get validated feedback. It lets you converse better with real users: ‘Is this what you want? Does this meet your needs?’.
Talented modern application squads have discipline in their engineering approach. When they talk about MVP, they include all that rigour. Otherwise, they rush into production, and before they know it, stuff goes wrong.
Serverless is software at the end of the day. To get into a working relationship with the business with your KPIs in place, you need to have ‘observability’ to assess your impact. It’s discipline in action.
Introducing experienced engineers to Serverless
Anytime we introduce experienced engineers to Serverless, they think I can’t do that because I like my stuff over here because I’m in control. But then they spend a month wholly immersed in it and take off. Because you’ve got far quicker access to things like observability and pathways, they instantly become more empowered. And that’s been an interesting side effect.
When people say go fast or rapid, you can think: ‘Oh, they’re just building up problems’. We’ve seen lots of programmers in the past who go fast initially but then get weighed down by technical debt or an add-on feature that burns and slows you down. It doesn’t seem like that’s the case with a serverless first approach.
The SCORP Process
We have a lot of experience bringing teams up to speed. And coaching and facility squads to embrace serverless first for modern applications. We talk about the SCORP process.
SCORP is our method to bring squads together in a continuous learning mechanism. We want them to communicate and learn about what worked and what didn’t work. But also drive on and share all that good practice. It’s based on a well-architected framework because you need support in a fast-changing environment. There’s new stuff coming in all the time. And you’ve got to have a support network around squads to continue going fast.
It takes continuous investment in education. If one team member is reading docs for two days in a row about managed services just to make a one-line change, then that’s two days well spent instead of days spent doing loads of code.
Because with the pace of change and the rapid release of new features and capabilities, spending time understanding how to meet your needs is a critical differentiator. And it allows your teams to do rapid delivery.
Every year, at AWS re:Invent, we watch for what we can delete from our modern application code base. In other words, what code liability can we remove because AWs have released a new managed service or feature? We say, ‘Happy days, I can eliminate that custom CloudFormation template!’. Or I can eliminate that hacked code that glues five services together!
Long-term value and avoiding code liability
What I like about this mindset and the Value Flywheel is that it helps a team figure out their purpose. You look at your landscape to see if you can do it. What’s the next best action? Or what’s the next thing we can do to make progress and start that feedback loop?’.
Then you’re into thinking about long-term value. You’re building modern applications quickly and rapidly without accumulating baggage. You’re not slowing down. And you can gradually get faster.
The reason why you can do that is because you are not writing reams of code. It is the concept of ‘code is a liability’. Instead, you’re solving business problems. You take all the complicated stuff to do, like observability, reliability and failover and get that ‘out of the box’. So you’re not spending little time tweaking low-level stuff, like non-functional requirements. You get that for free.
Serverless feeds rapid delivery.
Serverless isn’t faster but serverless first feeds rapid delivery. There’s a huge amount to unpack in that statement. For me, when people hear serverless, they still think of functions.
As an organisation, you have got to invest in your engineering talent. Serverless keeps you from that. We’re consistent in that message. You’ve got to invest in well-architected. In organisations embracing serverless, you’re shooting for a degree of uniformity or commonality across the squads based in well architected. One of the essential pillars concerning organisations and scaling is the operational excellence pillar.
Serverless and the Role of modern application developers
Serverless first feeds rapid delivery, so do you need fewer developers?
You cover much more ground if you do it right and with discipline. Because well architected and serverless first mindset sets you up for less code and more standard practice. You should not necessarily need fewer developers, but the developers that you have can have a more significant impact. The business and users will ask for more if they deliver demonstrable value. So your team will have to grow. And you can demonstrate more return on investment for your engineering team.
Do you need less skilled developers for Serverless?
In other words, can you hire fewer less-skilled developers? It depends on the ecosystem and environment. You need a high level of learning and the ability to learn and experiment. Whether that’s more skilled or not is up for debate.
If you have an excellent environment with psychological safety and investment in learning, you can take any developers and make them into highly effective serverless first teams. There’s no secret code book that Mike hides under his desk that explains the system.
You can Google this stuff, and there’s free training available. There are workshops and a body of material that supports these managed services patterns and ways of working. If you give them the time and the psychological safety, any developer could be very effective in a serverless first team.
That said, you are shifting a lot of stuff left onto that team. So the team is now responsible for security, performance, testing and CI-CD pipelines. So in many cases, there’s more responsibility. But that burden is lessened by those building blocks under managed services. Using that serverless first mindset, you offload the liabilities as much as possible.
Serverless provides you with extra capacity.
There are 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 liabilities they’re looking after are probably less than for a traditional team.
It takes fewer 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, which we have not seen in enterprises over the last ten years.
What about rockstar developers?
Do you think you need ‘rockstar developers’? I hate that term. You don’t need developers. You need engineers.
If you have two squads and their flywheels are turning. And one squad invests in continuous learning and keeps its radar up for new enhancements, capabilities and features. Over time, they will outperform the team that isn’t constantly learning. Especially in the cloud ecosystem and especially in the service ecosystem.
Because they’ll be the first to embrace event bridge, step functions have just launched 200 new integrations. A team constantly learning and has its antennae out for what to bring on board, what liabilities to remove or what new differentiated capabilities to adopt will outperform a team that just does like it always did.
Serverless requires a different set of skills.
You’re starting to see a different set of skills in teams. Collaboration is a requirement. You need a product development mindset.
The most senior person on the team is ensuring we’re following specific processes, keeping our quality reasonably high, ensuring our well-architected reviews are done and managing relationships with the product owners. Use their experience to help prioritise instead of being the most competent person in the team.
That well-architected, serverless first structure and that discipline gives you greater freedom. It gives you the freedom to go fast. It gives you that autonomy that you want to give your squads. We’ve seen this time and again. If they deliver a well-architected solution, and they can demonstrate that to us, you can gain much autonomy.
So Serverless isn’t faster, but serverless first feeds rapid delivery.So that’s the craic. Thanks for listening. Our blog is at theserverlessedge.com. Follow us on Twitter @ServerlessEdge, and our book The Value Flywheel Effect is available now.