Serverless Craic from The Serverless Edge

We talk about what we would like to see announced at this years AWS re:Invent 2023 looking at Observability, Generative AI, PartyRock, Developer Experience to name a few. Serverless Craic from The Serverless Edge Check out our book The Value Flywheel Effect Follow us on Twitter @ServerlessEdge  

Team Engineering with SCORP - there are practices we do like SCORP, which is our agile way of doing well-architected in every sprint with teams. Our practices are connected to engineering excellence, looking at what you're doing and constantly improving. And HP (high performing engineering), as a way of capturing key metrics to define good engineering or architecture, and then talk about it as a team. Even though the practices are out there, it's really just a mindset.

There were a few stories in the news about working remotely from another country. We talk about the pros and cons of working remotely versus returning to work. We work remotely and are globally distributed, but we've worked for many years in the office to, so we have experience of both to make a fair analysis. Serverless Craic from The Serverless Edge Check out our book The Value Flywheel Effect Follow us on Twitter @ServerlessEdge

Developer Productivity and discussions on developers and productivity have never gone away. You heard people talking about this in the 80s and the idea of paying developers by lines of code. And it was even rubbished in the 80s as a foolish thing to do. There's a famous story about developers removing bad code from the code base and having negative numbers by the end of the week and then asking if they have to pay the company back money. It's never been a good idea. It strikes me as strange that in 2023, we are having the same discussion. Serverless Craic from The Serverless Edge Check out our book The Value Flywheel Effect Follow us on Twitter @ServerlessEdge

How important is Resilience Hub, Chaos Testing and Well-Architected? We attended the AWS Resilience Day at the Titanic Hotel. We were sitting in the same room where the ill-fated Titanic was designed and drawn! We discuss what we learned. Including the tools and strategies that help software engineers build resilience that were not available for the Titanic engineers. And we talk about the fact that it isn't just one thing that leads to disaster for ships or workloads. Serverless Craic from The Serverless Edge Check out our book The Value Flywheel Effect Follow us on Twitter @ServerlessEdge

Bringing mapping to your org. We are doing a wee series on Wardley Mapping, with some practical items. The last two episodes were: 'Wardley Mapping 101' and 'Can Wardley Maps Predict the Future?'. So I thought it would be good to answer a common question: 'That's a cool technique, but how would I do that in my work?'. If you follow Simon Wardley, on Twitter, and you've started experimenting with Wardley Mapping, we tell you how you to bring Wardley Mapping to your place of work. We talk about using the Northstar exercise to facilitate mapping. And about finding like-minded people to sit and practice with. There is a way of talking about mapping. You're better to start with the outcomes. And then see if people are interested to get back into the map, as a way of sensemaking complicated areas. It's great to make sense of something and share that thinking with peers. And once you get into that language, you open up a common way of thinking and the idea of evolution to access things you want to talk about it. Serverless Craic from The Serverless Edge Check out our book The Value Flywheel Effect Follow us on Twitter @ServerlessEdge

Can Wardley Maps predict the future, is our topic this week. In our last episode, we talked about Wardley Mapping. We did a 101 last time, explaining the basics. One of the things that we say is that Wardley Mapping is a superpower that helps you predict the future. What do we mean by that? It's like a fortune teller. But it doesn't tell you when exactly something's going to happen. It's the state of mind that it puts you in. We run through a couple of examples, to demonstrate how we've done it in the past. Conversational Programming Generative AI Well-Architected Serverless CDK (Cloud Development Kit) If you have good situational awareness, you can wait until the appropriate time. You don't have to go off and waste energy, cycles and money trying custom build something. Wait three months and you'll get what you're trying to achieve. When you map this stuff out, you can start to think about how your sensing engine can get intel on whether these things are going to happen or not. There are lots of different ways you can do that. Like following Twitter feeds and looking at blogs. And looking at who they're hiring and following the industry experts. They're points of information that can help you see how things will evolve. To predict the way things are going to go. There are multiple levels of maturity in your map and how you think it's going move and where the evolution is going to happen. Wardley Mapping can be used to predict the future but it's not going to give you an exact date. What it can do is give you an example of this is what it will look like if it happens. So you prepare yourself for when it does. And then when the press release comes out, you're like, boom, we're ready. We saw that coming. So it's the no 'surprise approach' to building situational awareness.  Serverless Craic from The Serverless Edge Check out our book The Value Flywheel Effect Follow us on Twitter @ServerlessEdge

Wardley Mapping is a core part of our book: 'The Value Flywheel Effect'. And it's a topic that people always ask about it. It's a difficult thing to learn. We've spent many years thinking about it, stumbling around, and then practicing. So we figured we would do a quick series on Wardley Mapping. We have spent almost 10 years mapping, give or take. For me, it has been an absolute game-changer. One thing that's come along recently is the Wardley Mapping canvas by Ben Mosior @hiredthought. It's a nice canvas with six steps on how to map. Before I started using the canvas, I used to find that maps could get big and go off in 60 different directions. Purpose and scope are the first two steps. And then the third one is users. The fourth one is user needs. And then the fifth step is the value chain. It can be difficult to keep things abstract. And not go too deep. But it is good to be as abstract and high-level as possible, even just to start to get something down. Once you have the value chain of the user, a need, and a couple of dependencies, that's when you then bring it across to the map. And I would usually put them in the middle of the map. Drop them all into Product, to get you started. So you've got them all in a vertical line on your map and canvas. You start moving different components from left to right. And you might work out that one of the dependencies is Commodity or Custom. And you can see how that interaction goes. That's when you start to add in dependencies because you've got more room in the map. This is where the conversation really starts to kick into gear. And this is where people start to challenge each other's context and think about where that component belongs or what's missing from the map. So it makes for a very collaborative exercise. If you are planning a mapping session, you need to be a good facilitator. If a participant feels something is in the wrong place. Don't say no, you're wrong. It's in the right place. You want the individual to explain why they think so. If it is something that's blatantly just them for raising the challenge. The last thing you want is an unsafe environment where nobody wants to speak. It doesn't need to be too fancy. You might map for an hour. And if you're facilitating, five or 10 minutes off the hour, you take a couple of notes, If someone says we should move that component from x to y that's an observation, You're not committing to do it but just taking a few observations. Always just keep it simple. So here are a couple of really good links. We talked about Ben Mosier @hiredthought. He's got a brilliant site called LearnWardleyMapping.com. Ben created the Wardley Mapping Canvas, which is on Creative Commons Open Source. Simon's also got a couple of links. There's a site on GitHub called Awesome Wardley Maps. It is by John Grant on List.WardleyMaps.com. Simon's original book is on medium.com/wardleymaps. Simon's content is great but deep.  Serverless Craic from The Serverless Edge Check out our book The Value Flywheel Effect Follow us on Twitter @ServerlessEdge

ServerlessDays Belfast was on the 28th of February. It's a volunteer, community, and not-for-profit event. We had a bunch of sponsors: AWS, Bazaarvoice, EverQuote, G-P, Instil and LibertyIT. Our organizers are me, Gillian Armstrong, Garth Gilmour, Peter Farrell, Julie Sherlock, and Treasa Anderson. We had 12 speakers, and over 260 attendees from over 40 companies. But most excitingly we had it at the Game of Thrones Studios Tour. The theme was 'The Reality and Fantasy of Serverless, Building Serverless Teams and Making it Real'. Phil Le-Brun, who is the Director of the Enterprise Strategy Team for AWS launched the event. And give us a perspective of what he sees when he is speaking to the leaders of the industry. IT Revolution was very generous to sponsor and provide 250 of 'The Value Flyweel Effect' books. Julian Wood gave the Keynote. Even though he works for AWS as a Serverless Developer Advocate, he gave his opinion on where he sees the industry. I thought that paired really nicely with Mattie Wilson from Instil. He gave a brilliant talk on an engineering team going through the journey from a cloud application to a serverless application. Sheen Brisals from The LEGO Group, as ever, gave an absolutely brilliant talk about Lego's journey. Going Serverless to EDA and the team topologies of an event-driven organisation. Sheen is an absolute master. Jonah Andersson did a talk on the .NET stack. And Conall Bennett and Roger Moore did a talk on CME Group's move to a Google tech stack. Craig McCarter talked about large-scale serverless. And I took comfort from hearing about a team that's doing something financially significant at a massive scale. And they're pushing those limits. I really enjoyed the talk by Anna Carlin and Emma Patton from Aflac Northern Ireland. They called their talk: 'A rookie journey of discovery and learning'. So they came in as grads and basically built a serverless system. And Chintan Parmar's Dunelm story was really interesting about Dunelm's e-commerce site because it's quite an unknown story. Most people had no idea that they had a whole big serverless ecommerce site. Ben Ellerby from Aleios closed out with his Serverless Staircase Framework. I've been a fan of Ben's for many years. He's an AWS Hero. He's brilliant and very experienced. And he's worked on a lot of serverless projects. That is what his company does. So he's got lots of war stories from doing this with real customers. Serverless Craic from The Serverless Edge Check out our book The Value Flywheel Effect Follow us on Twitter @ServerlessEdge

We've been talking about AWS re:Invent over the last few episodes. But one thing that we haven't talked about is Serverless Espresso. Serverless Espresso is a pop up coffee shop that allows you to order coffee from your phone. In the Expo Hall at the AWS Summit, they have a Barista setup. And you walk up to a QR code with a screen in the background. So you scan the QR code and enter in your email address. And up pops a menu. If you select an americano, espresso or other type of coffee, it kicks off an event driven flow. It uses an event driven service under the hood and pops up in the screen as a number. And then the Barista takes the number makes your coffee and gives it to you. But what's happening in the background is a whole load of orchestration and choreography run events. And as they've been using it as a way to explain serverless event driven architecture. Event driven architecture can be hard for people to conceptually wrap their heads around. So making it real through ordering coffee. And showing how to tie a coffee process and an event driven coffee ordering system makes it real. It demystifies it a little bit and removes some of the thinking that event driven architecture sounds really hard. This makes it more approachable. It stitches together a lot of stuff that we've been advocating for, in a way that makes sense. By using AWS Step Functions, EventBridge, Lambda, API Gateway, S3, DynamoDB and Cognito. It brings to bare a lot of great technology that we are advocating for in a way that's practical and easily consumable. And the Serverless Espresso workshop is very good for walking you through the steps about why you're doing what you're doing. And how do you do that, set up rules and set up everything. It's a great way to get hands on with event driven architectures and serverless in a practical way. There are two myths in this space that AWS are trying to dispel. We first started talking about event driven architecture 13 years ago. We had the idea of doing something but back then it was really difficult, because we didn't have a lot of support. So we had hard problems to solve technically, because the foundations weren't there. That is the first myth of being a hard thing to do. The second myth is that people think of serverless as just writing code and functions. It's actually more like an event driven architecture. It's events firing off activity and not a call stack. So it's a lot easier to build full event of architecture than it would have been years ago. The technical challenge is not as bad as you think it is. What I like about Serverless Espresso is the simple interactions. You order, it goes to the barista who makes the coffee, and he gives it back to you. There's one interaction. Normally when ordering a coffee, you talk to a waiter, the waiter talks to the barista, and the barista talks to someone about milk etc. There can be six or seven people in that flow. It causes confusion. In a company, if a business process is owned by six or seven teams, even across two or three departments, it gets messy. If a single team builds for the customer directly and there's no one else, it's usually pretty clean. Because you can see everything needs to happen. It gets complicated if the business processes is split over several teams and departments. Serverless Espresso Lab is good, because the opinions are out there and you add on your bit, which is your business process flow. It goes back to our book The Value Flywheel Effect. And the first phase of the value flywheel which is clarity of purpose. Who is the customer and what is the business flow that we're trying to build? And let's have a good debate on how we are going to do that. When you get to the technical side, that opinion is already there. And you can focus on getting the orchestration correct. Because you know that a lot of that underlying stuff is pretty much solved apart from making it behave. Look at the Serverless Espresso Lab on workshop.serverlesscoffee.com. Or search for Serverless Espresso. And big kudos to the AWS Serverless Developer Advocate team. They're mostly on serverlessland.com. Thanks for listening. Serverless Craic from The Serverless Edge Check out our book The Value Flywheel Effect Follow us on Twitter @ServerlessEdge  

AWS, What's New? We are post AWS re:Invent. To sum up, it was about the next generation of cloud focused on delivering value quickly by removing barriers to business adoption and enablement. This year there was a solution focus. Previously there was a focus on migration. On Day 1 SiliconAngle published an article called "AWS chief Adam Selipsky hints at the next-gen cloud". He looks at classic cloud versus next-gen cloud. Classic cloud is infrastructure as a service and the platform of the cloud. And next-gen is looking at ISVs and true cloud. It's about using the cloud to power you business journey. Which is exactly what we talk about in The Value Flywheel Effect! AWS are market leading for low level cloud primitives. If you want compute, get it from AWS. It has been this way for the last 15 years. But next generation cloud is about business capability. When you do Wardley mapping correctly, cloud primitives are pushed to the right to become commodities. You then look for the business capability you need. That's exactly what the value flywheel effect is. You look at your business strategy and decide what you need to use versus what you need to build. You use technical strategy to build the right thing. And you're not stuck using something that someone else is going to expose as a SAS. AWS are consolidating core primitives and opening up the solution space to help customers do interesting things with them. And you can see that with the partnerships they are setting up with other big companies like Mongo and CloudFlare. It's becoming an ecosystem. There has been a lot of criticism of AWS in previous years with regards to their developer experience. Code catalyst is a big move from AWS to try to make that more seamless. It stitches together a number of things that have evolved over the last while. But it's really about enabling product teams to rapidly deliver value in a way that doesn't blow up three months down the road. It's an accelerator for teams coming on to the cloud or into serverless. And it is frictionless developer experience. In our book, it's the next best action phase of the value flywheel. Well architected featured heavily at AWS re:Invent. AWS are continuing to develop well architected and build it into things. And they are continuing to develop patterns, blueprints and accelerators. Security also featured with verified permissions. It's out in pilot at the moment but it has potential to make a big impact on managing fine grained permissions and doing identity authorization properly, especially if you have a custom app. Most companies of a certain scale have their own custom built version of this. So they have spent a lot of time and effort. But you need to acknowledge that you are ahead of the curve. And have the courage to delete your custom built solution. Deleting code is a good idea! There's a bunch of step function stuff out. I particularly like SnapStart which gives you the ability to drop large java applications into lambda. And performance time is through the roof. You can draw up an average Spring Boot application into lambda and you will get similar performance but it's way cheaper to run. It's not just java, there will be other languages as well. It's snapshotting a virtual machine and making it available on demand, which is a big deal. There are some caveats to it. But it's addressing the myths around cold starts and using lambda for high performance workloads. It's also interesting from the perspective of having large framework oriented services and leveraging those for femoral compute. At AWS re:Invent, the message I was hearing loud and clear is that enterprises and large companies have moved to the Cloud but need help doing the next piece. They need help creating their value flywheel. They've done the move and now need to go to the next stage of modernization or next-gen. So that is good news for our book 'the Value Flywheel Effect'. Because we tell you what to do. I spoke to a lot of people who were trying to do a serverless transformation. And trying to create their value flywheel. There's definitely a lot of demand for more advice and guidance. And stories of how companies have done this. The ecosystem has never been better for applying the value flywheel effect now. A lot of the challenges we had in the past have started being addressed. So it should be easier for people who are adopting it now to make progress. In the past, when we promoted being well architected and serverless first, people looked at us a little funny! But it's starting to permeate throughout AWS. It's an accepted term and people understand what it means. There's a lot less inertia going well architected and serverless first. Compared with what we experience six years ago. Serverless first is not scary anymore. Serverless Craic from The Serverless Edge Check out our book The Value Flywheel Effect Follow us on Twitter @ServerlessEdge

