Site Overlay

How to achieve Rapid Delivery for Modern Applications

Reading Time: 10 minutes
Dave, Mark and Mike talk about Rapid Delivery this week

There’s been a lot of chat recently about serverless, speed and modern applications. And something that we’ve been talking about for many years in relation to modern applications 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. There’s a lot to unpack with that one. In the past there’s been (I wouldn’t say a lot) squads that operate with an 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 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.

Dave Anderson  

Hi, everyone. Welcome to the next episode of Serverless Craic with myself, Dave Anderson, Author at The Serverless Edge and Technical Fellow at Bazaarvoice. My two gentlemen are here, let them introduce themselves.

Mark McCann  

Mark McCann, Author at The Serverless Edge, Stay At Home Dad, still working on my 5k times. (Running Distance)

Mike O’Reilly  

Michael O’Reilly, Contributor at The Serverless Edge,  Architect at Globalisation Partners and still not working on my 5K.

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. And we were chatting last week, and I think Mike said 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 First is a whole mindset.

Mike O’Reilly  

There’s a lot to unpack with that one. In the past there’s been (I wouldn’t say a lot) squads that operate with an 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 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 and modern applications 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.  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.

Dave Anderson  

It’s like the analogy we’ve been using for modern applications: the Value Flywheel.  One of the things that’s interesting with the flywheel is, as you often see on a steam train, it builds up a head of steam. 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.  But no one understands that or very few people understand.

Mark McCann  

It’s the mindset of breaking stuff up into small chunks of value, that you can actually get into the hands of real users quickly. We all have these pipelines and patterns. But if you don’t actually 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 definitely learned.  We have all these capabilities at our fingertips. We have these pathways to production, these golden paths. We have these serverless first building blocks. We have all of these managed services. But it doesn’t work unless you have that mindset, that product thinking mindset, the product design mindset of let’s get something in front of a real user to get some actual validated feedback. All of the stuff that we’ve talked about,  enables us now to have better conversations with real users about: ‘is this what you want, does this meet your needs?’.

Modern Applications depicted by photo of earth at night with electrical lights
Photo by NASA on Unsplash

Mike O’Reilly  

The really proficient modern application squads that do that are really disciplined about their engineering approach. When they talk about MVP, they include all that rigour as part of the MVP.  We have seen, in the past, where they go into production and before they know it stuff goes wrong, because Serverless is software at the end of the day. In order to get into a working relationship with the business and get your KPIs in place you have to have a lot observability to assess your impact.  It’s discipline. We’ve been doing serverless for a long time. I’ve really gotten into Serverless in the last three or four years.  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 it’s all the same stuff, only you’ve got far quicker access to things like observability, or your pathways out, Mark, as you’re talking about.  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.

Mike O’Reilly  

That’s another that’s an interesting part. We’ve a decent amount of experience around bringing teams up to speed and coaching and facility squads embracing serverless first for modern applications. And that’s why we we talk about the SCORP process.  SCORP is a method for us to bring a group of squads together in a continuous learning mechanism. We want to get them to communicate, learn about what worked and learn about what didn’t work. But also drive on and share all that good practice. That’s all driven around well architected because you do need support in such a fast changing environment. There’s new stuff coming in all the time. And you’ve got to have that support network around squads, to continue going fast.

Mark McCann  

It’s like 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 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 allows your teams to go really fast.  Every year, at AWS re:Invent, we’re always keeping an eye out for what can we delete from our modern application code base? What code liability can be removed 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 glue together 5 services. 

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? What’s the next thing we can to make progress and start that feedback loop?’.  Then you’re into thinking about your long term value. And you always keep that long term value in mind. So you’re building modern applications quickly and you’re building rapidly but you’re not leaving a lot of baggage. You’re not slowing down. And you can gradually get faster. And 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, ike non functional requirements. You get that for free. It’s very hard to describe that. So back to the original statement that 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 that 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. 

Dave Anderson  

So two questions for you. Serverless first feeds rapid delivery, so d you think you need less developers?

Mike O’Reilly  

Yes. I think if you do it right, and you do it with the discipline that we’ve got, you cover a lot more ground. Because really what well architected and the serverless first mindset is setting you up for is 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 value and demonstratable value, then the business or whoever your users are, will probably ask for more of that. So your team will have to grow.

Dave Anderson  

So effectively, more return on investment for your engineering team. 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, but 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, 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

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.

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 pretty. And if one squad invests in continuous learning and keep 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 their 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. 

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  

That’s 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 coming out next year. Thank you very much. 

Transcribed by https://otter.ai

Leave a Reply

Your email address will not be published. Required fields are marked *

Translate »