Serverless Craic from The Serverless Edge
Serverless Craic Ep1 DevOps Enterprise Summit 2021

Serverless Craic Ep1 DevOps Enterprise Summit 2021

December 24, 2021

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:…

Our Talk: 'The Serverless Edge, Using Wardley Mapping with the Value Flywheel from combined Business and Technology Evolution' 

Slides: (including ours under Dave Anderson):

New Book announcement

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:

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:

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 -,  and similarly with Bank of New Zealand -  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


Serverless Craic Ep2 Map Camp

Serverless Craic Ep2 Map Camp

January 12, 2022

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.
New Book from David Anderson

Serverless Craic from The Serverless Edge

Serverless Craic Ep3 Matt Coulter and Liberty Mutual

Serverless Craic Ep3 Matt Coulter and Liberty Mutual

January 14, 2022

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  He is an Architect for Liberty Mutual, an AWS DevTools Hero and Serverless Architect sharing reusable, well architected, serverless patterns over at 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.

Matt Coulter: @NIDeveloper

Serverless Craic from The Serverless Edge

Serverless Craic Ep4 Sustainability

Serverless Craic Ep4 Sustainability

January 14, 2022

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

AWS re:Invent 2021

AWS re:Invent 2021

January 14, 2022

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

Serverless Craic Ep5 Rapid Delivery

Serverless Craic Ep5 Rapid Delivery

January 21, 2022

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

Serverless Craic Ep6 Purpose

Serverless Craic Ep6 Purpose

January 21, 2022

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

Serverless Craic Ep7 Security

Serverless Craic Ep7 Security

January 21, 2022

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

Serverless Craic Ep8 Well Architected Operational Excellence Pillar

Serverless Craic Ep8 Well Architected Operational Excellence Pillar

January 21, 2022

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

Serverless Craic Ep9 AWS Security Pillar

Serverless Craic Ep9 AWS Security Pillar

January 21, 2022

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

Podbean App

Play this podcast on Podbean App