AWS reInvent announcements In this episode we are talking about what we would like to see at AWS re:Invent. The AWS internal teams work towards re:Invent to make their big announcements. Sometimes they have announcements beforehand. But the big announcements will be on stage. What would you like to see? Serverless Services An increase to the enhancement and evolution of service development capabilities and the ecosystem in general. So more serverless services coming online for items that aren't serverless and iterating to be more serverless. There's a bunch of things that people are almost afraid of like observability, deployment patterns and some of the frameworks. So make those a bit easier. API Gateways In service development, Private API gateways are interesting, but they could be more developer friendly, in terms of setting up, naming and managing. The edge around the environment needs to be tightened up. I don't think they have nailed the data options yet. We are seeing more enhancements around eventing capability like SNS filtering, SQS and X ray. These are things that make the serverless experience more rich and all encompassing. Developer Enablement That leads on to developer enablement. You need to think about developer enablement and time to value. Can you get a developer up and running with a productive IDE in the cloud? And can they start delivering value rapidly? We're seeing steps around Cloud IDE starting to emerge. I want to see what AWS does around their Cloud9 offering. So that you can go from idea to something deployed and running within minutes. Well Architected We are big advocates of the well architected framework. Over the last year, we've seen good announcements on well architected capabilities, systems and services coming online within AWS. I want to see a continued evolution of that. And more well architected thinking and characteristics baked into everything AWS are doing. All the way from developer advocates to patterns and code samples. Well architected needs to be better known. A lot of people still don't know what well architected means. There is still work to do to get people to understand what well architected is and what it isn't. And have it present in the tools and not a separate thing that you need to go and do. It should just be there in your job. And there's a second thing. Some of the basic primitives are moving up a level to something more like a pattern. Developer advocates are great at this with Serverless Land. It would be great to see some consistency in those higher level primitives. It's about fast feedback and dare I say the value flywheel. Can we get more feedback faster on our well architected status? Can the pipeline's tell us how well architected the chains that we made are. And can our IDE tell us how well architected we are? Stitching that together in a compelling way with fast feedback for the developers would raise the bar on what developers deliver into production. That's effectively platform heuristics. I remember back in the IBM mainframe days, it was a mature platform. And you knew it so well, that they started to bake in heuristics. When you start to analyse your code there would be a heuristics to say this might be wrong. Here's what you need to do to fix it. We're starting to see some of these elements emerge already with Security Hub, Reliability Hub and Fault Injection Simulator. It's about stitching those together like factory mode for workloads in your accounts. Tell me we're not well architected, and tell me how to fix it. There's probably an extension to that. As we enable developers I'm seeing good industry examples from new tools that have been launched. In other words here's a new feature and here's how it applies to your particular industry. Sustainability Sustainability is a topic close to our hearts. I haven't heard much about it this last while. More fine grained analysis of carbon scores would be useful when teams are designing and building their workloads. And getting faster feedback on a particular service and how much it is going to cost you in carbon. What's the wacky stuff you would like to see? I'd love to see work on APA management and API gateways. Factory mode for your accounts. How well architected are you would be really good. Instead of us having to do the reviews and do it manually. The gateways are due an uplift or enhancement. What about documentation? And how you consume information about services. We are seeing an explosion of services on the console. Is there going to be a cut down console just for your layer? Cost is always a big one. FinOps is a massive growth area with a lot of good tools out in the market. The only other one I can think about is Identity. It will be interesting to see if anything comes out with Cognito. Serverless Craic from The Serverless Edge Check out our book The Value Flywheel Effect Follow us on Twitter @ServerlessEdge

It began with the forging of the Great Maps and Simon Wardley We've been talking this week about Wardley mapping. Simon Wardley features in our book 'The Value Flywheel Effect'. Where did you first hear about Wardley Mapping?  I first heard Simon Wardley talking at cloud conferences about early cloud. I remember an open source conference and a 20 minute video. Simon was really funny, which actually helped. When he presented it came across as common sense. Like, why would you do anything else? The bigger question is why were we looking for this type of stuff? Or why did it resonate with us? I think we were at a certain point in our careers. We had been engineers for a while. And we thought there's got to be a bigger picture here that we're not quite grasping. Simon Wardley started writing his book in 2016. I went to Lean Agile Scotland in October 2016. And he did the talk in person. I had seen his talk a couple of times, but it didn't really click until I sat and watched it in real life. I've always liked the idea of a group of people drawing a diagram to understand something. I think that is really powerful. Remember, there was a time when we said we need to stop using PowerPoint! We need to get people into rooms to have conversations and working sessions. I refined and improved my ability to do Wardley Maps through teaching. There were people who hadn't experienced mapping. Or if we had visitors or customers in the building, you'd get them into the end room with the big white wall and just start talking. You would try to teach them what a map was. And what each position meant. Or even just have a conversation. There's another important step. You move from doing it yourself to doing it in a group environment. When you are looking at a map you are figuring it out. When you do it in a group environment, the group will ask about this and that. And that's when it really starts to click. For me, the two big things are: 1. Start with a customer need. I remember a team were stuck for six months because they didn't know who the customer was. 2. The four phases of evolution or access (Genesis, Custom Built, Product, Commodity). Get your head around that concept. One of the other pitfalls we fell into was mapping too much detail. We went too low level. And then someone came along and zoomed us out, by saying 'you don't need those five components. Here's just one!'. Practice, practice, practice is the big lesson here. We knew we were starting to get good when we were able to roll it out across multiple teams to map out the tech stack. They were getting value and getting excited about doing it. And we were getting lots of feedback on what did or didn't work. We were in offices and I would draw maps on the board. It was all very collaborative. But now we have the emergence of good online collaboration tools like Miro etc. Another important lesson is that senior people just want to hear what you are going to do. They don't want to know how you figured it out. If they say why are you doing that? You can go through the map in your head and say that you've thought about it. If you say this is what we are going to do and here's the outcome, you don't need to show them all your work. When we started mapping there wasn't much about apart from the odd presentation. Now there's lots of material out there. The community is growing. You can google and look up YouTube. And there's online conferences as well like Map Camp. Those videos are available soon as well. A lot of Simon Wardley's maps are readily available on GitHub. A lot of the work in UK.Gov carried out by Liam Maxwell and others still stands the test of time. If you look at the UK government's digital footprint, it's still in there on freely available materials. Their work is permeated with thinking about user needs, understanding value chains and situational awareness and mapping. For resources look at Simon Wardley on Twitter @swardley and his pinned tweet. Simon has a book: 'Wardley mapping'. He is on Medium at 'wardleymaps'. There's a whole bunch of stuff including free articles. They're fairly meaty but they're good. John Grant keeps a list of maps on GitHub, which is list.wardleymaps.com. Ben from @hiredthought is also at learnwardleymapping.com. And of course, our book, 'The Value Flywheel Effect' is coming to a store near you soon. Serverless Craic from The Serverless Edge Check out our book The Value Flywheel Effect book Follow us on Twitter @ServerlessEdge Transcribed by https://otter.ai

What is Engineering Excellence? We are chatting about two things that I think are quite interesting: engineering excellence and well architected. They are two phrases we kick about a lot. And they're heavily featured in the book, The Value Flywheel Effect coming out soon. Few companies will say they don't want good engineering. And we are happy with bad engineering. But they don't define what good looks like. And then the second thing is that engineers are expected to write lots of code. For me, engineering excellence is not writing loads of code. It's about getting into code reliability, feedback loops and how well engineering is functioning. And how your team is performing and meeting bigger goals. I love to say 'slow is smooth and smooth is fast'. So how do we set ourselves up for that? At the beginning, I like to go slowly to look at our process. To define engineering excellence, we use Dan Pink's motivation factors of autonomy, mastery, and purpose. We translate those motivation factors to technical excellence, autonomy, and customer focus. Well architected is better defined than engineering excellence. But I find that a lot of people haven't heard the term well architected and they think you've just made it up! There's a body of evidence, supporting material, videos, tutorials, workshops and labs to support well architected. People can google well architected, whether they're talking about AWS, Azure or Google. And they're going to get a fairly consistent response. They self serve and self learn. I remember years ago, when you talked to architects, they said that good architecture is a non functional requirement. It's performability, scalability, extendibility and every stupid word ending in 'ility'. Now the fact is that it is well documented, understood and you can rhyme them off as SCORPS makes it easier. If you want to move fast, you've got to be empowered and know what good architecture looks like. When you have guidance or patterns that are implemented in a well architected fashion, that sets you up for rapid delivery, moving with speed, and in an engineering excellence way. It's fast flow aimed to facilitate you moving fast, getting things out quicker and being more competitive. Teams are rapidly delivering product value multiple times a day. And they have a trail of evidence that they're going the right way because of these practices. They have dashboards, logs, alarms, alerts and the run books and the playbooks. And the key business indicators (KPIs) at their fingertips. So any stakeholder can challenge them on what they are doing, how they are operating or what they are deploying. I f you arrive in an area that isn't well architected, you've got to spend three months trying to understand what went on before or trying to understand the decision making. Or you've got 12 months of technical debt that should have been taken on board before you moved there. That very difficult from a personal perspective. There's a whole bunch of advantages. One is a problem prevention culture. But I don't think it exists in a lot of organisations. It hasn't really cut through. They're still on the feature, factory, server mindset. Deliver, deliver deliver. Feature, feature feature. And then they have a tipping point where everything grinds to a halt for months or maybe years. And it may never recover. But if you have a continuous improvement mindset and you are investing in fraud prevention, well architected, engineering excellence and continuous learning. And you are enabling and applying this to your teams, you get ahead of problems before they become problems. You're investing in performance, security, resilience, high availability, every day and every week. And those things compound on each other. It's like compound interest! From a problem prevention perspective, do you want to spend all your time babysitting a non well architected workload and dealing with all of that? You want your teams moving, adding value and moving on to the next thing. That's not possible if your build lacks quality, is always down or if you're having to constantly upgrade. With well architected and engineering excellence, we can build things that run and increase in value. And there's less work over the long term, while your teams move on to what the business needs. I don't think a lot of orgs think in that way. By the time they do get thinking that way, they're already experiencing a lot of problems. Serverless Craic from The Serverless Edge Check out our book The Value Flywheel Effect book Follow us on Twitter @ServerlessEdge

We are just back from The Value Flywheel Effect book launch at DevOps Enterprise Summit organised by IT Revolution with Gene Kim and crew. We had a great week doing our book launch. It was great to see the buzz and the content. But getting handed the first copy of The Value Flywheel Effect book made it very real! There was a shelf full of IT Revolution books in chronological order. Like DevOps, Enterprise Handbook, Accelerate, Team Topologies and all the Mark Schwartz and Dominica DeGrandis books. And The Unicorn Project and The Phoenix Project. It was unbelievable to see our book sitting alongside all of those books. Learning Sprint The first thing I did was a learning sprint. I did an hour on creating a cloud strategy with Wardley mapping, which I thought was interesting. I used Ben Mosior's Wardley map canvas from LearnWardleyMapping.com. And it was great taking people through that. Once people start connecting the elements of the value chain, they can start to ask why is that over there and not over here? Then you're into a nice conversation. Once they get beyond the terminology, notation and syntax, they are asking interesting, challenging questions. The canvas is a great way to get people thinking quickly. They start gaining insights and seeing what they may not have before using the canvas or map. And you can give them tips. People deliberate over who is the exact customer. Or the actual customer and their needs. People can get very micro at the start. And you say just pick one and keep moving. Just keep pushing through, because you can always add more later. You are getting people to move quickly. And you are giving people a couple of steers. But the first 20 minutes is complete confusion. What are we doing here? And then once you draw the map out, people go 'Ah right!'. And then when you start to plot movement and inertia, that's when people get really excited. And it becomes crystal clear. Creating the Value Flywheel Effect Talk I deliberated on what to do for my talk because I wanted to do something different. So I decided on 'Creating the Value Flywheel Effect' looking at how came up with this stuff. So I did an intro to the book. And then I told the story through maps, similar to our Map Camp talk. I started with one of the drawings we had done five or six years ago. Which was a scribbled messy drawing of a map. And I contrasted with the map in the book to show the evolution of the map. So it was a nice mechanism to tell the story. Some people think that maps come out fully formed. But they never do. There is lots of variation and challenge. We always challenge each other. And we revisit, rub stuff out and draw it again. When we validate certain things we always go back to the map. It's not the map. It's the communication! And the interactions. The maps are always wrong at the start. People try to go out of their way to create the perfect map. But that's not the point of the exercise. The Value Flywheel Effect Book Signing I did the book signing in the main theatre. There were 4 different book signings. So you hope to see people queue up because you don't want to end up standing on your own. But there was a huge queue and I was there for two hours signing 200 books. People were really nice and they were really excited. And lots of other speakers queued up as well. Propelo sponsored our book signing and they were great. So now the book is in the wild with 200 plus people! So we're starting to get feedback from people who weren't in the early previews. It was fantastic to see Dominica DeGrandis' comments on LinkedIn. She wrote the book: 'Making Work Visible'. It is a brilliant book about visualising flow. She has a couple of posts about our book: 'The Value Flywheel Effect'. And she popped up a maps from her LinkedIn called 'Mapping Psychological Safety'. It was the name of the post on her blog: DDeGrandis.com. And she said that it had never occurred to her to map psychological safety. I thought that was insightful. We would map stuff like that all the time. There's no boundaries to what we map. Psychological safety is usually the base or foundation of the map. Mapping, safety or challenge are things that are quite hard to see. But they are the most important thing for everything that comes above it. The thing at the very top, which is the need, is usually the least important because it is the end product. It's built into the flywheel. You need an environment where it's safe to challenge. And having safety to challenge requires psychological safety. It's cool that it's resonating with people and they're starting to zero in on those sorts of things. DevOps Enterprise Summit was a great event. Look up the slides on GitHub. All the videos are on videos.itrevolution.com. Serverless Craic from The Serverless Edge Check out our book The Value Flywheel Effect  Follow us on Twitter @ServerlessEdge

Today we are talking about a big DevOps Conference. And the first book signing of our new book, The Value Flywheel Effect. It's at the DevOps Enterprise Summit on October 18-20 with IT Revolution who also published our book. It's the first live event in three years. DevOps Enterprise Summit is the leading community for driving change in technology. And IT Revolution focuses on practitioners and not professional authors. It's people who have done it and are sharing their story. It's scary and challenging tying to drive transformational change. So it's brilliant to be able to talk to practitioners who've done it before. I'm interested to see how 'The Value Flywheel Effect' lands. I'm doing a talk on the book and a book signing. And I am doing a couple of Learning Sprints at DOES. We are focusing on Wardley Maps because that's what a lot of groups find super exciting. So the Learning Sprints will be about mapping. And I will focus on mapping in the actual talk. One of the best things about mapping is that invites challenge. So hopefully the audience will be debating if I have my components in the wrong spot. Then I'll having a proper conversation and interaction. Because that's what I want. At the Learning Sprint we will sit down with a table full of people and walk through the Wardley mapping process. It is a really good way of learning the technique and asking questions in a safe and comfortable space. One of the cool things about DevOps Enterprise Summit is they've been running for over 10 years. They have all their IT Revolution books, which are all brilliant. But what's neat is the Repo on GitHub. where they put the presentations for all the talks. There are two events a year. So you have about 20 repos full of presentations on GitHub @DevOpsEnterprise, which is the name of the organisation. It's well worth looking at. There are hundreds of presentations. And it's an absolute goldmine of free information. There are videos as well on events.itrevolution.com. You have to register for it, but it's very unintrusive. Once you register, you get access. And they don't send too many emails. It's a fantastic and supportive resource for people trying to drive change. There's nothing more comforting than seeing something that resonates with what you're trying to do. And with the challenges you're facing. And you can send it to peers, friends or around your organisation. It can give you additional support and credibility for what you're trying to do. And it can drive adoption. That level of external validation for what you're doing can accelerate internal adoption of the change you're trying to drive. We've definitely benefited from that in the past. Don't listen to us. Go watch this video or read these slides. It's a great technique to the leverage. We have two playlists on IT Revolution's blog. One on Lean Engineering and another on Effective Cloud Adoption, with links to a bunch of videos. Years ago, you would have been hoping to get on a course to learn this stuff. Now it's on tap! You end up going away from DevOps Enterprise Summit with at least 10 things that you want to try or at least look into. And you have repositories of resources available which are great getting your hands on to take back into your own organisation. Serverless Craic from The Serverless Edge DevOps Enterprise Summit Twitter @ServerlessEdge

This week we look at 'What is Value Engineering?' with BMK Lakshminarayanan from DevOps New Zealand. BMK is based out of Wellington, New Zealand working as Transformation Architect and Independent Consultant for Section Six. He helps customers on containers and cloud with DevOps, modern engineering and architecture practices. He also worked for 15 years with Bank of New Zealand. As part of that work he connected and became a central part of the DevOps community. BMK uses the term value engineering a lot. It's about making tech impactful for your business. When he says impactful for your business, it's about value for your customers. That includes making wise decisions about your technology investments. Value is what is your customer getting out of your service and product? You need to look at three things for customer value. 1. What value is the customer getting from spending their time? 2. What value do they get for the money they spend on that product or service? 3. Are they really happy with the service or product that you're offering? The other side of the coin is actually business value. What is the business getting out of the software you're running in production? Is it generating revenue for your business? What IT investments are the business making? Are they getting a good return of value? If the business saves money using technology, they do more with less. The investment will increase as they go forward. Studies in the last few years with Gartner, Forrester and other analysts say that technology investments keep going. When technology is providing the value they are after. As an architect or developer your job is not just building and committing code. You look after the code that you're running in production. And how customers are using the system and the experience they have. The feedback you get goes back into your architecture, design, planning and development. You're not a programmer, you're an engineer because you are creating an outcome. And you're not creating code or a product. You have to understand what that outcome is. Your output is not the code. The outcome is the business deliverable. There's a huge piece of engineering culture that needs to be put in place. We are talking about psychological safety. If you ask engineers to own an outcome and it's not happening. They need to be able to speak up and drive how that outcome is met. I use a term called engineering excellence. It's the mindset and culture within software units or the technology itself. An enterprise may have top talent and high density talent. But who can solve problems for customers? People need to feel comfortable sharing their experiences from an organisational point of view. In order to do that, you need a friendly environment where people can stand up and speak up. I've seen the other side of things. When engineers don't feel they are in an organisation that's promoting, safeguarding or helping with psychological safety. They keep moving to a different organisation to look for different opportunities. Or sometimes developers put their heads down and they don't give their best. Because they feel they don't have options and they're stuck. Are you seeing many failed cloud transformations? Or to phrase it in a different way. A lot of people have moved to the cloud. But they haven't realised the value they thought they would have. Have you seen that? I would not attribute that as failure. But I would say a lot of organisations are struggling in this space. Moving to the cloud is not just a business decision. You need technology experts to make this viable for your business to run. A big challenge that I was talking about a couple of days ago with a client, is have you thought about Capex and Opex. It's a fundamental thing. Because in traditional IT, you have a datacenter and you have design and a lot of capitalizable work in that space. But when you move to a rental model, the Capex is very little and the Opex is more. The business previously never worried, cared or thought about how much data cost to run their business application. Because it's a shared infrastructure in your data centre. There's a whole education required. We talk about that in our book. FinOps and Opex versus Capex. The organisation has to change the entire process, their thinking and the working culture, when you adopt the cloud. I hate when companies put a layer in front of the cloud. They take the old infrastructure team and put them in front the cloud. It's completely stupid. And it's missing the point. You need to let developers loose with guardrails and the correct governance. You can't build the same way in the cloud. You've got to build in a different way to take advantage of the newer services. Serverless Craic from The Serverless Edge Check out our book The Value Flywheel Effect book Follow us on Twitter @ServerlessEdge

