This week the team talk about about serverless, speed and modern applications. A lot of people just think 'Function' when they hear the word '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.
Dave, Mark and Mike talk about Rapid Delivery
Dave Anderson
There's been a lot of chat recently about serverless and speed in modern applications. And something that we've been talking about for many years is Rapid Delivery. Mike has a great sentence: 'Serverless isn't faster, but Serverless First feeds rapid delivery'. I think there's a lot in that. A lot of people, when they hear 'Serverless' just think 'Function'. But Serverless is a whole mindset.
Serverless is a mindset
Mike O'Reilly
There's a lot to unpack with that one. In the past, squads operated with the attitude that you can spin stuff up really fast and get stuff out quick. You get out the door and then mayhem ensues. Our experience tells us to focus on discipline. Slow is smooth and smooth is fast. Serverless isn't faster, but Serverless feeds rapid delivery. What I mean by that is we take our time. We design systems and modern applications using well architected and the five pillars.
Before we go into production, we look at our observability, what we're doing around performance and we're looking at resiliency and reliability. All that takes a lot of 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 a number of weeks to get up and running.
Squads can achieve rapid delivery
But once you get through that process, you've got rigour and you're actually in the environments. You've made that 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. Lambda is ephemeral compute and DynamoDB database. They're all highly interoperable. There's only so many ways you can join those things so you don't get caught up in design or overthinking how you are going to hook this stuff up. It's these are your options and they're finite so that keeps you moving and that is why it is rapid.
We published a blog article on how Rapid Delivery is like working with Lego blocks eg. just connecting the different blocks. When you've kind of got you rigour, your base, you're invested in well architected and your team is disciplined in relation to its approach, that's 'slow is smooth and smooth is fast'. And then once your modern application is up and running, it's like lightning.
The Value Flywheel
Dave Anderson
It's like the analogy we've been using for modern applications: the Value Flywheel. And the value flywheel builds up a head of steam, similar to a steam train. You start off 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 and he said a brilliant thing. He said 'Software development needs to be rapid impact'. Every time I talked to executives about 'rapid', they used to panic because they don'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 when we get up to full speed, we're going to go in really fast. You're not rushing anyone, you're just slowly building momentum. And then you're really getting that rapid delivery.
Mark McCann
It's the 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 a real end user and get that feedback quickly, then it's all for nothing. It's just vanity. That's something that we've learned.
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 doesn't work unless you have a product thinking mindset. And the product design mindset of let's get something in front of a real user to get some actual validated feedback. It enables you to have better conversations with real users: 'is this what you want, does this meet your needs?'.
Photo by NASA on Unsplash
Mike O'Reilly
The really proficient modern application squads are really disciplined 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. In order 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.
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 of this. But then they spend a month and they become completely immersed in it and they take off. Because you've got far quicker access to things like observability and your pathways. They instantly become way more empowered. And that's been an interesting side effect.
Mark McCann
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 really fast initially, but then get weighed down by the 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
Mike O'Reilly
We've 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 the 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, in order to continue going fast.
Mark McCann
It's a continuous investment in education. If one member of your team is sitting 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 keep an eye out for what we can delete from our modern application code base. In other words, what code liability can we remove because there's a new managed service or a new feature being released. We are like 'Happy days, I can get rid of that custom CloudFormation template!'. Or I can get rid of that hacked code that glues 5 services together!
Long term value and avoiding code liability
Dave Anderson
The thing I really like about but 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 but you're not 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 stuff that's complicated to do, like observability, reliability and failover and you get that 'out of the box'. So you're not spending loads of 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 are still thinking of functions.
Mike O'Reilly
As an organisation you have got to invest in your engineering talent. Serverless does not get you away from that. We're fairly consistent in that message. You've got to invest in well architected. In organisations that are embracing serverless, you're shooting for a degree of uniformity or commonality across the squads that's based in well architected. I think one of the most important pillars, in relation to organisations and scaling, is the operational excellence pillar.
Serverless and the role of modern application developers
Dave Anderson
So two questions for you. Serverless first feeds rapid delivery, so do you think you need less developers?
Mike O'Reilly
Yes. I think if you do it right, and you do it with discipline, you cover a lot more ground. Because well architected and a serverless first mindset is setting you up for less code and more standard practice.
Mark McCann
I would not necessarily say you need less developers, but the developers that you have can have a greater impact. If they're delivering demonstrable value, then the business and users will ask for more. So your team will have to grow.
Dave Anderson
So effectively, more return on investment for your engineering team.
Do you need less skilled developers for Serverless?
So the second question I will ask (and this might be controversial) is: 'Do you think you need less skilled developers?' Can you hire a bunch of less skilled developers who can build more?
Mark McCann
It's a tough one, it depends on the ecosystem and the environment that you have established. You need a high level of learning and ability to learn and experiment. Whether that's more skilled or not, is up for debate.
If you have a really good environment that has psychological safety and has invested in learning you can take any developers and make them into highly effective serverless first team. There's no secret code book that Mike hides under his desk, that explains the system.
You can Google this stuff and there's training freely available There's workshops you can do and there's a body of material that supports these managed services patterns and ways of working. 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, 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. By using that severless first mindset you are offloading the liabilities as much as possible.
Serverless provides you with extra capacity
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.
Mike O'Reilly
I would agree with that. Going back to your previous question. 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.
What about rockstar developers?
Dave Anderson
Do you think you need 'rockstar developers'? I hate that term. I argue that you don't need developers. You need engineers.
Mark McCann
If you have two squads and their flywheels are turning. And one squad invests in continuous learning and keeps their 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 ones to embrace event bridge. And step functions have just launched 200 new integrations. A team that is constantly learning and has their 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
Mike O'Reilly
There's a different set of skills that you're starting to see in teams. Collaboration is a big requirement.
Dave Anderson
They need to get into product development mindset.
Mike O'Reilly
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.
Dave Anderson
Use their experience to help prioritise as opposed to being the smartest person in the team.
Mark McCann
That well architected, serverless first structure and that discipline gives you greater freedom. It gives you 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're delivering a well architected solution, and they can demonstrate that to us, then you can gain a lot of autonomy.
Dave Anderson
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 is available to order now. Thank you very much.
Transcribed by https://otter.ai
Top comments (0)