Serverless Craic from The Serverless Edge

Treasa Anderson

Welcome to Serverless Craic from The Serverless Edge with Dave Anderson, Mark McCann and Mike O'Reilly. We want to share our tools and techniques so that you can use them to communicate your Technical Strategy with your C-Suite and business owners. We want to help you to build a serverless first organisation. We will show you how to use Wardley Mapping to gain situational awareness of where your cloud applications and business are. And then how to develop your technical capability in away that builds engineering standards to set your organisation up for sustainable success.Sounds like the tools and techniques that you need - then hit the subscribe!-ABOUT- Dave, Mark and Mike are senior technical architects/leaders passionate about driving technical strategy. They have led transformation journeys, technical excellence, cloud adoption and tech strategies in many industries.Active in various technologies including ML/AI, Public Cloud (IaaS, PaaS, SaaS), Engineering, Product, Cyber and UX.

Start Here
Serverless Craic Ep39 AWS reInvent announcements
6d ago
Serverless Craic Ep39 AWS reInvent announcements
AWS reInvent announcements In this episode we are talking about what we would like to see at AWS re:Invent. What would you like to see?Serverless ServicesAn 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.API GatewaysIn service development, Private API gateways are interesting, but they could be more developer friendly, in terms of setting up, naming and managing. 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 EnablementYou 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. Well ArchitectedOver the last year, we've seen good announcements on well architected capabilities, systems and services. I want to see a continued evolution of that. And more well architected thinking and characteristics baked into everything.  All the way from developer advocates to patterns and code samples.  Some of the basic primitives are moving up a level to something more like a pattern.It's about fast feedback and dare I say the value flywheel. 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. SustainabilityMore 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 EdgeCheck out our book The Value Flywheel Effect Follow us on Twitter @ServerlessEdge
Serverless Craic Ep39 AWS reInvent announcements
6d ago
Serverless Craic Ep39 AWS reInvent announcements
AWS reInvent announcements In this episode we are talking about what we would like to see at AWS re:Invent. What would you like to see?Serverless ServicesAn 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.API GatewaysIn service development, Private API gateways are interesting, but they could be more developer friendly, in terms of setting up, naming and managing. 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 EnablementYou 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. Well ArchitectedOver the last year, we've seen good announcements on well architected capabilities, systems and services. I want to see a continued evolution of that. And more well architected thinking and characteristics baked into everything.  All the way from developer advocates to patterns and code samples.  Some of the basic primitives are moving up a level to something more like a pattern.It's about fast feedback and dare I say the value flywheel. 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. SustainabilityMore 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 EdgeCheck out our book The Value Flywheel Effect Follow us on Twitter @ServerlessEdge
Serverless Craic Ep38 It began with the forging of the Great Maps and Simon Wardley
Nov 17 2022
Serverless Craic Ep38 It began with the forging of the Great Maps and Simon Wardley
It began with the forging of the Great Maps and Simon Wardley We've been talking this week about Wardley mapping. 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. 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. 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. 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!'.  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. 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 EdgeCheck out our book The Value Flywheel Effect Follow us on Twitter @ServerlessEdge
Serverless Craic Ep37 What is Engineering Excellence?
Nov 12 2022
Serverless Craic Ep37 What is Engineering Excellence?
What is Engineering Excellence?Few companies say they don't want good engineering.  But they don't define what good looks like. And secondly,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! 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.  If 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. 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 problemsServerless Craic from The Serverless EdgeCheck out our book The Value Flywheel Effect Follow us on Twitter @ServerlessEdge
Serverless Craic Ep36 The Value Flywheel Effect Book Launch
Nov 2 2022
Serverless Craic Ep36 The Value Flywheel Effect Book Launch
We are just back from The Value Flywheel Effect book launch at DevOps Enterprise Summit organised by IT Revolution with Gene Kim and crew. 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 LearnWardleyMaps.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. 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 TalkI 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. It's important to remember that the map is not important. 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 SigningThere was a huge queue and I was there for two hours signing 200 books. Propelo sponsored our book signing and they were great. 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.  Psychological safety is usually the base or foundation of the map. 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 EdgeCheck out our book The Value Flywheel Effect Follow us on Twitter @ServerlessEdge
Serverless Craic Ep35 DevOps Conference Preview of DOES 2022
Oct 19 2022
Serverless Craic Ep35 DevOps Conference Preview of DOES 2022
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. 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. 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 we will have a good conversation and interaction.  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 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.DevOps Enterprise Summit Serverless Craic from The Serverless EdgeCheck out our book The Value Flywheel Effect Follow us on Twitter @ServerlessEdge
Serverless Craic Ep34 What is Value Engineering with BMK
Oct 13 2022
Serverless Craic Ep34 What is Value Engineering with BMK
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 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? 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. 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.  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 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. 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.  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 EdgeCheck out our book The Value Flywheel Effect Follow us on Twitter @ServerlessEdge
Serverless Craic Ep33 How to apply the well architected tool
Sep 28 2022
Serverless Craic Ep33 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. 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. 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. 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.A cloud provider writes a framework in their own language. And it will have a bias towards their own products. 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. 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 discussionSCORPS process on ThServerless Craic from The Serverless EdgeCheck out our book The Value Flywheel Effect Follow us on Twitter @ServerlessEdge
Serverless Craic Ep32 The Second Cloud Transformation
Sep 23 2022
Serverless Craic Ep32 The Second Cloud Transformation
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?  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.  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. 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:InventServerless Craic from The Serverless EdgeCheck out our book The Value Flywheel Effect Follow us on Twitter @ServerlessEdge
Serverless Craic Ep31 Event Driven Architecture Examples at EDA Day
Sep 16 2022
Serverless Craic Ep31 Event Driven Architecture Examples at EDA Day
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!Serverless Espresso Julian Wood, 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. 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 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 EventBridgeDavid 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. Look up his resources on ‘Awesome EventBridge’.Marcia Villalba - FooBar Serverless Marcia Villalba is a 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.  Check out her FooBar Serverless YouTube channel. There is tons of developer friendly content from beginner to more advanced. Lego Talk - Sarah Hamilton and Sheen BrisalsThe 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 panelThe 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 forServerless Craic from The Serverless EdgeCheck out our book The Value Flywheel Effect Follow us on Twitter @ServerlessEdge
Serverless Craic Ep30 AWS Serverless Services with Paul Swail from Serverless First
Sep 8 2022
Serverless Craic Ep30 AWS Serverless Services with Paul Swail from Serverless First
AWS Serverless Services with Paul Swail from Serverless FirstIn this episode the team talk about AWS Serverless Services with Paul Swail. Paul is an independent Serverless Consultant helping teams get started with serverless on AWS.The Value Flywheel Effect Book ReviewPaul 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 FirstWe 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 StackWardley 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 ServerlessBen 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 ContextThere'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 vagueI 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.Serverless MaturityWe 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? 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. Because it's a big overhead for for developers to learn without AWS certifications.ServerlessFirst.com and @PaulSwail Serverless Craic from The Serverless EdgeCheck out our book The Value Flywheel Effect Follow us on Twitter @ServerlessEdge
Serverless Craic Ep 29 What is Long Term Value - Phase 4 of Flywheel?
Aug 31 2022
Serverless Craic Ep 29 What is Long Term Value - Phase 4 of Flywheel?
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. 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.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 EdgeCheck out our book The Value Flywheel Effect Follow us on Twitter @ServerlessEdge
Serverless Craic Ep28 Next Best Action - Phase 3 of the Value Flywheel
Aug 24 2022
Serverless Craic Ep28 Next Best Action - Phase 3 of the Value Flywheel
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. It's trusting your cloud provider platform to have the capability to do something. And just use it.  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.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 Edgetheserverlessedge.comServerless Craic from The Serverless EdgeCheck out our book The Value Flywheel Effect Follow us on Twitter @ServerlessEdge
Serverless Craic Ep27 Challenge Tech Strategy - Phase 2 of Flywheel
Aug 17 2022
Serverless Craic Ep27 Challenge Tech Strategy - Phase 2 of Flywheel
It's important that engineers challenge tech strategy. Challenge is about the environment. When you decide on a strategy, do you have the right environment to challenge it?  In the last episode, we talked about Phase 1 of The Value Flywheel Effect: Clarity of Purpose and setting direction.  The Value Flywheel Effect is our book which is available for preorder.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.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.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. 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. 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 EdgetheserverlessedServerless Craic from The Serverless EdgeCheck out our book The Value Flywheel Effect Follow us on Twitter @ServerlessEdge
Serverless Craic Ep26 Flywheel Strategy Applied with Phase 1 Clarity of Purpose
Aug 11 2022
Serverless Craic Ep26 Flywheel Strategy Applied with Phase 1 Clarity of Purpose
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? 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.  Without clarity of purpose, you are 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.. 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. 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 EdgetheServerless Craic from The Serverless EdgeCheck out our book The Value Flywheel Effect Follow us on Twitter @ServerlessEdge
Serverless Craic Ep25 Intro to the Value Flywheel Effect
Aug 4 2022
Serverless Craic Ep25 Intro to the Value Flywheel Effect
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. 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'.  Business and IT need to look at 'what is our mission'?  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. 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?  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 ActionThe 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.  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  about removing those impediments to fast flow. Can we quickly get an idea into the hands of real users to get valid feedback. 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 ValueThe 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. 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 Edgetheserverlessedge.comServerless Craic from The Serverless EdgeCheck out our book The Value Flywheel Effect Follow us on Twitter @ServerlessEdge
Serverless Craic Ep24 Clarity of Purpose with the North Star Framework
Jul 7 2022
Serverless Craic Ep24 Clarity of Purpose with the North Star Framework
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!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.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.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 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.  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 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 FrameworkJon CutlerSimon Sinek: 'Start with Why' & 'Golden Circle'. Serverless Craic from The ServerServerless Craic from The Serverless EdgeCheck out our book The Value Flywheel Effect Follow us on Twitter @ServerlessEdge
Serverless Craic Ep23 Top 8 Principles for Cloud Software Engineers
Jul 1 2022
Serverless Craic Ep23 Top 8 Principles for Cloud Software Engineers
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. 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. 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. 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? 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.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. 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. 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. Serverless Craic from The Serverless EdgetheserServerless Craic from The Serverless EdgeCheck out our book The Value Flywheel Effect Follow us on Twitter @ServerlessEdge
Serverless Craic Ep22 How to start cloud computing
May 26 2022
Serverless Craic Ep22 How to start cloud computing
We found out that 'how to start cloud computing' is a burning issue from our meetup BelfAWSt. And it is a community Meetup in Belfast, to talk about all things AWS! 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. I also have used A Cloud Guru.  More recently, 'Skill Builder' has become freely available. Udemy courses are really good.  And other Cloud Providers have similar educational materials. I really like the foundational white papers. There's four or five core white papers that are worth reading. If you attempt a certification, and you read those white papers, it's still beneficial. The PDFs are free and you can download them. 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. 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 last thing is the whole idea of patterns. Matt Coulter has CDK Patterns and CDK Day.  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. Patterns: Community: Craic from The Serverless EdgeCheck out our book The Value Flywheel Effect Follow us on Twitter @ServerlessEdge
Serverless Craic Ep21 Become an awesome software architect with these 12 books
May 20 2022
Serverless Craic Ep21 Become an awesome software architect with these 12 books
We have picked out our top books that have influenced us and our '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. 2. 'Domain Driven Design' describes good domain models and the importance of collaboration, communication and shared understanding, You can be in different types of stacks or scenarios, but the knowledge is abstract so it's applicable. 3. The Simon Wardley Book I find myself always going back to it. It's chunky and quite academic. But it's as deep as well. 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' This is a game changer.   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. 5. 'Extreme Ownership' 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.6. 'Team Topologies' It's such a powerful question to ask 'what type of team are you?'  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 etc. 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, organisational and architectural approaches you should adopt. 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.  9. 'Creativity Inc' 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' 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?  11.  'Ask Your Developer' looks 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 and on developer experience, their golden path and off roading. 12.  'The Software Architect Elevator' 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'.The Serverless Edgetheserverlessedge.comServerless Craic from The Serverless EdgeCheck out our book The Value Flywheel Effect Follow us on Twitter @ServerlessEdge
Serverless Craic Ep20 Modern Cloud
Apr 8 2022
Serverless Craic Ep20 Modern Cloud
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'.  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.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 misServerless Craic from The Serverless EdgeCheck out our book The Value Flywheel Effect Follow us on Twitter @ServerlessEdge