How to apply the well architected tool Grady Booch is a fantastic software architect who has done a lot of pioneering software engineering. One of his latest messages says that it's a good thing that AWS, Azure and Google are offering guidance on building with well architected. But he also warns that when cloud providers talk to you about well architected, it comes with a bias towards their products. There is an inherent bias among providers who are investing in these frameworks. They lean towards their own ecosystem and services. But the interesting thing about the AWS framework is if you squint at it sideways, you can extract the implementation details. And focus on the principles and values behind delivering a well architected solution. You can abstract a huge amount of value from them, even if you don't embrace the services aligned to that cloud provider. It's the collaboration, questions, mindset and thinking that are good. And they are fairly consistent across whatever tech stack or platform you're leveraging. The questions are very similar. And the answers may be a little bit different. But even just asking those questions is hugely valuable. And as long as you apply it to your context, you can get a lot of value. I remember having discussions with people who were asking what architecture is? They weren't quite sure what architecture was and were trying to redefine architecture. With less technical colleagues, you need to give them a definition of what architecture is. When you compare all three Cloud Providers, they roughly have the same stuff. But AWS is driven by principles or tenets. A lot of the principles in the framework are applicable elsewhere. Azure is almost like a wizard as it takes you on a path, which is good 90% of the time. But I worry about what happens if that's not right for you. And Google sets the bar was quite high with hardcore SRE. The culture of each of the providers comes through. But they are all really good frameworks. With AWS, if you leverage a lot of AWS services, you're going to be EDA. So that is going to bias you towards operating in certain ways and leveraging certain ways of communication. Whether it's Kinesis, EventBridge or SQS SNS to connect things together. With Google, I am interested to see why they're focusing so much on SRE. Maybe there's a requirement on squads to look after resources when they are up, because it's more container oriented. The folks at Google perhaps believe that customer success is driven through proper SRE and operational excellence. A lot of the SRE principles came from Google. A cloud provider writes a framework in their own language. And it will have a bias towards their own products. So you need to see that and see the difference. And if you ask a cloud provider to do a well architected review on your product, a solution architect from that cloud provider to will come in and do it. And all they know is their products. So if you get an AWS solution architect to review your product, they'll start recommending AWS products. The lesson to learn is that it's not the framework that's important. It's the process that you put around it. And the process does not need to involve the cloud provider. We can run that ourselves. And we can apply the framework ourselves. It is a big shift, to use well architected as a benchmark to self assess to learn, measure and improve. The great advantage of doing this yourself is that your feedback loop is established. So you're actually seeing what works, what doesn't work and where your gaps are across all the different pillars. And where you should be investing your time and your team's time across the org. If you bring in somebody external, they won't have the context. And they're not going to be part of that feedback loop. When you use Clarity of Purpose, which is Phase 1 of the Value Flywheel, with the well architected framework, you can combat that bias. Your focus will be on solving the problem with the tools you've got at your disposal. And you're able to leverage tools faster and more efficiently. It should not be something that your architect does to you. This is something that the team should be embracing themselves through an iterative and incremental process. We've written about this a lot in our SCORPS process, which is in the book as well. It doesn't need to be a big, scary thing that an architect from on high comes down and imposes on you. It can be a very useful learning and enablement tool. Grady Booch Search for 'Grady' 'Well' 'Architected' to find that tweet and discussion SCORPS process on TheServerlessEdge.com. The Value Flywheel Effect book Twitter @ServerlessEdge Transcribed by https://otter.ai

What is the Second Cloud Transformation? In this episode we are talking about the second cloud transformation. A lot of people are talking about what happens when you get to the cloud? You have already moved to the cloud. But you are not achieving the cloud successes like being event driven or serverless. It can be a surprise for organisations that work in traditional ways. Their frame of reference is all on premise like big data centres or new mainframe stuff. So this new paradigm causes uncertainty around what can be done. What does a good cloud solution look like? Or what's a good implementation for your context? There's a learning curve that people need to climb and to become more comfortable. When companies move to the cloud, it's usually part of a transformation. But the reason why we call it 'The Second Cloud Transformation' is because there's another step change. The best person I heard describe this is Shaun Braun from 3M. He did a keynote at AWS re:Invent in 2021. He talked about people moving to the cloud and measuring data. And then they transform by shutting things down and redoing other things. Enterprises and people from mature companies are struggling. They are in the cloud but having problems with account creation, observability, security or how to deploy or provision things. There are infrastructure things that they haven't done. Because they haven't modernised. Sometimes the move to the cloud happens quickly. People have not been left behind. But they've been focusing on other things and they haven't gone back to first principles. To rethink how the software capabilities work. You need to move away from big upfront design. And shift design, decision making and architectural decision making onto the teams. Because they're the ones who know the business problem and business aims best. And safe space is a big thing. Situational awareness and creating an environment that is safe for the organisation. Because teams will make mistakes. But you have got to encourage experimentation in a safe way. A good enabler for that is thinking about and setting up policies for the services you want to start leveraging out of the box. In the second phase of The Value Flywheel Effect you map out your capability. So you do need to have an honest assessment of the capabilities you have and the teams in the organisation. Because maybe the engineers don't understand security. At least then you know that you've got to level people up. 'Shift left' is a great mechanism, because your teams have to do more and there's going to be gaps. So in some ways the second cloud transformation is filling those gaps. And you end up with well rounded teams. We talk about asking the question: 'what does good look like?' One of the best books to answer that question is 'Accelerate' by Nicole Forsgren.In the book there are four key metrics for building and scaling high performance technology organisations. Another go to book for this particular topic is 'Reaching Cloud Velocity', by Jonathan Allen. How to spin up new teams and the mitosis approach? It's a phenomenally good reference, similar to 'Accelerate'. And we reference both those books in our book 'The Value Flywheel Effect' which is available for preorder! When you get into the cloud you need to enable real transformation! This is what we are calling the second cloud transformation. TheServerlessEdge.com and @ServerlessEdge  Shaun Braun from 3M at AWS re:Invent Accelerate Reaching Cloud Velocity The Value Flywheel Effect Book with IT Revolution

We are talking about Event Driven Architecture examples today. There was an event in London a few weeks ago, called EDA Day. It was organised by GOTO with a lot of AWS contributors. It was neat because it was one day focused on event driven architectures. It showed the coming together of a 15 to 20 year old pattern of EDA, plus serverless. And all the bigger services on top of that, like Eventbridge and Step Functions. Gregor Hohpe's Keynote Gregor Hohpe did the keynote talk: 'I made everything loosely coupled. Does my app fall apart?' Gregor is an AWS enterprise strategist. And he talked about the event landscape and the complexities behind event driven and architecture. He had a diagram called: 'A calls B'. It looked pretty simple until you get to the million things you need to think about when A calls B! He said that there were three languages in a cloud native serverless domain. The business domain and how you talk about the business domain as a business person. The eventing architecture and how you talk about it as an architect. And the cloud native area, and how you talk about it as a cloud engineer. So DDD, event framework and CDK for automation. It's about having those three separate languages and how you talk. And bringing them together at the end. Serverless Espresso And one neat thing to mention is a developer advocate called Julian Wood. He's worth looking up on Twitter. He, Ben Smith, and a few others from Serverless Land, put together a demo called Serverless Espresso. You scan a barcode and through an event driven step function, event bridge sequence, you can order a coffee from your phone. It looks and sounds really simple. But you watch the whole thing happen. That's a great lab. So look up AWS labs, to see Serverless Espresso. It's well put together to show how you build an event driven architecture from the ground up. Ben Ellerby - Minimal Viable Migrations Another good speaker was Ben Ellerby. He worked in Theodo and is an AWS Serverless Hero. He has a thing about Minimal Viable Migrations. A lot of people think event driven is a greenfield or brand new thing. But he had a great talk about existing architecture and going event driven. He talked about doing a small part of your architecture and going bit by bit. By using an incremental model. David Boyne - Awesome EventBridge David Boyne joined AWS and does ‘Awesome EventBridge'. He has open source projects. And he does a great talk on 'Thinking Event First'. How to approach events and get your schemes right. And really think about your domain model and lock it in from day one. So he's got a bunch of tools as well. So it's worth looking up his resources on ‘awesome event bridge'. Marcia Villalba - FooBar Serverless Another great speaker was Marcia Villalba. She's one of the developer advocates at AWS. She's got great content on good practices and getting started. She has a really nice way of explaining these concepts. There is one thing I get nervous about around event driven and domain driven. People who are good at it tend to get very complicated very quickly and lose everyone. But Marcia's super at bringing these concepts across and helping normal teams, which is every team. Check out her FooBar Serverless YouTube channel. There is tons of developer friendly content from beginner to more advanced. It's one of my YouTube subscriptions that I watch quite regularly. Lego Talk - Sarah Hamilton and Sheen Brisals The last one to talk about is Lego. They sponsored the event. And they had two talks. Sarah Hamilton is one of the software engineers and she gave a really good talk about the advanced techniques they're using in their event driven architecture. My friend, Sheen Brisals was speaking as well. They have a fantastic story, which is well worth listening to. It's about how they moved to an event driven serverless architecture. There's a socio-technical element to this. How you organise your teams and the attitude is what I would call a core engineering competency and mindset. As opposed to an architectural pattern. Lego tells their story brilliantly. Product Leader panel The event ended with a panel of product leaders from Eventbridge, Step Functions and MongoDB. It was a really relaxed panel. Emily Shea, who we know well, was there. She works in go to market for serverless. It was a relaxed chat. No one was pushing any tools. They were shooting the breeze on good practice and what's coming down the track. The evolution of event driven architecture and the tie in with serverless. There's something in it! I don't want to say Serverless is becoming EDA or EDA is becoming serverless. But serverless enables EDA for sure. https://gotoldn.com/ https://theserverlessedge.com/ https://twitter.com/ServerlessEdge  

AWS Serverless Services with Paul Swail from Serverless First In this episode the team talk about AWS Serverless Services with Paul Swail. Paul is an independent Serverless Consultant working with and helping teams get started with serverless on AWS. The Value Flywheel Effect Book Review Paul also reviewed our book The Value Flywheel Effect. The team talk about his views of the book. And the fact that it is essential reading to get higher level buy in to serverless in your organisation. Serverless Mindset versus Serverless First We talk about the difference between the terms serverless mindset and serverless first. And how it is essential to be pragmatic in your approach and not insisting that serverless is the default for all your architectural decisions. It is better to use serverless as the architecture or service of choice. And then fall back to non serverless or less serverless services for certain parts of the architecture. Wardley Mapping your Tech Stack Wardley mapping and mapping your tech stack became really useful. Because you can see the individual components that can be moved to serverless. Instead of insisting the whole thing must move. The origin of Serverless Ben Kehoe came up with the term 'the serverless spectrum'. And it captures the notion of falling back. You can see if you have fallen back to things on one side of the spectrum. Leading with Context There's a fundamental thing with developers. Generally, they identify with the technologies they've use frequently. And they get really attached. And fanboy/girlism kicks in as well. There is a natural tendency to do that. Before your rational mind kicks in and says hold on. What is this? And what are the drawbacks of this? Or what sort of context would this not work in? Context can be vague I split it up into the application context of the actual system. What are the features or operational, latency and performance concerns you need the system to have. And the actual organisational context. The first application context is usually known. People know that they are building a specific app. It has these features and these requirements. But the second organisational context is what developers do you have available to you? What skill sets do they have? Are they developers without ops skills so we need to hire infrastructure folks. Or do we have infrastructure folks, and they might not have much to so because we're using serverless? These things need to be considered when you're adopting technologies for a new project. Keep it simple It's the worst thing in the world, when a senior engineer builds something really complicated because they are smart. However, the beauty of a good system is simplicity. It is worth going the extra bit to get to simplicity. And don't overcomplicate things just for the sake of it. I don't you know if it's an ego thing, but sometimes people build things are way too complicated. If you're the architect you need to imagine yourself not being there for two months. How will the team fare? Have I designed a system that's simple enough if they hire a new developer in the meantime. When I'm not there to get them up to speed. Serverless Maturity We have reached maturity in the serverless ecosystem. Developer advocates are starting to codify and articulate their patterns. We have CDK patterns and things that are Google-able. Teams can reach out to see how to do it in an API gateway, lambda or dynamo. And see videos, tutorials or documentation of workshops that are maturing and established. AWS effectively becomes a platform team, if you follow the serverless first approach. And they're going to keep investing in making it easier and adding more features and capabilities. How will Serverless evolve? One reason for being attracted to Serverless in the first place, was as a developer you are working close to the product. Full stack developers build a front end and back end. But you can have a team of one back end and one front end developer. And they do everything. So tools that optimise for small teams to get stuff done are essential. Like operational stuff or standardised CICD pipelines and testing mechanisms around that. There's a lot of good work being done on the friction that serverless had over traditional app development. And having to deploy to the cloud locally and making that fast. I think it will continue to get better for individual developers. By creating stuff that would otherwise have complex AWS nuances. Because it's a big overhead for for developers to learn without AWS certifications. ServerlessFirst.com and @PaulSwail TheServerlessEdge.com and @ServerlessEdge The Value Flywheel Effect Book with IT Revolution

What is Long Term Value? We've spent the last couple of episodes talking about the value flywheel effect and the value flywheel itself. There are four phases: Clarity of Purpose, Challenge, Next Best Action and Long Term Value. We've been talking through each of these phases in detail. And today, we're going to talk about phase four, which is Long Term Value. So the simple question is, what is long term value? Long term value means continuing to deliver value for the medium to long term, because you've invested in a sustainable way of working. You have invested in well architected and paid down your technical debt to get long term value. And you're not going to hit a wall in the short term, because you've not built in quality or architected appropriately or built a sustainable solution. As you go forward make sure that all of your systems are built to deliver long term value. You have got to have that rigour of discipline. And you have got to do it continuously. You can't decide to just do it at the end. It's got to be baked in. If you don't invest in long term value and the well architected framework, you'll hit the wall. You might go fast for a quarter or two, or a sprint or two. But sooner or later, it's going to catch up to you. You may be going fast and delivering value, but you're not doing it on a sustainable way. You're not paying down those debts. And you're not building things that are resilient, scalable, performant and cost effective. You may go fast for a few months or even a few years. But eventually it catches up with you. And then you crash, you stop and you can't deliver any value anymore. If you invest in this, your team are thinking about delivering differentiating value instead of firefighting. You're solving issues and trying to see why things don't work or resolving customer issues. Because you've invested in this you have capacity for impactful, meaningful and differentiating work. And not just run work or busy work to keep the lights on. The challenge is getting teams embedded into it. And getting them into the right cadence and adopting it. But when that happens it frees up architecture. And it give teams more autonomy. It fuels the overarching pyramid. When you're looking at broader cloud controls and constraints. And building a more functional, productive organisation, it drives all of that. You don't have to have an architect on every squad. You can scale in that way. It's all about efficiency, throughput and looking after the longer term. What happens if we don't do it? You see teams in a false economy where they get their first or second build done quickly. But then things start going wrong. And you build up technical debt very quickly. Things start to go wrong. You end up firefighting. And it really slows down. It's the perfect velocity thing. You start off quite fast. But it starts to slow down rapidly as things start to creek. Is there anything else you can think of that happens if you don't think about this? Your business, execs and key stakeholders start to wonder why am I not getting value out of meetings anymore? Where's the next differentiating capability? And where's my next feature? Or my next capability that can differentiate us in the marketplace? I've got the same teams and they were good last month. Why are they not delivering this month. Or they were good last year? Why are they not delivering this year. You'll have a lot of noise from the execs wondering why is it not working anymore? The problem becomes the dreaded rewrite a couple of years in. And realising that this big ball of mud just needs somebody to take a sledgehammer to it. You turn around and talk to your stakeholders because you are going to want to do next generation version of this. It's going to be brilliant. With all of the same functionality. But it'll be better. And the response is: 'why would I pay you to build it again? You built this five years ago, why are we building it again?'. That's a very difficult conversation. And the real answer is we didn't bother doing architecture, so we have to build it again. That's not a good place to be. A team that's leveraging and operating the flywheel will see their software appreciating in value over time. As opposed to depreciate. If you're not thinking about long term value your system is always depreciating. You are going to have to invest in patching, upgrading and dealing with issues. The terms we use are 'code is a liability' and 'the system is the asset'. You need your teams focused on the system delivering the value. And removing as many code liabilities as they can. And this phase of the value flywheel is about minimising liabilities and offloading more responsibility to the cloud provider. Or how can we leverage managed services and SAS providers. To remove custom build and evolve into a commodity. So all of those things are at play in this phase of the value flywheel. Serverless Craic from The Serverless Edge theserverlessedge.com @ServerlessEdge

We've been going through the Value Flywheel Effect in the last few episodes. And talking about the different phases. The Value Flywheel is the core mechanism we talk about in our book. There are four phases. The first is Clarity of Purpose, then we have Challenge, Next Best Action and Long Term Value. Today we're talking about Next Best Action. When you boil it right down, you've got understanding, your Northstar, Clarity of Purpose and you understand your landscape. But how do you start? What is the next best thing you can do? What is the simplest thing you can start today to improve your lot. And help the flywheel turn a little smoother and remove some inertia barriers. In very simple terms: what is the next best thing you can do today, tomorrow or this week. Conceptually, you need your next best action to be focused on business value. And not focused on building a huge platform. Or spending the next six months organising runtime or infrastructure strategy. You need to get going and start adding value as quickly as possible. There are two things to consider: a frictionless developer experience, so your engineers can create value very quickly. And a serverless first mindset, how you decide what choices you make. A serverless first mindset is selecting a serverless option first, when you review services and techniques to use in the cloud. A lot of people think it's a maturity cycle so they start at the bottom. Let's build it and work our way up to serverless. But it should start with serverless and working your way back to a fallback mechanism. In a nutshell, you should be renting all services in a managed service or serverless style. It's not common place yet. But it's something we've had great success with. It's trusting your cloud provider platform to have the capability to do something. And just use it. We've all seen teams that have a problem to solve go off and write a fra Next best action implies responsiveness and speed. It's not about how quickly you type code. It's a time to value. How quickly you can get value in the hands of customers to see if it works. Code is a liability. By mapping out your tech stack and adopting a serverless first approach you can tackle those code liabilities. So you're not going to be hit by old systems that have been left to decay over time. And when you need to make rapid changes you can't respond because you haven't paid down your code liability. Mapping your stack and embracing serverless helps to minimise code liabilities and get you on the right path. What happens if we don't do this? We call it the framework mentality. Someone decides they're going to write a framework and they can do it over the weekend. And that becomes the foundation for the next big project. You get version one into production and everyone's really happy. This developer is a rockstar, because they have rocked out a framework. But a year later, that framework is the very thing that's slowing down the project. And no one can understand why we did this thing in the first place. So if your next best action is let's write a framework, it's not the right idea. Sometimes quick fixes in your first release in code will absolutely slow you down in future releases. We're now at a time where you can use your provider for an atomic service or capability. And just use that and don't worry about what's behind it. It's like the domain driven stuff. They're enabling constraints, rather than constraints that slow you down. If your next best actions are always around patching, upgrading, hardening or getting ready for scale, you're not delivering business value. You need to adopt a serverless first mindset and approach so that your cloud provider is basically your platform team. Who are constantly upgrading, making performance improvements and making things more secure. And you're getting all that for dollars. You're focusing your time on differentiated stuff. On delivering value, outcomes and impact. If your next actions are always around hardening, patching and securing, you need to think about what you can do to minimise that in the future? If your next best action is to fix the infrastructure and you're not an infrastructure company, then you've done something wrong, it needs to be something about your own business value proposition. Serverless Craic from The Serverless Edge theserverlessedge.com @ServerlessEdge

It's important that engineers challenge tech strategy. We talk about Challenge in our book: The Value Flywheel Effect. In a previous episode found we went over the Value Flywheel in general. There are four phases: Clarity of Purpose, Challenge, Next Best Action, and Long Term Value. Today, we're going to deep dive into Challenge, which is phase two. Challenge is about the environment. When you decide on a strategy, do you have the right environment to challenge it? We've found this to be hugely important. In the last episode, we talked about Clarity of Purpose and setting direction. Part of bringing people along with you, is creating an environment where they can question purpose and challenge direction. But also, it's doing it in a safe and constructive fashion. You don't have your architecture leaders setting the direction and imposing it. You need to do it together. And you need to do things in a collaborative and facilitated to invite challenge. Techniques we use like Wardley Mapping, Event Storming and Threat Modelling are done as a team and collaboratively. People have an opportunity to challenge the process and artefacts. They're not challenging the individuals. That's very important. Because you need to have a good feedback loop. To understand if it can be better. Or if this could be improved. In high performance organisations in the cloud, things move very fast. You can't know at all. Challenge is about engineers. Our greatest engineers know the nuts and bolts and the nooks and crannies of the system. If you silence their voice, you're going to lose a huge amount of value. If you create a good environment, your engineers can point out where things won't work. Or bring new ideas to the table. You get richer system. So design your organisation and your tech around the ability to challenge. It's absolutely critical. Architects and senior leadership teams are there to enable and empower teams to deliver the best outcomes they can. It's about flipping the hierarchy. The team is at the top of the pyramid. And from a hierarchical point of view, we're there to enable and support. If you hire smart engineers, your best technical strategy is to get out of their way. Make sure they know what the goal is, and get out of their way. You have got to put in the right support systems to make sure people can work effectively. In traditional leadership, there can be a struggle. The team is carving out their own way and traditional leaders don't like that. But if you hire smart people, you need to let them do the work. You need enabling constraints as well. To guide engineers along the path. You need to enable teams to grow really fast, but you want to do it in a secure and well architected way. So that you're not going fast and creating lots of technical debt. Part of an environment for success is making sure guardrails are in place to enable engineers go fast responsibly. A big part of this is understanding where we are on the journey. By mapping your org capability and environment you can see if you have the capabilities to set you up for success. And if you have expertise for secure development, Wardley Mapping or Serverless, for example. If you don't then what are you going to do to get them in place for your teams? The last thing is pathway to production. By making sure you have a rapid feedback loop into the hands of real users you're part of an environment for success. Because you are removing impediments to the flow of value to end users. You have a well oiled pathway to production. So you're not waiting months and sometimes years for feedback on the things that your teams are working on. What happens if you don't have a good environment for challenge. You'll start to see people disengage. They'll feel that they are not listened to. And they will leave eventually. Especially if they're talented engineers. If they don't have an avenue to challenge, contribute or give their opinion, then that lack of engagement will drive them away. Also you're not getting the best out of your teams. You're not going to be able to meet your Clarity of Purpose. Or your goals because the teams are following a plan that was decided in advance. So there is no push back on that. You will see frustration and people will not feel part of the process. Team interaction modes will be suboptimal. Lots of teams will do the same things. There will be repeat work because there's no way to challenge. You'll see teams competing with each other. Instead of enabling and empowering each other. There are two systems. The system of all the employees in the company. And then the system or the technology we're working on. You have to bring those two together and look at them through the same lens. And that's something that I think architects have to do. Serverless Craic from The Serverless Edge theserverlessedge.com @ServerlessEdge

We are looking at how to apply flywheel strategy from our book 'The Value Flywheel Effect, which will be published on 29 November. In the last episode we spoke about the whole model and the four phases. They are Clarity of Purpose, Challenge and Landscape, Next Best Action and Long Term Value. This time we figured we'd deep dive into Clarity of Purpose. It's the first phase of the flywheel. It's about knowing where you are going. And where you want to go next and what your purpose is. Are the things you're working on meaningful and valuable?  There's an onus on senior leadership and/or the CEO, to make sure this is understood. Purpose is what is your business going after. And clarity is are you specific about that?  Is it measurable? There's a lot to unpack in that phrase. If we don't have clarity of purpose, we don't understand the problem we're solving or what our users needs are. We can't make good decisions with regards to the work we carry out. Or where we invest our time or resources to meet those needs. It's critical if you want high performance, autonomous teams. But if they're not aligned behind the clarity of purpose, they will go in different directions. And they won't have the impact you think they should have for your organisation. You have got to prioritise decision making, because we don't have infinite capacity. Without clarity of purpose, it is just making stuff up. Because it doesn't really matter what you do! And secondly, execution without clarity of purpose is just busy work. You are just going but you don't know when you're done. In some companies they'll build something because someone else built something. And sunken cost fallacy kicks in. Because they have no clarity of purpose, they can't measure success appropriately. So they tend to invest in something that's already failed. But knowing when to stop and when to try the next thing is a core rationale for solid clarity on your purpose. Situational awareness is critical. Having the data to backup, your purpose with key metrics that you're driving towards is critical as well. You need to make sure that what you're doing is influencing the right metrics. And all aligned to your purpose. As an IT person, you can come up with a million good ideas. But you've got to be prepared to say no. This is not going to have any impact. Or this is not going to affect the bottom line. This is not going to manifest as a benefit for what we're trying to do in relation to our Northstar. But what happens if you ignore it? It's not default or mandatory. You don't have have to get into it. I remember being asked to stop talking about why we're doing stuff and just do it. That wasn't healthy. Organisations don't become healthy. They don't become places where people want to have an impact. Instead they'll turn up and clock in the hours. But they won't move the org forward. Teams begin to solve the same problems. Because there's a lack of collaboration and people aren't communicating effectively. It becomes difficult to prioritise and organise across teams. Which is another side effect. You start to guess at things. And build stuff for the sake of building. And not focus on the overall outcome. We have talked about innovation theatre. Where the execs, all of a sudden, start wearing sandals, sports jackets and no ties! That's not innovation. It's innovation theatre when you start putting stickies on the wall instead of using documents. They are the traps you see people fall into when it come to innovation. Another one is the build trap. When your teams building like billy oh. But nobody knows why they're building or what they're building. And then you have what we call gold plating. You get into a big ball of mud, where engineers went crazy building a complicated system. And then all of a sudden, you need a simplification programme because it's too complicated. Or you need a reuse programme because you've built the same thing four or five times. I always think that startups are good at clarity purpose. Well, the ones that survive are. The ones that don't survive, probably had a bad clarity purpose. That's the final answer to what happens if you don't have clarity of purpose. Over time you go out of existence! Serverless Craic from The Serverless Edge theserverlessedge.com @ServerlessEdge

Our book 'The Value Flywheel Effect' is being published by IT Revolution Press on 29 November. We thought it might be worth having a chat about what the the value flywheel is. It is something we have painfully discovered over many years of working. Things really start to work well, when you join the business and technology strategy. We came up with this model to describe how you do that in a company. There are four phases. Phase one is 'clarity of purpose'. Phase two is 'challenge'. Phase three is 'next best action'. And phase four is 'long term value'. So we will deep dive into each of these in our next set of episodes. But for now, we will quickly go through them. Clarity of Purpose So the first phase is 'clarity of purpose'. Clarity of purpose is a very difficult thing to to establish. Business and IT need to look at 'what is our mission'? What is it? How can we add value? What is it we want to do? Does everybody understand it? Has everyone bought into it? In your organisation, how do you prioritise, how do you make a decision on what you should do over something else? How do we establish that clarity of purpose? It's about getting alignment as well. And trying to clarify what your clarity of purpose is. Or what your North star is. And what your key input metrics are. They are valuable conversations to have. They spark off good thoughts and conversations with people on teams. And it doesn't need to be perfect. It just needs to start getting alignment and people pointing in the right direction together. It's not what your boss says!, Your boss should explain what the clarity purpose is, but they may not. So don't blindly follow what your boss says. And then the second thing that it is interesting for an engineer or developer, is that your purpose is not to write code! You don't come to work to write code. You come to work to achieve clarity of purpose for the team and the company. Challenge The second phase, challenge, sits well with that. These first two are very much linked to the business strategy. And challenge is not to argue with the clarity of purpose. Once you're clear on the clarity of purpose, it's then what do we do to achieve that? That's when you need a healthy environment. Where there's challenge. Not have a fight with someone. It's a form of verification. We've decided the priorities and these are things that we're talking around. But what's the what's the best way to go about it? Let's have a conversation around that. Look at the landscape and evaluate our position. Are we being realistic? Good conversation and rationale go into this phase. Do we have an environment that invites challenge? You need to make sure that socio technical systems are set up. And challenge is invited and not punished. Are people getting a chance to challenge? Are we bringing in the experts? Who should we be talking to? Where's their voices? That's where Wardley Mapping is a powerful technique, because you're challenging the idea and not the person. You're not challenging the individual telling the story, you're challenging the approach. It's healthy and it promotes psychological safety. Next Best Action The third phase is next best action. And this is having a bias for action. What can you do quickly, to prove your direction. This is where serverless comes in. It's the rate of turm. How quickly can you make change? And how quickly can you get change into the hands of real users and customers? Or how quickly can you have an impact? Sometimes you have good priorities, you've challenged and you know what you want to do. But then it can get locked up in technical bureaucracy. It's removing those impediments to fast flow. Can we quickly get an idea into the hands of real users to get valid feedback. It's a very important phase for the organisation to embrace. We got into it in the book, which is great. If you've got an urgent business problem, you don't want to be off doing low level stuff. You're never going to get to it. So how can you make progress? Well not quickly! Long Term Value The fourth phase is long term value. It's about bringing in architectural and sustainability standards. How can you go fast without burdening yourself with lots of technical debt? And how can you go fast and at a sustainable pace? Or how can you deliver a well architected solution? With capabilities that enable the flywheel to turn faster. And it doesn't clog everything up and slow you down. Once you get to that, you're back into clarity of purpose again. And it keeps going. What we've found by going through these phases, is that each time you get better at them. You keep revisiting and you keep improving. As you turn the flywheel, you create more space for innovation and emerging value. You will start to spot where you should invest next. It becomes becomes a good muscle that you can exercise. Serverless Craic from The Serverless Edge theserverlessedge.com @ServerlessEdge

Clarity of Purpose with the North Star Framework For many teams, trying to figure out why you're building what you're building is a good question to ask. I have found out in my career that most teams don't really understand why they're building what they are building. It's interesting to look at the models for creating great software, like The British Design Council and the Double Diamond. On the left is discovery, and on the right is delivery. So discovery and delivery. We always talk about delivery. We obsess over it. We very rarely do product well, or discovery well. And a good product is really about discovery. One person who has nailed it is Melissa Perry. In her book, 'Escaping the Build Trap', she talks about people blindly building. And building backlogs It's comfortable for teams because they are in their groove. And they knock out another widget, ticket or feature without thinking about the impact and who it's actually for. Get the JIRA tickets closed, get the storage complete, get the sprint done, and move on! There are a lot of frameworks to talk about. But generally people don't know. The move from project to product was supposed to fix this. But I don't think it has. Because product managers have people building things like 'billyo'. But often they are building the wrong thing. A great saying is: "Build the thing right, build the right thing, build it quickly". We're good at building quickly and good at building the thing right. But we're not very good at building the right thing. And that's what breaks companies. Because building the wrong things can be expensive. For a number of years, the work we've been doing is streamlining development processes and building high performance teams. But we can fall into that trap as well. Here's all the patterns and automation that you can leverage. Just go hit that button. But you need to make sure you always take a step back and ask, what's it for? And who is it for? If you don't understand the impact you're trying to have, how can you do the right thing? Or build the right thing? How can you know what success looks like? What conversations are you having on potential approaches and ways to achieve that success? It all ties back to data, metrics and understanding the problem you're trying to solve. If you're not doing that, it dilutes the good intent of good teams and engineers. How can they build the right thing if they don't understand what success is? Or the problem they're trying to solve? And what are our options? It's a challenging thing to do. The frameworks on mindset and helping you think in the right way, lead you to what you need to solve. In 'The Value Flywheel Effect' book, the first phase of the value flywheel is 'Clarity of Purpose'. We base that on a leader persona, like the CEO. In other words the person who needs to drive the purpose. One thing we find helpful, which is not well understood, is the North Star Framework from Amplitude. We discovered it a few years ago. And it collectively blew our minds. We have used it ever since. It's a neat framework. One thing to note are the leading and lagging metrics. The four disciplines of execution was the first version of understanding lead and lag metrics. And how you can build the work into a Northstar metric and then a long term goal. It's a simple framework that people can get in an hour long session. Your teams can share and collaborate. And online collaboration tools have helped make this a lot easier. You don't need to be physically present. You do it online, which is great. We tailor it a little bit with pre Wardley mapping tools on 'what's your scope and what's your purpose?'. Your users and their needs sets the context leading into the Northstar. It gets everybody back on the same page if they have forgotten about a user. Or if they have forgotten that they do something for a set of people and their needs. One big thing we've noticed with this and Wardley Mapping is that it invites challenges. You are not challenging the person or the team, you're starting to have a conversation about North Star metrics, KPIs and the work aligned to that. You're not challenging a person. It provides a safe space for the right challenge to happen. I like the lag and lead measures concept. Development teams keep themselves busy sometimes, chasing vanity metrics. And gamification of vanity metrics is fun. But in actual fact, what you need are lead measures. What are the things that impact business success? They are the lagging measure. I love the traceability of the Northstar. You can go from business metrics back to your work. Or you can go from your work to the business metrics. I think that's the real power behind it. Melissa Perry: 'Escaping the Build Trap' Marty Cagan: 'INSPIRED: How to Create Tech Products Customers Love' Amplitude: The North Star Framework Jon Cutler Simon Sinek: 'Start with Why' & 'Golden Circle'.   Serverless Craic from The Serverless Edge theserverlessedge.com @ServerlessEdge

Today, we decided we'd have a chat about the 8 principles or tenets for a high performance serverless first team. 1. 'Chase a business outcome or a KPI' A team should know what business KPI they're working towards. You should be able to tap a person on the shoulder and have them tell you what they're working on. And what business impact the work they're doing is going to have. If the team says 'I don't know', then you run a Northstar workshop. After the Northstar workshop if nobody can think of a KPI then the next step is to ask if the team should be doing this work. It's not that they are a bad team. They are being asked to do the wrong stuff. 2. 'Be secure by design' Don't do security afterwards. Bake it in from the start. It's everyone's job. It's such a difficult thing to retrofit. Use threat models and get it done early. Try to solve for what you can and what you know. Bake it into all your engineering practices. And bake it into your pipelines. Shift it all left and help to enable teams to be more secure. Security has a risk profile, if you don't do it right. And it can be an existential risk for the businesses if you don't have a secure solution. 3. 'Keep a high throughput of work' That is borrowed from the DORA metrics in the 'Accelerate' book by Nicole Forsgren. This principle looks at high throughput, which is deployment frequency and lead time. For serverless teams, it is key to make changes fast and frequent. And always be learning and driving observability. As Charity Majors says, "speed is stability". The more frequently you do something, the more you deploy to production. You're actually improving your stability. You smooth out the pathways and the error conditions. And you bake it into your pipelines. Which means that you automate a lot of the stuff that could go wrong. 4. 'Reliably run, high stability system' That's the other two DORA metrics of throughput and stability. A lot of discussions with test teams, QA and software engineers drive the need for investment in world class quality and testing capabilities/practices. If you're not stable, where's the gap? What scenarios and behaviours have you not covered? It drives the right evolution. When you look at three and four, you can't achieve any of them if you've got things in the middle. Or handoffs, or if you are dumping things over walls. It's about promoting ownership. To get elite scores, you need to know what you're doing and embrace that approach. 5. 'Rent or reuse with build as a final option' How do you do that? Serverless! With Serverless and SaaS and our background you're used to going straight to the workspace. And with the FORESEE diagram, we find out what we are doing and it is coding. It's a mindset thing. It's back to knowing your business purpose. And then knowing your business KPIs. If you can achieve business outcomes without doing code you are at your most optimal. If you can leverage a SaaS offering that does what you need, that's probably the next thing. And finally you need to build following a serverless first mindset and approach. Using all the serviceful offerings and managed services. 6. 'Continuously optimise the total cost' This is the best question to ask any team. Good teams will tell you how much their cloud costs are. But loads of teams have no idea. This is a great measure of a good team. They have a cost in mind. A good team will tell you the run cost. And a great team will tell you the total cost. But really good teams will get into a worst case development conversation about how much features cost. And how much revenue they're bringing in. In other words, how impactful they are to the business. 7. 'Build event driven via strong API's' This sounds very easy. But from talking to Sam Dengler, nobody is doing this properly. We've been talking about this for 20 years. Proper integration is still a mystery to most people. It is about making sure you've got the right things in the right places. But also at the right size. And having things that are composable. It's about breaking things up into their smallest constituent parts. And change things as frequently as possible. I find that this one takes a lot of evolution and yields through different levels of complexity. And it takes time. You should always be thinking about it. 8. 'Build solutions that fit in their heads'. This principle is borrowed from Dan North. In other words, don't build crazy systems that are too complicated. This has a nice nod towards Team Topologies and setting proper boundaries. We've seen teams become victims to crazy architectures. Where there's too much to fit in your head and the cognitive load breaks people. When we are getting teams going my manta is 'just enough design'. Some teams want to design everything up front and go into huge amounts of detail. But it is better to keep your world small. Focus on what you're doing today. Serverless Craic from The Serverless Edge theserverlessedge.com @ServerlessEdge

We found out that 'how to start cloud computing' is a burning issue! We started a meetup in Belfast with our friends Matt Coulter, Gillian Armstrong, Gillian McCann, and Gareth Gilmore. It is called BelfAWSt. And it is a community Meetup in Belfast, to talk about all things AWS! We saw from looking at the topics and listening to the conversations that there is a need for guidance on how to get started! How do you set up your account? And how do you learn? Or build your career? Who do you reach out to? And when you are more familiar with the basics, what can you leverage to build higher order systems and solutions? Questions on certifications came up a lot. Are they valuable? What workshops can guide me through the Getting Started phase? How do you become part of the community to help me and my organisation? It is daunting when you look up aws.com and there is an ocean of stuff on the website. If you sign up, pick something relatively straightforward and follow a quick lab. It's an iterative process. 'Eat the elephant, one bite at a time'. The pathways of education and certification have been broadened to meet different user needs. 'Cloud Practitioner' is great for somebody getting started, who wants to understand what capabilities are available. When you get to associate and professional, the specialist certifications are more in depth with a bigger learning curve. From an educational track point of view, what I used was 'A Cloud Guru'. More recently, 'Skill Builder' has become freely available. Udemy courses are really good. So there's never been a better time to learn about the Cloud and AWS. And other Cloud Providers have similar educational materials. But the stuff that's freely available now is just fantastic. T he thing I really like is that they have foundational white papers. There's a white paper on well-architected. And there's 'secure by design', principles of cloud and elasticity and ephemeral behavioural stuff. So there's four or five core white papers that are worth reading. And you can tell the people who don't understand those concepts, because everything is built upon them. If you attempt a certification, and you read those white papers, it's still beneficial. The PDFs are free and you can download them. It gives you shared understanding across teams. So if you're a manager, not hands on or technical you will have the vocabulary to have a conversation with your team. It could be about scale or services. But it allows you to be better informed and have greater situational awareness. With certifications, you can go deep and broad on a lot of the topics. But real learning happens when you go and do something. Get into a workshop. Go and follow an AWS workshop or whatever cloud provider workshop applies to you. That's how stuff tends to stick with me. The developer advocates and AWS have been great at codifying their getting started workshops. Workshops that were only available at re:Invent/conferences are now freely available on AWS.workshops. The community is also good, with AWS heroes, community builders, and developer advocates. And it's actually quite a small community. It's a handful of people who are putting out good content. And it's not that hard to track them down on Twitter. It's worth tapping into that community. The last thing is the whole idea of patterns. Matt Coulter has CDK Patterns. SAM has a bunch of patterns. And there's the Serverlessland.com site. When you codify an architectural pattern, like a CDK pattern, it's a great way to accelerate and get something up and running. But also to look and see how the pattern was put together. It's a brilliant way to learn. You may want to wire capabilities and services together. For example you wire an API gateway with a lambda and store data in DynamoDB. There's a pattern for that. You can see how it's done in a well architected way. That frees up resources to build solutions that deliver value. Patterns like CDK and Serverlessland help. They are built on developer enabling frameworks. Some are built on CDK and some leverage SAM or the serverless framework. They are good to play around with. And to develop your preference to help you in the long run. You don't want to be doing things in the console or coding in raw CloudFormation. It's never too late to start learning. I would argue that the later you do it the better! Because the early stuff is a bit funky. This later tech is more refined and mature. Patterns: http://serverlessland.com/ https://cdkpatterns.com/ https://www.cdkday.com/ Edu: https://acloudguru.com/ https://www.udemy.com/ https://aws.amazon.com/certification/ https://explore.skillbuilder.aws/learn https://workshops.aws/ Community: https://aws.amazon.com/developer/comm... https://aws.amazon.com/developer/comm... Other: https://bahr.dev/2020/12/02/surprise-... https://www.youtube.com/watch?v=ryXnj... https://theserverlessedge.com https://twitter.com/ServerlessEdge

To help you become an awesome software architect, we have picked out our top four books to make 12 in total. We are looking at engineering books have influenced both ourselves and 'The Flywheel Effect' book. 1. 'Continuous Delivery' came out in 2011. And it has been massively influential in how high performing teams deliver their software today. It is still as fresh as it was when it was written. And a lot of teams would do well to actually read it again. 2. 'Domain Driven Design' is a good book on how to describe a domain, good domain models and the importance of collaboration, communication and shared understanding, including their chapter on ubiquitous languages. You can be in different types of stacks or scenarios, but the knowledge is abstract so it's broadly applicable. 3. The Simon Wardley Book I have got a print copy of it. And I find myself always coming back to it. I think it was out in 2011. It's chunky and quite academic. So it's not exactly an easy read. But it's as deep as well, as they say. So I'm a big fan and I always go back to it. I don't take every word of it literally. But it's definitely a good read and will challenge your thinking still to this day. 4. 'Accelerate' by Nicole Forsgren, Jez Humble, and Gene Kim. This is a game changer. I think everyone the industry understands that. It distills down and captures (with scientific backing) all of the things that we were trying to articulate or were trying to push or evolve in our ecosystem.The capabilities to drive improvement, the scientific backing and little snippets of good advice and guidance. It is one of the best. 5. 'Extreme Ownership' by Jocko Willink. There's some cracking guidance on how to own something and lead. One that sticks out is centralised command and leading up and down the line. It's a well thought out and structured book on how to think, modern leadership and how to motivate people to be successful. I enjoy reading about how to think through systems, particularly in a leadership position, in technical orbs and stuff like that. It helps you to think like a leader. 6. 'Team Topologies' by Matthew Skelton and Manuel Pais. It's such a powerful question to ask 'what type of team are you?' And the response is: 'what do you mean?'. The answer is that you're a platform team, an enablement team, a value stream team or you're not anything. And all the techniques are in it with different tools and team API's and stuff. I think it's really practical. You can pick it up and implement tomorrow. 7. 'Reaching Cloud Velocity' It covers how to succeed in the cloud. In other words what are the principles and tenets that you should apply. What are the cultural and organisational things you should think about as you're starting to move to the cloud. It looks at the architectural approaches and patterns you should adopt. And how to do security and governance. It also looks at what's your business strategy, now that you're in the cloud. 8. 'Designing Data Intensive Applications' is almost a bible for anything data related such as streaming, different types of databases and why you make decisions on certain types of databases. You get into the design and the nuance of it. And understanding the landscape. It's broken into 2 to 3 minute blocks. So you can get straight into it and get perspective or context. 9. 'Creativity Inc', by Ed Catmull. The book is about Pixar, who went up against Disney by direct selling films. The full title of the book is 'Overcoming the Unseen Forces That Stand in the Way of True Inspiration' . They talk about the inspiration of creating and then actually making it. And how they structured the company and all the challenges they had. 10. 'Working Backwards' by Colin Bryar and Bill Carr. We see Amazon from the outside eg. amazon.com, Amazon Prime, deliveries and Alexa. But how do they actually do it? How can they be so successful and set themselves up for success? What way are their leadership structured? 'Working Backwards' distils down and gives insight into how Amazon operates at that sort of scale. It looks at how they have remained successful despite their growth. 11. 'Ask Your Developer' by Jeff Lawson, looking at the developer centric approach at Twilio. There's a lot of good content on how to inspire great individuals and teams to be creative. There's a good chapter on developer experience, their golden path and off roading. And how they've organised around developer experience. 12. 'The Software Architect Elevator', by Gregor Hohpe. I love his concept of an architect riding the elevator to talk to the executive in the penthouse, going down to the basement to write code and then all the floors in between. He talks about the how an architect can behave and operate to be successful in a company. Gregor is the 'architect's architect'. Serverless Craic from The Serverless Edge theserverlessedge.com @ServerlessEdge

This is the sixth and final piece of our Modern Cloud series. Modern Cloud has to represent value for the different personas across the business. The customer is an obvious one. But it's good to talk about internal stakeholders. The CEO and Product personas are very interesting. I think we were happy talking about the Developer and CTO/Architect perspectives. They are our personas! Wardley Mapping guides us towards our users and their needs. Having those conversations and distilling that down helps us with our thinking. And to articulate the benefits. What are the good approaches for 'time to value'? And to realise the potential of modern cloud ecosystems. It's been useful to talk and clarify the mental model of what the cloud is and what it can be. And what benefits teams and organisations following this path can get out of it. This has been democratised globally. If you pursue this properly, you can compete with anybody in the world. When we started talking about the cloud we thought about building ephemeral event driven architecture. But our CEO was thinking, can you be faster and cheaper? It became a value proposition. Remembering some of those things is important! You need to keep that commercial lens as you design applications and processes. And as you build up teams. One thing that is interesting (we've been talking about it for a long time) is the term 'serverless'. We have done a lot of work on the concept of serverless first. And I think it's a strong strategy. It's very powerful. But the serverless term itself is problematic. One of the reasons why we use the term modern cloud is because Serverless has turned into a type of religious war. When people hear the word Serverless, they think of Lambda. But it's much more than that. Lambda was the first 'go to' for ephemeral event driven or function based workloads. And it's been fantastic. But the ecosystem has evolved with managed services becoming available. And direct integration between managed services is available. So you don't need as much glue! You don't need to worry about operational burden or code liability. You can offload that to the cloud provider and to the services. Serverless, as a term, is probably coming to a close. It was a useful vehicle to describe what emerged. But it has gone through an evolutionary journey. Now, I think the term modern cloud supplants it. Serverless exists within the IT org. With the modern cloud, you are working with Product and Business. And you need to start talking in the language of capabilities. You need to develop a ubiquitous language about building blocks to describe getting capability into production. We know what the modern cloud has under the hood. But we have to evolve to talk in business terms. The well architected approach helps to frame it. Is it secure and operationally excellent? Is it performing and reliable? Is it cost optimised and sustainable? Those capability conversations are supplanting the discussions on whether you are using serverless or not. That's a paradigm shift that people don't talk about. Even from teams who are using the modern cloud approach. A term that we use in 'The Flywheel Effect' is 'long term value'. And we also talk about well architected. Because we defer ops and maintenance to the client, our solutions are more cost effective, without doing anything. And they're more secure, robust and performant. You don't hear about that massive benefit. But another thing we have been thinking about is modern cloud versus legacy cloud. Legacy cloud is the traditional call stack in the cloud. There's a whole bunch of stuff that's going to be running hot all the time. It's really just stuff that should be in your data centre, but it's now in the cloud. It's a very interesting question. It's quite a challenging question. But a lot of people look back at their traditional stack and suddenly realise it's actually a legacy monolith in the cloud. A lot of people think transformation ends with moving to the cloud. But transformation starts with moving! Legacy cloud is where you need to start. Then you need to measure and actually start modernising. A lot of people miss that point. There's definitely a time requirement and adjustment to moving from that mindset into an organisation that can embrace what we're talking about. With regards to the modern cloud, there's a way to organise yourself within the cloud to allow you to operate that way. And it takes time. It's slow to begin with. But as you progress, the momentum builds. And before you know it, you're up and running. It's the flywheel effect. People think if they're in the cloud they can stop innovating, evolving and leveraging new capabilities, But then you are left behind. Your flywheel is not turning anymore. And you're not evolving for the future. Serverless Craic from The Serverless Edge theserverlessedge.com @ServerlessEdge

We are continuing our series on the modern cloud. During our six part series, we've covered an ‘'Introduction to Modern Cloud', and talked about the CEO, Product and Developer perspectives. Today, we're talking about the technical leader or CTO perspective, which is linked to long term value. As CTO, you need to be on top of this because you own the rationale behind the decision to go for modern cloud. It may require a big initial investment despite it being hard to see the pay off at the start. One big pressure 'straight out of the gates' for a CTO is platform choice. You have to bet on a platform. And you have to guess how the platform will evolve in the next 10 years. At a CTO and organisational level you need to think about resources, where to apply resources to add business value, and you need to look at evolution and the innovations currently out there. You need to base the decision on the business in order to make the right bet on the platform. Another decision to make is picking a platform or staying platform agnostic. Will we work with all of the clouds and have a lever to switch between clouds automatically? Or will we work with all three clouds at the same time? You're probably better off minimising your liabilities and your platform by having the thinnest but valuable platform you can get away with to meet those needs. As CTO, you have to create an environment to encourage evolution. With rapid development, you need to give yourself every opportunity in the market to try out new concepts to expose a new business opportunity. As you scale up, different factors apply and you may decide that you need to change tack. You need to arm yourself with as many building blocks as possible. You may have separate platforms, or separate ways of building things to support your business model. As CTO you have to deliberately pick and select a platform! You need to pick a platform that will give you quality. Once you're on a modern cloud platform, you need a problem preventing culture. You're thinking about how to build so we don't have any problems as opposed to problem creation culture, where you're celebrating people for fixing stuff that should never have been built in the first place. The well architected framework is a great way to put guardrails in place. So you're saying: ‘this is our platform and here's our standard'. Establishing those principles is critical for the CTO. What are your principles for containers versus serverless? What are your principles for innovation or for leadership? You need to empower and enable teams to make decisions. You need to arm them with good principles so that they can assess their choices. As they're starting to pick technologies, they're starting to leverage the building blocks that you talked about Mike. You need a feedback loop on what works and what doesn't work. It's a shared responsibility thing. As a team, we apply well architected approaches to our implementations and to our architecture. But then again you need to trust your cloud providers in relation to things like HA and availability, and factor that into your decision as well. A good example of that is using industry standards. Look for a standard and use it. Sometimes there's a lack of trust when people don't do that. Companies that have to customise are very small in number and they are pioneers. 99% of companies can use the standard and be very successful. You need to be clear about using standards and not deviating except for a good reason. And usually there's not a good reason. Otherwise it can come back to bite you with issues around data, security etc. A modern cloud CTO, should ask for a well architected solution and set up their organisation to answer that question. If you've done it right and empowered, enabled and educated your teams, they should give you an informed answer. The hardest thing for CTO's is dealing with regulations and compliance, like SOC compliance, for example. At a certain point in time, managed services may not be 100% SOC compliant. But typically, I find over a short period of time, they become compliant. Unfortunately, people go down the 'Build Your Own' route and the teams and orgs that waited, pass them by because they don't have to invest in Ops to maintain their own custom solution with its limitations. You need strategies and solutions for these issues. In the role of CTO of the modern cloud, sustainability has to be something to start thinking about. Whatever application or stack you build in the cloud, there will eventually be a carbon burn measure for how much carbon you're using. It's a forcing function for all the other practices we have just talked about. If you're able to deliver a well architected, serverless first solution across your entire org, as CTO, you are building the right foundation to deliver a sustainable solution. Serverless Craic from The Serverless Edge theserverlessedge.com @ServerlessEdge

We're continuing our conversation on Modern Cloud. There are a couple of previous episodes: an overview of the CEO's perspective and an overview of Product's perspective. I figured we would look at the Developer perspective today. This ties in with our 'next best action' or 'bias for action' concept. Sometimes when you meet with developers, you don't know what's working or not. By mapping out the tech stack, it's easy to spot things that are in the wrong place. In the modern cloud, capabilities are evolving and merging rapidly. So mapping out your tech stack and understanding what's available in a modern cloud environment is very valuable. You can have a conversation with your teams on the components of the tech stack and see if there are more advanced modern cloud capabilities to take advantage of. Is there a managed service capability that can offload some of the burden in our tech stack? Can you leverage DynamoDB, step functions or some other evolved modern cloud capability to meet those needs? It's a cracking exercise to involve business or product people who don't understand the full value stream. Typically in organisations, investment is done at the UI or UX level. Perhaps they want to make a change but don't really understand the level of complexity that's involved. A map can be a vehicle for a conversation to get investment to replace a legacy part of the platform. With mapping, you can't change everything there and then, but you can plot a path. It's a good way to set goals, look for opportunities and work towards those goals. I like to do that very early with squads and look for opportunities for the year ahead. What areas need investment for modernization or to move up a level? It's a really good approach to have a joined up and holistic conversation. As well as having that conversation as a team, you're implicitly putting the concept of evolutionary architecture into everyone's head. In other words, it's okay to keep changing. There isn't a sunk cost fallacy where we hang on to something for years, because we built it. What you also need from your tech stack is rapid delivery. You want your engineers to deliver features into production quickly. There's lots of ways to do that. One way is by using decent developer patterns like CDK patterns. Composable building blocks are critical for rapid delivery. In the modern cloud with Product Leader needs and CEO needs, speed is key. You need proved patterns to compose your solution from. With the emergence of infrastructure as code, CDK, SAM and other infrastructure code capabilities, you can bring expertise and patterns to your teams to rapidly stand up solutions. For example a single page app pattern is a building block that can be deployed. Or an API gateway that connects to a new SQL database with step functions in the middle to do workflow. Pattern collections have exploded over the last couple of years. With modern cloud, you should be able to find a well proven pattern that you can leverage or customize to your needs. And you are rapidly delivering value. Sometimes people think rapid means poor quality! And if you're going to build with those patterns, then you need to build quality in! You actually need to start by having a high standard of technical excellence to make sure those patterns have quality attributes, in the first place. When you are talking about modern cloud, serverless, and leveraging managed services, a lot of things shift left. There's a lot of responsibility on the squad to assemble things to meet certain standards in the organisation. Building up squads is a huge aspect. You start off with the basics and get your observability set up which takes time, and you will go slow. But it's amazing, because after one or two months, you begin to see the philosophy creep in and before you know it you're ten times what you were at the start and you've got all the confidence in the world. The engineers are empowered and they're very creative. With continuous architecture you've got everything you need to confidently pivot and deliver rapidly. As a developer, you've got to invest in continuous education and continuous learning. We've benefited massively from following the right people on Twitter and subscribing to YouTube channels to watch videos as well. It pays dividends. If you have mapped your tech stack, have situational awareness and if you are leveraging modern cloud properly, you can apply the features that are being announced today. That is the differentiator for your team and for your business. You have happy developers! Nicole Forsgren describes it in her 'Accelerate' book: if you invest in your team to make them go fast and safely, then employee engagement shoots up. It's quite hard to explain because some people see it as money spent. But the business benefits at the other end. Serverless Craic from The Serverless Edge theserverlessedge.com @ServerlessEdge

Welcome to our conversation on Digital Product Leaders and the Modern Cloud. First of all, the good news is that our book has been announced: The Flywheel Effect. Let's just get that in there first!  But let's continue our discussion on the modern cloud. We've talked about what the modern cloud is from the perspective of the CEO. What about from the perspective of a product leader? What are the things that a product leader would expect from modern cloud? The first one is operational overhead. As a team, if you're building in modern cloud, there's less lower level stuff to worry about. So there's maybe more capacity for other things.   When teams are using a serverless method and taking advantage of the modern cloud, operational overhead is the main advantage.  I'm not spending time setting up servers, building a full specification and veering away from traditional MVP.  It gives me more time to think about product, measurement, hitting targets and understanding the business problems.  Responsiveness is critical. Teams are set up to leverage modern cloud. They're more aware of and responsive to the needs of product leads. If you're not focused on patching your servers and scaling network architecture, you are much more focused on the actual to address, the users, and their needs. And how can I leverage rapidly? You're part of the conversation.   For a product leader, your engineering teams should be more engaged with the problems that you're facing, the innovation you're trying to achieve or the issues you're trying to solve for customers. For product in the modern cloud, you should be expecting your engineering teams to be responsive to your needs. And there should be a good feedback loop. Because the time from idea to validation in production should be very short. It can be down to minutes, if you've architected and engineered it correctly. It's the right type of operational overhead. I advise teams that getting the business view of your workload and getting the IT view of your workload is Day Zero work.  You're going to need observability for production to be able to make rapid decisions.  There is still operational stuff that you do. It's now aimed at product evolution and making good decisions for what you're building. If you're leveraging modern cloud correctly and following well architected and serverless principles, you should be comfortable that you will scale globally to meet the need. It shouldn't be something you need to think about six months in advance.  Having that mindset allows you to experiment rapidly.  It allows you to be iterative in your product approach, You've got the apparatus to see how your workload has been received, how it's being used or not used.  When you talk about continuous improvement or evolution, your organisation has got to be set up for that.  You are driving a culture of innovation. You will  be constantly evolving what you're doing to move towards the business purpose set out for your team or organisation.  You'll find that you're moving into new areas and having conversations that you wouldn't have had previously, because you were so invested  in setups.   If you're leveraging modern cloud you'll have composable building blocks that your engineering teams can experiment with to meet needs in almost real time. From ideation, discovery and framing sessions, engineering teams will be able to stand up a prototype live and give you working code solutions that you can validate. The feedback loop is the flywheel turning rapidly. You're able to experiment at a pace that is previously unheard of.  Serverless Craic from The Serverless Edge theserverlessedge.com @ServerlessEdge

We're continuing our series on Modern Cloud looking at the Modern CEO. What does a CEO expect from Modern Cloud? They want capability from your engineering or IT organisation. They also want speed. And flexibility. I don't think they care about Lambdas or Kubernetes! It's good way to really frustrate your CEO if you tell him all about Kubernetes and Lambdas. As a CEO, you're going to have the needs of your customers in your mind. You're going to have user groups needs for your company to meet. You can look at Modern Cloud and think, how can I rapidly meet the needs of those customers or users? What capabilities does Modern Cloud provide me with? They are looking to Modern Cloud to quickly stand up capabilities to meet those needs. A big part of Modern Cloud is aimed at integrating with things that exist. Let's not build it. Let's not start way back with nothing and work our way up. It's the Buy, Rent, Build question! In my experience, CEOs are obsessed with the customer in the business domain that they're in. They're very focused on that industry. The healthy question to ask is: 'why are we building that?'. Why are we building that thing if it doesn't have anything to do with our core business. There's a value chain that you can draw. We've seen lots of so-called SAS offerings that don't pay as you go, don't scale up or down and come with a lot of operational overhead and burden. As we evolve towards modern cloud and a serverless first mindset approach, the SAS offerings we're looking to rent need to be assessed to see if they are built on modern cloud principles and practices. Otherwise, you will tie yourself up into knots with things that will not scale. There's an appreciation that modern cloud can actually drive your business. It's not just a cost centre. If you have a modern cloud attitude in your company, engineering is actually part of the business. Engineers are not stuck in the IT department. If everything is stuck in the IT department and it is treated like a black box, you might be doing modern cloud, but you're not getting the commercial benefits from bringing the tech potential to your business leaders. The next one is Speed. We've talked previously about 'Time To Value'. It's not how fast the developer can type in the code. It's the value stream from an idea to how quickly that makes it into the hands of the customers. That's not just IT. It's the whole org from front to back. And obviously, in the modern cloud, you can speed that up. You should be able to go from ideation, discovery and framing through to production and into the hands of a real customer and delivering value in days if not hours. There's a nirvana point where you're having discovery and framing sessions with the business and your end users, and you're actually showing them real prototypes in real production environments that have been toggled appropriately so that they're not exposed to the existing customer base. There is a flywheel effect here! But if the flywheel gets stuck and you're spending ages iterating, there's inertia and stoppage. When you start executing quickly, Product realises they can ask for things quickly. The flywheel starts to turn. The third item is flexibility. There's a couple of different ways to think about this: the ability to pivot a line of business or the ability to scale in different ways or different global locations. If you leverage modern capabilities, you're not worrying about a lot of upfront investment. You're not outlying capital expenditure. Your software features and capabilities are operational expenses. It's not OpEx versus CapEx. You're not worried about cost making it hard for you to pivot and change. You're not betting your credibility on a $50 million data centre that you've just purchased, and you have to make it work. You're able to do 'safe to fail' experiments in a rapid fashion, like we talked about with Speed. Your feedback loop is a lot tighter. You can pivot more efficiently and effectively to find that product/market fit. From a CEO's point of view, they want to have lots of options and they don't want to go through one way doors, They want two way doors. So if it doesn't work out, they can come back out and try something else. There are data implications as well. Organisations that embrace modern cloud are able to leverage data capabilities and expand into new products or ventures or experimentation. They're not fixated on yesterday's success. They've got their heads on a swivel, looking for that next opportunity. It's a radical target for orgs that embrace successful modern cloud. Serverless Craic from The Serverless Edge theserverlessedge.com @ServerlessEdge

This week we introduce you to Modern Cloud.  Modern Cloud is a phrase that we use a lot. But a lot of people are asking: 'What does modern cloud, modern application or modern architecture actually mean?' It's hard to explain what it means without thinking about legacy cloud. Gregor Hohpe has a great description. He says; 'If you lift and shift to AWS (or any of the cloud providers), and don't modernise your architecture, all you've got is a fancy data centre!'. You've moved your old data centre to a cloud level data centre. So you've got a top of the range data centre, but you're not actually benefiting from Cloud. I spoke to a company a year or two ago, who had a five step maturity model for the cloud. And they asked me about serverless first. And when I responded they said: 'Oh, you've just described step seven!'. They hadn't moved beyond modern cloud practices. That's where Wardley Mapping comes to the fore by allowing you to understand the users, the user needs and the value chain of technology that you have at your disposal to meet those needs. As well as choosing the right tool for the job. So a well optimised EC2 instance, for this particular use case may be perfect. You can justify the additional runtime and operational burden, because you have good situational awareness about your tech stack and the choices you're making. Teams that are operating in the modern cloud have that situational awareness, and they understand the trade offs for the technology choices they make. They can justify that all the way up the chain to the actual needs of the users. We always describe inertia in Wardley maps and spot teams and tech that suffer from inertia. Inertia can be not looking after something within a Lambda function that means we go back and continuously look at it, fix it or patch it. We haven't thought about the longer term or what its role is other than for this solution. You can have an EC2 container with operational capability around it. We're patching all the time, all our dependencies are up to date, we're getting ready to move mobility, we're always thinking about the next thing and is this the right piece of kit for the problem we're trying to solve? There's a mindset element which comes from teams working in a modern cloud way. A modern cloud team can do everything themselves. They rarely need to go outside their team for help. They're ‘fast flow'. There's very few handoffs, You still need, not necessarily a DevOps team, but you need enabling teams. There are complicated sub-system teams to ensure that your streamline teams or your fringe stack teams have all the experience, expertise and capabilities to do what they need to do without having to talk to anybody. As Team Topologies say, your streamline teams are set up for success and they're able to move without friction, without handoffs or dependencies on anybody. They have the organisational structure to make sure it's done appropriately and the guardrails are the right ones for business. There's a good train analogy. The train driver and staff in the train can drive the train from A to B. But they still need someone to lay the track, work the signals and repair the train. You're not doing it on your own. There's other things providing other services. Well architected is a factor as well, which we've talked about. And there's 'time to market' and how fast the team can deliver. Observability is critical for the team's to know how they're delivering with good radiators and good dashboards with frequency, mean time to restore and your lead time for change. The DORA four keys metrics are part of that as well as the well architected pillar and your adherence to them. Teams should have a good understanding of where they are on that journey. It's critical for teams that are adopting modern cloud to know their current status and how well architected they are to know how to evolve and improve. It's worth going through the flywheel that we talk about in our upcoming book. We talk about how to be effective in the modern cloud. In the flywheel, we look at 'Purpose' which is the strategy of the business/company and 'Challenge' which is the ability to challenge, have an environment for success and the right culture in the organisation. 'Next Best Action' is from a developer's point of view and looks at design patterns, processes and DevOps. 'Long Term Value', is about architecture, data security and sustainability. It's interesting to look through those lenses at ‘modern cloud'. Whether you're a CTO, an architect, or a developer, it's good to understand the art of the possible. What does good actually look like? What can we actually do? And the direction and pathway towards that. You don't arrive overnight. Serverless Craic from The Serverless Edge theserverlessedge.com @ServerlessEdge

AWS Well Architected Pillars - our favourites! Over the last six episodes, we have gone over the well architected framework from AWS. As a recap, we think this is a fantastic framework. It's about your workloads. Like a physical building, if the foundation is not solid, it may cause structural problems that undermine the integrity and function of the building. So you need to look at all six pillars for your workloads. And that's what you do to effectively produce sound and stable systems. Operational excellence: it's the ability to run and monitor systems to deliver business value, and continually improve support, processes and procedures. Security: the ability to protect information systems and assets, while delivering business value through the risk assessments and mitigation strategies. Reliability: the ability for systems to recover infrastructure or service failures, acquire computing resources to meet demand and mitigate disruptions such as misconfigurations, or transit network issues. Performance efficiency: the ability to use compute resources effectively to meet system requirements, and maintain efficiency. Cost optimization: the ability to avoid or eliminate unneeded cost. Sustainability: guidance on how AWS can help you reduce your footprint and best practices to improve the sustainability of your workloads. Mike's favourite is: operational excellence. I'm a big fan of continuous improvement and getting yourself into a sustainable way of working. How do you learn from failure? How do you react to certain things? How do you have visibility of everything around you? If you can assemble that apparatus and those behaviours, then you can begin to eat into the other pillars. For example, operational excellence gets into how to observe if something's working in production, or if something's failing in production. If something's failing in production, how do you deal with it? Do you have ‘run books'? Do you have playbooks? What's your playbook say about this scenario? It's fundamental and core. It's where I start. If I'm going into a new team or area, I'll always start with operational excellence. This one is very consistent across all squads and all parts of the organisation. That's probably my favourite, because I know it so well and I rely on it. Mark's favourite is the sustainability pillar. I think it if you have all other things in place, the sustainability pillar will really drive you to that next level. If you're trying to deliver a sustainable solution, you can't do that without having a good handle on the other five pillars. So I think sustainability and the sustainability pillars and the questions within them, are a forcing function for good practices, processes and architectural choices that the other pillars are continuing. With our serverless first mindset and approach I think it lends itself well to the sustainability pillar. I think sustainability is probably my favourite now. Also, we want to make sure that we leave the world a better place than what we found it. So if we don't deliver sustainable workloads (especially with the exponential growth of compute devices in the digital era) it's not going to be good for the long term health of the planet and for the people on earth. Dave likes security, reliability, cost optimization. The reason why I like those three is because they're things that a different team does. If a team thinks they're really good but completes one of those pillars, they realise there's a bunch of stuff they've never thought about but actually is their responsibility. The most shocking one is probably cost optimization. Most teams don't really think about cost. There's usually an IT manager somewhere who does it. It's magic and it happens in the background. But when you start asking teams about how they monitor or control their cost and optimise for cost, it spins their head. I like the shock factor of that and also the fact that it's about real money . If you make a tweak, you can actually save your organisation money. It's green dollars and not pretend money. So I always enjoy when teams are connected back to reality. I think that's interesting.  Serverless Craic from The Serverless Edge theserverlessedge.com @ServerlessEdge

We're continuing our conversation on the well architected pillars looking at what is our favourite pillar. Today we're talking about sustainability. What's nice about sustainability is that it rolls up a lot of good practices and it's a very simple measure. So it's very hard to measure carbon, but very simple to understand when someone, like AWS measures for you. There's a list of best practices that are broken down into sections. So lets list them out: Region Selection, User Behaviour Patterns, Software and Architecture Patterns, Data Patterns, Hardware Patterns, and Development and Deployment Process. Region Selection is quite straightforward. Some regions are supplied with greener energy than others. Some regions are using non sustainable resources, depending on where you are in the world. If you don't have massive latency requirements, or a real need for super fast, low latency, then you're probably best putting it into a more sustainable region. So where you put your workloads can have a sustainability impact. User Behaviour Patterns is about using assets in an elastic way with the latest technology. It will be more sustainable, efficient and cheaper on modern cloud. If you go down the legacy cloud route, and treat the public cloud like a data centre, then you're not going to be very sustainable, you're not going to be very cheap, and you're not going to be very efficient. It's about how you align your SLAs with your sustainability goals. Making sure workloads and solutions on the cloud are aligned to SLAs is what we're going to be concerned with over the next number of number of years. Software Architecture Patterns is about keeping your code base and your architecture really efficient such as refactoring optimization and more effective data access. It's good practice as it ties back into efficient design. When you work in enterprise spaces, you do question the value of older business products that are running in the background. You've got to constantly assess if this is worth the compute? There's an interesting question on optimising the impact on customer devices and equipment. If you have a really inefficient client side app with a lot of data processing on the device that it doesn't need, you could sustain the lifetime of that device by having a more effective and efficient client side app or web app or mobile app. I always think about IDEs and the bigger IDEs in terms of auto completion and indexing because they get very warm very quick! I've seen a lot of IDEs moving onto the cloud: Cloud9 and VS code. And you're thinking that all of that should be done in the cloud too. A very thin client for all your needs. And everything is done in the cloud, server side, from your IDE to everything else. Data Patterns: there's an awful lot of waste with data flying around the internet. There's a lot of good practice here. Data can be quite toxic for various reasons from privacy breaches and security points of view. You should have a good handle on this. Your data classification is critical. If you don't extract value from it, get rid of it or it's going to be unsustainable. Everything's becoming more data centric, and the amount of compute that goes into chomping data is 90% of what IT. I'd love to see how much electricity or energy is used on processing data. I am keen to see how organisations approach this one. Hardware Patterns: is right sizing our stuff correctly. We've all been in teams where the question asked is: 'what size box do you need?' And the answer back is: 'the biggest one humanly possible!'. It's a natural reaction but you don't need that. This is where a serverless first mindset and approach really kicks up a gear. You don't even have to concern yourself with a lot of these questions. It automatically scales up and down appropriately. We don't have to worry about picking hardware or incident sizes ahead of time. Development and Deployment Process: how do you increase utilisation of build environments? We see this quite a lot where environments sprawl and asset's sprawl for no real benefit. So again, it's all about being smart about how you set up your clients, how you set up your pipelines and how you set up your environments to make sure they're actually delivering value. And they're not just there because that's the way we have always done it. The question here is: 'how do you adopt methods that can rapidly reduce or introduce sustainability improvements?'. If you're on a serverless spectrum, the cloud providers are working for you and they're introducing new capabilities. Serverless Craic from The Serverless Edge theserverlessedge.com @ServerlessEdge

We're continuing our talks on Well Architected with the fifth pillar which is AWS cost optimization. There are 10 questions and 5 subsections:  Practice Cloud Financial Management,  Expenditure Awareness,  Cost Effective Resources,  Matching Supply and Demand, and  Optimising Over Time.  Practice Cloud Financial Management is a maturity step for teams to be able to know how much their stack costs. There has been a big shift in architecture, since we've got more visibility into cost in the last number of years. When you were working on the enterprise mainframes, you were dealing with capacity. And maybe you did get into licencing and availability of licencing but you never talked in terms of cost.  Setting expectations around CapEx versus OpEx is critically important, especially with business partners, who maybe aren't aware of this and will wonder why my bill went from £50 to £3,000 this week? And the explanation might be running a load test for a new feature. So you need to be very upfront and very good about setting expectations that costs will fluctuate up and down give reasons why. It relates back to 'clarity of purpose,' understanding what you're doing, and being able to articulate that, in a business way to link up business and IT together. Expenditure awareness: To grow that awareness, education is critical.  You need to make teams aware that these things are available to you.  So how do you govern usage? How do you monitor usage and costs? And how do you decommission/how do you switch things off?  If you're in a leadership position, you should be able to see a breakdown. If you have five applications in your portfolio you should be able to know the cost breakdown from those five, at the very least. That's not that hard to do. Cost Effective Resources:  Developers, always want to pick the fastest, craziest and wildest thing. But is it more cost effective? Sometimes you don't need the fastest thing and a moderate speed will do the job. This point to sustainability as well.  It's not how fast can you get it? It's how fast do you need to provide adequate service?  The total cost of ownership comes to the fore here. It's not what is for right now. It's the long term operational burden and cost.  You can choose a technology that's super low cost, but the cognitive burden is massive because it's a new technology that's outside your team right now. Then, what's the learning cost for that team to learn the tech stack or language that you chose for cost efficiency reasons? You have got to take a bigger view. It's not just for what you're doing right now. How do you plan for data transfer charges. That's definitely one to look at if you have a large data footprint. Matching Supply and Demand and Optimising Over Time.  I've lumped these together. There's a piece around keeping up with the latest and greatest in AWS and tweaking your design so that your continuing efficiently. There's also a bit about selecting new services as you build new stuff and selecting wisely for a decent cost impact.  This is where we see the serverless advantage kicking in.  Matching Supply and Demand is taken care for you as it scales with the load. If you're on traditional architectures or EC2, you might need to pre provision some other stuff and have it at hand and ready to go.  That's a hard calculation to get right. You're going to have a lot of wastage with excess capacity just waiting to go whenever the demand comes in. So it's a lot easier when you're serverless.   Serverless Craic from The Serverless Edge theserverlessedge.com @ServerlessEdge

In this episode we're continuing our series talking about well architected pillars. Today, we're going to talk about the Performance Pillar which is called performance efficiency. Each of the pillars of well architected usually have around 10 questions. This one has eight. And it's got four sections: Selection, Review, Monitoring, and Trade Offs. It is really about the performance efficiency of your whole system. There are five questions about selection. The kicker question is the first one: 'how do you select the best performing architecture?'. You should go really hard and deep to make sure you understand the problem you're trying to solve for the users that are going to use a system. What are their needs? Once you have that to hand, do something like domain driven design to break it up a little bit and make sure you have good boundaries and domains established. When you have all that you're well informed. At the start of a project, there's always pressure to get something working. But you need to pause at the start and figure that out. The idea of the mental model of the system is really important. Can you explain to everyone in your company what it is? Is it X, Y, or Z? Evolution is critical. It might be the best architecture to meet the needs right now, but is there scope, capacity or room for it to evolve to meet unexpected future needs as well? I want to move fast. But I reserve the right, at some point, as we scale up or the system evolves to pivot and change reasonably quickly. This is another factor with serverless. Because it's event driven, you're forced to use event driven style architectures so it lends itself to that sort of evolution. You can swap things out later on. If you need a container, a SAS or an external vendor, it's pluggable. But there's a bunch of non functional requirements that need to be right. This is where you get into the idea of is this a commodity component? Or is it something that's mission critical to your business or a piece of IP. Do you need to build it? Or can you just rent it? Wardley mapping helps you to think whether or not to build. For example, we need global storage so let's try and build that. The answer is no! Just use S3. In summary, what's the managed service I can leverage? What's the serverless capability I can leverage? If it doesn't meet the needs of your use case, you can fall back to something that's further back on the serverless spectrum. That applies to compute storage, databases and networks. Serverless is not standing still, it is improving over the years. We've seen cold starts reduce and we are seeing more conductivity across managed services, as opposed to directly through lambdas. You get those benefits without having to do anything. That's another benefit to consider when deciding to take a serverless approach with your architecture. I think one of the best things with a serverless approach to performance is that the cloud provider is constantly working at improving performance efficiency, reducing costs, speeding up and adding more horsepower to your compute. By choosing smartly, with your architecture, you get a free underlying platform team that is constantly working on improving your performance. And you can just take advantage of it without having to worry. You can leverage that performance improvement. Moving onto the next section and relating to what you said is how do you constantly review your architecture to take advantage of new releases? Cloud providers are constantly innovating and releasing stuff every week, so you want to be in a position where you can add new stuff quickly without breaking the whole architecture. You need to operate a 'two way door' as Amazon call it where you go in, do something and then get back out again. You don't want a one way door where you get trapped. Event Bridge is a good example. For a long time we've been using an SNS SQS finite type approach to the event. And the Event Bridge was released. The team was trying to get latency reduced and constantly looking at that. And then realise that when you get to a certain level, we'll make that cutover. But it's a good example of how to evolve and plan for that. The next section is Monitoring and how to monitor your resources for performance, which is fairly straightforward. And the last one is Trade Offs and how to use trade offs to improve performance. A great example is Lambda Power Tuner, where you can tune your function based on memory or CPU to get that nice balance between cost and performance. Performance efficiency quickly becomes a work based development conversation. If business isn't bringing in loads of money, you don't need all this horsepower under the hood. It doesn't need to be that efficient or effective from a performance point of view. Serverless Craic from The Serverless Edge theserverlessedge.com @ServerlessEdge

In this episode the team continue their conversation on the well architected framework with the Reliability Pillar. It has 4 sections: foundations, workload architecture, change management, and failure management. If you're building in a traditional way then reliability can be a huge amount of work. But we're serverless heads. AWS make it a lot easier to do some of these things. A lot of service quotas and constraints are baked into the foundations. From a change management perspective, you want to get into the continuous delivery kind of mindset, so there's a lot of monitoring if you use the modern tools. From a failure management perspective, serverless is ephemeral, so it's built for retries. You can design so that those areas are slightly easier to work with. When you look at the foundation section of the reliability pillar, you're probably looking at how to plan and not over provision or overspend and how to scale up effectively. You put a lot of time into the foundation section, where as if you are in Serverless you still need to look at foundations, but I think it's less intensive. So you're looking at things like DNS, or how you to write effectively, and things like that. You still need to worry about quotas and some of the constraints and resource constraints of your account. But you're starting from a more mature reliability standpoint, when you adopt the serverless and a serviceful approach. So from a change management point of view, adapting to change is built into serverless capabilities and how managed services operate. From a failure management point of view, a lot of that is baked in especially if you've built an event driven asynchronous workload, using SNS, SQS or Eventbridge. A lot of circuit breaker type mentality, retry and dead letter queues are coming out of the box now. Increasingly they are maturing those capabilities to make it easier for teams to have a default, resilient driver and reliable capability. With serverless architecture we tend to take a micro path: micro service or micro front end. It's opinionated so there's only so many ways to connect these things. It's aimed at speed, cost effectiveness and reliability. If you are using lambda, it's 6 AZs wide, in terms of the HA side of things. It's the same with DynamoDB or Aurora. There's lot of stuff that AWS has thought about for you in relation to the foundational side and you can benefit from that. And that influences how you actually assemble your workload in terms of the workload architecture as you've got to work within those constraints. What's interesting about the reliability pillar and well architected is that they have been there for eight years, but they've just recently added this new section, which is workload architecture. And one of the questions is how do you design interactions in a distributed system to prevent failures? So there's a specific section on how to design distributed workloads. That's more than a nod. It's proof that a lot of customers are moving towards distributed micro service and modern application stacks. There's a lot of depth in that. To do that well, you need like upfront design. You need to think about your system before you design it. You can't code you way out of it. Serverless makes some of these things easier, but the time that you don't spend on retries is put into domain design. It's an equal amount of effort and it's still challenging but you're putting precious time into system design, as opposed to tuning a non functional thing. It's still hard to build the systems, but I firmly believe you get a better system at the end of the day. Some of the questions look at: if we auto scale this serverless component, what sort of load or pressures are put on something that doesn't auto scale? It forces you to think about protection and where are the choke points? Should you be throttling your workload? Should you be setting constraints on the scalability of your serverless workload? Those type of questions get to something that we're very passionate about, which is testing for resilience and continuous resiliency, and having test days or game days that tease out where the choke points are. Where are your failure cases? Where are the downstream systems that can't respond or can't take the load as you pass to it? All of us agree that it is easier to do it with serverless and it's important that the setup is designed properly. But you can get good feedback by testing for this stuff. And you've seen the maturity of the fault injection service that has come out. It's easy to use and I'm hoping to see that evolve and mature to be much more serverless focused as well. But it's a lot easier to test for resiliency. So you're not guessing anymore. You have real automation and you've baked that into your CI CD pipeline as well. Serverless Craic from The Serverless Edge theserverlessedge.com @ServerlessEdge  

This week, we're continuing our series looking at each of the pillars of the well architected framework. We talked about the operational excellence pillar in the last episode. We're going to talk about security this time which is our favourite well architected pillar. There are 10 questions for this pillar and a couple of different sections. The well architected security pillar is aimed at checking how secure your organisation is. It goes into things like: How are you managing accounts?  Is your control tower hooked up? Are you using guard duty? It promotes team awareness of security across the organisation. The types of things to engage with when looking at workload are blast radius: If something goes down, how are we going to recover it? Or is there a case there for failover? Or resiliency? It is broad but there are things you can zoom in and focus on in that question. With the modern techniques, capabilities and improvements, you can be fine grained and have more accounts. Single sign also helps manage that burden. And AWS organisations, control tower and cloud trail are mature capabilities that help you get a good initial posture. One thing about well architected is that there is a nice flow to the questions and sessions. The first question: 'how do you securely operate your workload?', straight away gets into identity and access management, your inventory of people on machines and how you manage that. Or how do you manage blast radius, permissions, and the process of adding and removing people, accounts, machine accounts and different resources. In a modern cloud environment, rule number one is that it is tightly managed and automated. Normally, it ties back into the enterprise or a broader policy and it gets teams asking what are the authorization controls for this component. The Least Privilege principle comes to the fore especially for serverless workloads. As you ephemerally spin stuff up and down, you can be tempted to give star-star to everything and open up the world meaning your blast radius is massive and you've got a big security hole. So you need to be aware of the Least Privilege principle and give it the minimal amount to be functional. You have got to automate that and build it as part of your automation. Otherwise it becomes unmanageable burden and an ephemeral sort of workspace. The next is one of my favourite: detective controls, how you detect and control security events. I always love the way security people talk about 'left of attack': all the things that happen before the attack. There is the time when the attack happens and that's panic stations. But there's usually a whole bunch of stuff before that, that you can act on. And that could be two years prior. So there's a whole mindset around detecting weird activity when people are probing your system, before the actual attack. That's the hunter side of cybersecurity when people try to find breaches. It's about keeping abreast of latest developments and responding to new emerging threat vectors, like 'Log4j'. How do you respond to that new information to the left of your detection? Do you have the right logging, monitoring, alerting and alarming for rapidly detecting and remediating these events? The next one is data protection. There's stuff here about both encryption etc, in rest and in transition. We have mentioned that code as a liability. Your data can also be a liability that you need to manage appropriately. Organisations have a good data classification document or something that describes data classification as it pertains to the industry or the organisation. I think the challenge you've got is getting engineering teams to understand it. Previously we've woven in data classification into the threat model exercise so the first section is what sort of data are we dealing with. The last section is 'incident response'. It's fairly self explanatory. How do you respond and recover from incidents? You want to be well drilled with as much automation as possible. Sounds straightforward. But it's complicated. It ties back to the operational excellence pillar. You're anticipating these events ahead of time. If you're anticipating them, you have associated runbooks or playbooks to facilitate squads in particular circumstances.  So there's a lot around education as well and making sure that everybody in the organisation understands what you do in the event of an incident. You don't want a junior developer noticing something, and not feeling confident or capable to raise their hand and say something is not right here. You want a psychologically safe environment for everybody to raise an incident or a query something that's not quite right. In the security pillar, there's a nice arc that starts with people and ends with people. It goes through all the technical stuff in the middle. But security is a 'people' responsibility. Serverless Craic from The Serverless Edge theserverlessedge.com @ServerlessEdge

This week, the team are starting a series of episodes on the Well Architected Framework Pillars.  In this episode they start with the Operational Excellence pillar. There's been a lot of good conversation about well architected and the well architected framework. And the team have written about this on The Serverless Edge Blog: well architected and SCORP or SCORPS, which is the five and now six pillars of well architected.  So taking operational excellence first. The AWS pillar breaks down into three areas. Each area has five or six questions. So the three areas (in the operational excellence pillar) are prepare, operate, evolve. It's great to go into new areas and teams and ask these questions: Do you know who your users are? Do you know what what the purpose of your team is? Do you know what your highest priority thing is? If you are in a safe space with the whole team involved you can get a really good conversation. It's also good to tease out if you are aligned with the strategic direction? Do you have a prioritisation framework or are you making it up 'on the hoof'?  You have got to prepare to move onto post implementation and hand off to a different team or  the place where you're bringing on new engineers or whatever.  Do you have the runbooks for the operations in a particular workload? Do you have the playbooks that are linked to observability in your dashboard? So that when things go wrong, there's a solid set of instructions to deal with that problem and they don't have to go in and unpack what you've built out. It checks simple stuff like: Do you have enough people to meet the challenges? Do you have assigned owners who are going to be responsible for processes, practices and operations? If you can get these foundations in place early, you evolve, go down through the lifecycle and start applying the other well architected pillars. Your chance for success greatly improves because your operational excellence pillar has set the foundation.   The next pillar is operate.  So you start with prepare and then move to operate. I like operate because there's a lot of observability.  I like thinking of a workload as an asset, how to understand the health of that asset and how to monitor it to make sure it's working well. It's about getting the team ready for production. There's always something that is going to go wrong, something you haven't predicted or an alternate path has been missed. So when those things happen, have you got the correct procedures for learning what that defect teaches so you can bake it in and toughen up your operation going forward. It's an holistic way of thinking and you need those mechanisms to show you how your workload performance by product.  If you have proper observability you can show the C Suite your team working on a particular capability, feature or value stream and how it relates to our vision and strategy. That's proper operational observability across everything including not only the health of your workload, but the health of your team. Door key metrics should be part of how you operate with a sustainable pace for the team. The last one is evolve. You go through prepare, operate and then evolve. And it's quite simply about how you evolve operations which doesn't mean cutting costs and reducing the budget! We're big into mapping and evolution is a cornerstone of Wardley mapping. If you don't take these signals from your systems and your workloads on board and use them to evolve improve and get better than there's no point having observability and dashboards. Your operations are going to generate a lot of data and  useful information that you, as an engineer, manager or architect can use to evolve your current setup. You should be always looking to learn.  You set up for success and you put the foundational building blocks in place to increase your chances of a successful development cycle. Serverless Craic from The Serverless Edge theserverlessedge.com @ServerlessEdge

This week the team talk about the all important relationship between serverless and security.  They have come across CISO's who don't want to touch Serverless because they believe it's not secure. So in this episode they get to grips with the question: 'Is serverless more secure or less secure?'. Mike, Mark and Dave have talked previously about rapid delivery and assembling or aggregating various components or managed services together to form a product, feature or capability. A massive part of that is not having to worry about the operational side of maintaining those managed servers. The cloud provider is patching and doing those things to a level that organisations would struggle to keep up with. From the infrastructure and operational side, there's a ton of good security benefits.  The shared responsibility model is key here. A lot more of the shared responsibilities for security of the cloud fall onto your cloud provider ie. AWS. By leveraging higher level building blocks and managed services, more of that responsibility is on AWS. They have some of the best security engineers in the business. They're very good at articulating and working behind the scenes to patch hard and secure and give guidance.  There's also the risk exposure. If you have a purely serverless application, then you're responsible for application security. And if you mess up application security then maybe somebody might steal detail or data or hijack a session. But you know that it's at an application or session level and infrastructure security is handled by the cloud provider. But if somebody compromises your infrastructure security such as ransomware, then your whole company is down. Losing customer data is bad. But losing your entire company's data centre is catastrophic. So the exposure is slightly less with Serverless.  You need to sit down with security people and talk to them to understand what they're trying to do. There is huge value (when you're hit with a process that's difficult), in understanding what's the control behind the process, because the process is just trying to put a control in force.    Having a shared vocabulary and a common language is critical. We have had great success with threat modelling to help bridge that common language/vocabulary. Threat modelling, as a technique has been awesome, not only for good application design, but also for having conversations with security partners/teams on the threats we have identified and what we're doing to mitigate them. When you come to the Security Team and say: 'This is what I think you want to do. And this is how I think we should do it.'. You're opening up the conversation. That is a key point. These collaborative, facilitated team based activities, surface so much value.  As an architect, I think it's a really good exercise for making sure you understand how teams are going about certain things as well. So you're constantly validating your thinking. When you are walking through the Microsoft threat model, you're building DFDs (data flow diagrams), and you're constantly reaffirming what it this talking to here, what are we doing, what what are we passing across?   One last point on the threat modelling piece is when you get into the mitigations, and how you verify your mitigations, it leads you down the path for creative testing. You are arming your engineers with ways to test the system through a different perspective and you look at different techniques.  Another great piece is identifying a developer to be a security champion. And it isn't about always identifying the most senior developer.  Serverless is more secure. Do threat modelling, do well architected reviews, identify security champions, establish good guardrails and automate the hell out of everything! And talk to your security department. They are not evil, they don't have horns! Serverless Craic from The Serverless Edge theserverlessedge.com @ServerlessEdge  

In this Episode, the team looks at clarity of purpose and the North Star Framework. They look at the reasons why orgs don't understand the basis of transformation/trying to improve which should be based on a core understanding of purpose/why you doing the things you're doing.   Or it could be the fact that businesses talk about wanting to corner the market or drive up the rate of business. But the broader organisation doesn't feel part of it, or doesn't understand the mission.  It could also be that teams or development squads don't understand how they're going to contribute to that mission and how what they're doing is having an impact on the overall mission.  What is clear is that successful transformations need to involve everybody in the company.  The Serverless Craic team run North Star exercises and the North Star playbook. It's a phenomenal practice or tool for getting that level of understanding for where you are in the overall transformation.  The framework is brilliant because you find the one metric that matters, and then you work at how you can work backwards from it. And for many companies, the one metric that matters is not 'making money'. Every company will have some kind of goal for profitability.  A lot of the time people are trying to chase the lag metrics. They don't think upstream. They don't think about the North Star or the input metrics that actually make a difference. There's a detachment from the people on the ground doing the work, trying to work as hard as they can with the best intentions. Because they don't have that purpose or that alignment to the actual real purpose or the real North Star. And their efforts are in vain. They're not actually influencing any of the input metrics that could affect the real North Star. Metrics are important to the organisation from a financial perspective. But what are the lead measures that have a proper influence over those lag measures. What sorts of things could we be doing more effectively, how do you instrument your transformation and how do you know that those lead measures are having an impact on the overall 'money in the in the bank' or core outcome.  We can move the needle on this North Star metric and that should result in successful outcomes. But the interesting pieces out on the left of the North Star are the lead measures. If you don't have those metrics, and that team doesn't understand how it's playing into the overall big picture, the management side can become really difficult. Whereas if you've got those lead measures, and the teams know what they're trying to do in relation to the influence of the overall North Star, it becomes very easy to pivot or understand the impact that a squad has in terms of customer value. It's very odd that a lot of organisations don't operate that way because it's super efficient and effective. It gives you a lot of opportunities to crack. Organisations need to be brave with discussing Purpose on their North Star. Once you make this visible, make metrics observable, start talking about the North Star and important metrics, and start to align your teams, the teams then become engaged with making a difference and seeing the benefits of the work. Then the teams will go out and start challenging the rest of the organisation by saying: 'that doesn't quite make sense, I don't think that input metric is quite right, can we change that to something better?'.   You can Wardley map your market to find out which capabilities should be your differentiator. What's your IP? And what do you not need? What is your competition? Decide what you're going to get rid of because it's not a differentiator. And what you're going to hang on to because it's core to your clarity of purpose. Serverless Craic from The Serverless Edge theserverlessedge.com @ServerlessEdge

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 the team have 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. We take our time to 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 of that takes a lot of maturity and engineering rigour.  A lot of our squads assemble their observability and dashboards first, to get in front of their metrics and begin that iteration process. That can take a number of weeks to just get up and running. But once you get through that process, and you've got rigour, you're actually in the environments achieving rapid delivery. You can rapidly increment, you can rapidly experiment and you can get instant feedback on what you're doing.  With serverless, 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.   If you give your engineering teams the time and the psychological safety, then any developer can 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  provided by managed services. By using a severless first mindset you are offloading liabilities. They probably have a lot more concerns to deal with 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 achieve the same thing, but the idea would be to go further and use your developers on new emergent stuff. I've liked working with squads 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. A well architected, serverless first structure and discipline gives you greater freedom. It gives you freedom to go fast It gives you 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. Serverless Craic from The Serverless Edge theserverlessedge.com @ServerlessEdge

In this episode Dave, Mark and Mike talk about the all important and hot topic of sustainability. After doing a lot of reading and writing about sustainability and cloud compute and through the influence of COP 26 the team discuss the how sustainability is now at the top of the agenda.  Even Simon Wardley called for AWS to bring out carbon cost per lambda execution preInvent. Mark feels it's one of the big wins that all Cloud Providers can easily put out there especially with Microsoft Azure calculator and GCP and their carbon footprint capabilities.  Mark sees cost as a proxy for carbon footprint up to now, but it's a big assumption.  But with a serverless first approach, sustainability is not for free, but you're getting it as a side effect.  Dave talks about the 4 basic models of compute and how hard it is for Cloud providers to report on all cases. But the first step is to get to the cloud and the second step is to think about your energy utilisation.  They also discuss a recent report that AWS is around 80% more efficient than running your own data centre Mark also talks about the fact that teams who have delivered solutions in a serverless first way will be able to adopt any new carbon footprint features that within minutes or hours to satisfy Board/C Suite Level mandates. And they discuss the UK government sustainability guidelines for the Central Digital and Data Office. Serverless Craic from The Serverless Edge theserverlessedge.com @ServerlessEdge

In this Episode Mark and Mike chat to Dave 'live from Vegas' at AWS re:Invent 2021. Watch to find out their take on Matt Coulter's speech as part of Werner Vogels keynote, how Serverless and CDK is becoming part of the mainstream as well as the announcement on CDK Patterns Version 2. Sustainability has been the hot ticket item at AWS re:Invent - you saw that prediction from The Serverless Edge first!  AWS have announced their Carbon Calculator.  And sustainability is now another pillar in the Well Architected framework. There was more news on AWS Amplify and great dialogue on the Data Driven Enterprise as well as the Goldman Sachs Financial Cloud for Data.  Some of the new pieces were incremental and the team were spotting how machine learning is being integrated in many of the developer tools. Don't miss out on Serverless Craic's unique insight and perspectives as well as hints on the best talks from AWS re:Invent 2021. Serverless Craic from The Serverless Edge theserverlessedge.com @ServerlessEdge

In this Episode, Dave, Mark and Mike welcome guest and former Liberty Mutual colleague, Matt Coulter @NI Developer, who received the 'Now Go Build' award from Werner Vogels at AWS re:Invent 2021.  As well as all having previously worked together at Liberty Mutual, Matt is founder of CDK Patterns and published author of the CDK Book available on thecdkbook.com.  He is an Architect for Liberty Mutual, an AWS DevTools Hero and Serverless Architect sharing reusable, well architected, serverless patterns over at cdkpatterns.com or behind the scenes bringing his flagship event: 'CDK Day' to life. Matt Coulter and the Serverless Edge guys reminisce about bringing serverless to life at Liberty Mutual and how CDK patterns was a key part of the journey.  They talk about the challenges they encountered and the approaches that brought them success such as gaining external validation from the pioneers of serverless to enable them to get the internal support needed to start serverless at a 100 year old global insurer. You can learn from these experts on how to get started on your severless journey using tools such as Wardley mapping to get your situational awareness and find your next best thing to do.  Find out about the importance of building a developer community to maximise the fast flow efficiencies from CDK patterns.  And how combining that with well architected and serverless first principles will build momentum into a self sustaining Value Flywheel.  This unlocks your clarity of purpose and gives your org long term value. Listen to Dave, Mark, Mike and Matt talk about their experiences of removing cognitive burden from developers to allow them to experiment and collaborate in the wider community leading to even greater efficiencies for their teams and organisations. Notes: Matt Coulter: @NIDeveloper CDKpatterns.com https://github.com/cdk-patterns thecdkbook.com Serverless Craic from The Serverless Edge theserverlessedge.com @ServerlessEdge

Dave, Mark and Mike discuss Dave's 'Adaptation - the Value Flywheel' talk at Map Camp 2021. In this episode they work through Wardley Mapping as a concept demonstrating an example that Simon Wardley uses when mapping serverless as a concept. They then move on to Dave's talk at Map Camp which develops the concept further through the use of the Value Flywheel.  This sets the context of how Wardley Mapping works in the practical implementation of ongoing technical strategy.   https://www.mapcamp.co.uk/ https://twitter.com/MapsAsCode https://onlinewardleymaps.com/ https://twitter.com/swardley/status/1436280981087047682  https://twitter.com/davidand393/status/1448260882350346242  https://architectelevator.com/  https://theserverlessedge.com New Book from David Anderson itrevolution.com Serverless Craic from The Serverless Edge theserverlessedge.com @ServerlessEdge

Dave, Mark and Mike discuss their best bits from the DevOps Enterprise Summit 2021 with IT Revolution. They also review their talk on the Serverless Value Flywheel.  The DOES 2021 talks are practical with participants describing their digital transformation journeys in an open way, revealing the lessons they have learned.   Here are quick links to themes, tools and techniques that the guys covered in their talk on the Value Flywheel and picked up in other talks and discussions: https://learnwardleymapping.com https://doctrine.wardleymaps.com https://medium.com/wardleymaps https://list.wardleymaps.com https://github.com/ddd-crew/ddd-starter-modelling-process… https://amplitude.com/north-star Our Talk: 'The Serverless Edge, Using Wardley Mapping with the Value Flywheel from combined Business and Technology Evolution'  Transcript: https://www.theserverlessedge.com/wardley-mapping-with-the-value-flywheel/ Slides: (including ours under Dave Anderson): https://github.com/devopsenterprise/2021-virtual-us Slack: https://devopsenterprise.slack.com/ New Book announcement https://itrevolution.com/announcing-new-book-from-david-anderson/ The conference was virtual but there were still many opportunities to interact through the Slack Channel and Lean Coffees with leaders and architects from leading edge organisations.  Dave and Mark also give a behind the scenes view of their talk: The Serverless Edge, Using Wardley Mapping with the value Flywheel from combined Business and Technology Evolution which previewed their book due to publish next year with IT Revolution: https://itrevolution.com/announcing-new-book-from-david-anderson/ In their talk they explained what a 'value flywheel' is and they did a live demo of a Wardley Map to show the technique in action. There are 4 stages of the 'value flywheel': 1. Clarity of Purpose 2. Challenge 3. Next Best Action 4. Long Term Value The transcript for talk is available on: https://www.theserverlessedge.com/wardley-mapping-with-the-value-flywheel/ Dave and Mark hosted a Lean Coffee on 'Building internal capability, not consultancy dependency', which prompted a good debate. Mike also picked up on themes around value streams and flow efficiency with Mik Kersten from Tasktop - tasktop.com,  and similarly with Bank of New Zealand - bnz.co.nz.  The guys felt that Wardley Mapping is very complimentary to those themes and is rising in popularity.  Mark picked up on an increasing evolution towards product centricity, meaningful work and socio technical practice. Mike attended a session looking at ubiquitous language tying in with the need for visibility/observability to make decisions in DevOps organisations which Mark also picked up on in the talk on 'shifting left with product excellence' with Liz Fong-Jones with metrics being used in right way being key.   Mike also picked up a lot of SRE themed talks including one by Michael Winslow from Comcast.  Courtney Nash from Verica and Troy Koss from Capital One did a 'Chaos and Reliability: A Surprising Friendship in the Enterprise' talk that Mark enjoyed. And Dave picked up on a talk by Dr. Ron Westrum. Mike felt that Team Topologies concepts were permeating the talks and thinking at the conference.  Dave enjoyed the talk with Admiral John Richardson and the ultimate distributed organisation, leadership and autonomous themes.  Security was covered by John Wallace looking at how that area has changed.  The guys picked up on the lack of serverless talks, although that could be about the organisational journey.  Also the conference wasn't really about specific technologies. Tune in next time for more conversation on all things Serverless Craic. Serverless Craic from The Serverless Edge theserverlessedge.com @ServerlessEdge