Forem: The Serverless Edge

How to use the Cloud

The Serverless Edge — Wed, 24 May 2023 13:05:59 +0000

Modern Cloud is a phrase that we use a lot. It’s hard to explain what it means without thinking about legacy cloud. Gregor Hohpe has a great description. He says; ‘If you lift and shift to AWS (or any of the cloud providers), and don’t modernise your architecture, all you’ve got is a fancy data centre!’. You’ve moved your old data centre to a cloud level data centre. So you’ve got a top of the range data centre, but you’re not actually benefiting from Cloud.

.
Mike, Mark and Dave introduce the Modern Cloud and how to implement it for your org
.

Going beyond ‘lift and shift’

Dave Anderson

So there’s a term called Modern Cloud. I thought it would be interesting to dive into that. It’s a phrase that we use a lot. But a lot of people are asking: ‘What does modern cloud, modern application or modern architecture actually mean?’ It’s hard to explain what it means without thinking about legacy cloud. Gregor Hohpe has a great description. He says; ‘If you lift and shift to AWS (or any of the cloud providers), and don’t modernise your architecture, all you’ve got is a fancy data centre!’. You’ve moved your old data centre to a cloud level data centre. So you’ve got a top of the range data centre, but you’re not actually benefiting from Cloud.

I spoke to a company a year or two ago, who had a five step maturity model for the cloud. And they asked me about serverless first. And when I responded they said: ‘Oh, you’ve just described step seven!’. They hadn’t moved beyond modern cloud practices. So I thought it might be good to do a series on modern cloud. But before we get into that, what do you guys think modern cloud is?

Continuous style architecture

Mike O’Reilly

Good question. There’s a lot of dimensions and lenses to that question. But the way I see it is that ‘lift and shift’ is where we are lifting what we have in there and it’s now running . But are you really taking advantage? Is your organisation taking advantage? Is your team taking advantage of all the capabilities that exist within the cloud space? In order to take advantage of those things, you have got to operate in a certain way.

There are modern cloud operations that we’ve talked about in previous episodes, like well architected and what serverless teams do. It’s about being able to take advantage and really get into continuous style architecture. But doing that in a sustainable and safe fashion.

Mark McCann

It’s about reducing time to value, in a sustainable way, so you’re not accruing technical, organisational and process debt. If you’re leveraging modern cloud to its maximum and if you’re following a serverless first approach, you’re able to go fast and sustainably over a decent period of time. Because you’re not building up technology debt that you have to pay down which slows you down in the long run. If you’re in modern cloud, doing serverless first, and leveraging well architected, you’ll feel the benefits and your business will see the benefits.

Graduation of IT

Dave Anderson

Nicole Forsgren called it out in her book: ‘Accelerate: Building and Scaling High Performing Technology Organizations’. Modern cloud is like the graduation of IT into the actual business by coming away from being a department to driving the company forward. You’ve got the speed to drive the company forward and be involved in the business conversation as opposed to being ‘in the wheelhouse shovelling coal’. So it’s about the graduation of IT and the change from being a cost centre and to value generation. There is an interesting point about modern cloud and technical debt. If you’re set up well, you’re not creating tonnes and tonnes of technical debt.

Mike O’Reilly

With continuous architecture, you’re operating in the modern cloud within the modern cloud paradigms like event driven architecture, leveraging managed services and well architected patterns, so you’re continuously evolving what you’re building. When you treat code as a liability and have well architected teams working in a modern cloud, you’ve got great observability. They’re constantly rebuilding, refactoring and evolving to build upon what they’ve done in previous projects on the platform.

And by using strategies like ‘pioneer, settler, town planner’ and ‘innovate, leverage, commoditize’, you tend not to hold on to anything that you’re not leveraging. You are not accruing a lot of debt. You’re continuously modernising, which means you’re constantly managing that side of your architecture.

Ability to adopt new capabilities

Mark McCann

Because you’re optimised, when new capabilities, features or services come along, you can rapidly innovate and leverage them for differentiating value. If AWS or Google release a new service or feature, when you’ve managed down your code liabilities and you’re working in an optimal way, you can embrace that rapidly, within days. We have examples in our career. Something is announced and our teams are leveraging it the next day or the next week. When you have a good modern cloud stance, that’s possible. If you don’t then it’s going to take years down the road for you to be able to embrace those new features and capabilities.

That could be the difference between your business making it or not making it! There’s a real business differential to be gained from embracing a modern cloud approach. If you’re higher up the value chain you’re going to have more business impact. You’re more visible to the business, because you’re actually driving business success.

Dave Anderson

One of the things that is very hard to define with ‘modern cloud’ is technology. There are companies using Lambda that are in legacy, because they’re using it wrong. And there are people using EC2’s that are working in a modern and progressive way. You have to be clinical about your technology choice to use it well.

Wardley Mapping enables the Modern Cloud

There’s no such thing as a good or bad technology choice. It’s how you use it to solve your problem. So it’s not a matter of saying, Lambda is good and a Container is bad. A lot of people outside technology find it hard to deal with the fact that technology changes so quickly. It’s actually nothing to do with the technology choice. It’s about how well your teams are planning to use it.

Mark McCann

That’s where Wardley Mapping comes to the fore by allowing you to understand the users, the user needs and the value chain of technology that you have at your disposal to meet those needs. As well as choosing the right tool for the job. So a well optimised EC2 instance, for this particular use case may be perfect. You can justify the additional runtime and operational burden, because you have good situational awareness about your tech stack and the choices you’re making. Teams that are operating in the modern cloud have that situational awareness, and they understand the trade offs for the technology choices they make. They can justify that all the way up the chain to the actual needs of the users.

Photo by Sendi Gibran on Unsplash.com

Spotting the inertia

Mike O’Reilly

I think that’s a cracking point. We always describe inertia in Wardley maps and spot teams and tech that suffer from inertia. You’ve hit the nail on the head Dave. Inertia can be not looking after something within a lambda function that means we go back and continuously look at it, fix it or patch it. We haven’t thought about the longer term or what its role is other than for this solution. You can have an EC2 container with operational capability around it. We’re patching all the time, all our dependencies are up to date, we’re getting ready to move mobility, we’re always thinking about the next thing and is this the right piece of kit for the problem we’re trying to solve? There’s a mindset element which comes from teams working in a modern cloud way.

Dave Anderson

DevOps going from infrastructure to DevOps to SRE, to ‘you build it, you own it, you run it’, is very complicated because it’s changed so much over the past 10 years. One of the acid tests is how DevOps is talked about in the company. If you’ve lots of handoffs and developers are sitting waiting on other teams, then that’s a bad sign. A modern cloud team can do everything themselves. They rarely need to go outside their team for help.

The need for enabling teams

Mark McCann

They’re ‘fast flow’. There’s very few handoffs, You still need, not necessarily a DevOps team, but you need enabling teams. There are complicated sub-system teams to ensure that your streamline teams or your fringe stack teams have all the experience, expertise and capabilities to do what they need to do without having to talk to anybody. As Team Topologies say, your streamline teams are set up for success and they’re able to move without friction, without handoffs or dependencies on anybody. They have the organisational structure to make sure it’s done appropriately and the guardrails are the right ones for business.

Dave Anderson

There’s a good train analogy. The train driver and staff in the train can drive the train from A to B. But they still need someone to lay the track, work the signals and repair the train. You’re not doing it on your own. There’s other things providing other services. Well architected is a factor as well, which we’ve talked about. And there’s ‘time to market’ and how fast the team can deliver.

Mark McCann

The flywheel effect

Observability is critical for the team’s to know how they’re delivering with good radiators and good dashboards with frequency, mean time to restore and your lead time for change. The DORA four keys metrics are part of that as well as the well architected pillar and your adherence to them. Teams should have a good understanding of where they are on that journey. It’s critical for teams that are adopting modern cloud to know their current status and how well architected they are to know how to evolve and improve.

Dave Anderson

It’s an interesting discussion. It’s worth going through the flywheel that we talk about in our upcoming book. We talk about how to be effective in the modern cloud. In the flywheel, we look at ‘Purpose’ which is the strategy of the business/company and the ability to challenge, have an environment for success and the right culture in the organisation. ‘Next Best Action’ is from a developer’s point of view and looks at design patterns, processes and DevOps. ‘Long Term Value’, is about architecture, data security and sustainability. It’s interesting to look through those lenses at ‘modern cloud’. What’s our goal when we talk about the modern cloud? Do you think it is well understood? Or is it changing so fast that nobody knows.

You don’t arrive overnight

Mike O’Reilly

Whether you’re a CTO, an architect, or a developer, it’s good to understand the art of the possible. What does good actually look like? What can we actually do? And the direction and pathway towards that. You don’t arrive overnight. If you look at AWS, for example, in terms of how they get people into the cloud, there’s a seven step process. Initially, there’s a ‘lift and shift’. But once you’re there, what next? There are many ways to evolve. It’s good to have a conversation to acknowledge and accept it. You can do it. It just takes time and you have got to keep your eye on it.

Dave Anderson

Was that the 7 hours of cloud migration?

Mike O’Reilly

Yes!

Mark McCann

Our goal is to start sowing seeds by putting questions into people’s heads about what is possible and what good looks like. Hopefully, we can shed light on what works, what we have experienced in our careers, the benefits, the pitfalls and the things that are good for when you’re going down this path, because it’s not easy, but it’s well worth doing. In today’s competitive global landscape, you need to be leveraging the modern cloud properly.

Dave Anderson

That’s the opportunity. So that’s the craic. We’ll flesh these ideas out over the next couple of episodes. Thanks very much for listening. Our blog is at TheServerlessEdge.com. We’re @ServerlessEdge on Twitter and other channels as well. Thanks very much.

How to pick your favourite Well Architected Framework Pillar

The Serverless Edge — Thu, 11 May 2023 13:37:47 +0000

Designing and developing systems is similar to constructing a physical building. If the foundation is not solid, it may cause structural problems that undermine the integrity and function of the building. So you need to look at all six well-architected framework pillars for your workloads.

.
Dave, Mark, and Mike pick their favourite AWS Well-Architected Pillars
.

Dave Anderson

This is our last chat about the AWS Well-Architected Framework Pillars. This is the big one! What’s your favourite well-architected pillar? Over the past six episodes, we have gone over the well-architected framework from AWS. As a recap, we think this is a fantastic framework. It’s about your workload. Like a physical building, if the foundation is not solid, it may cause structural problems that undermine the integrity and function of the building. So you need to look at all six pillars for your workloads. And that’s what you do to effectively produce sound and stable systems.

Well-architected framework pillars

The first one is operational excellence. I’ve got some blurb here: it’s the ability to run and monitor systems to deliver business value, and continually improve support, processes, and procedures. That’s a good one.

Security: the ability to protect information systems and assets, while delivering business value through risk assessments and mitigation strategies.

Reliability: the ability for systems to recover infrastructure or service failures, acquire computing resources to meet demand, and mitigate disruptions such as misconfigurations, or transit network issues.

Performance efficiency: the ability to use compute resources effectively to meet system requirements, and maintain efficiency.

Cost optimization: the ability to avoid or eliminate unneeded cost.

Sustainability: guidance and how AWS can help you reduce your footprint and best practices to improve the sustainability of your workloads.

So there are six really solid pillars. The moment of truth has arrived! Mike, I will ask you first: what is your favourite pillar?

Operational Excellence

Mike O’Reilly

They’re all my favourite! I always go back to the first well-architected pillar. It’s the first one in the well-architected reviews: operational excellence. The reason I like this one is because I’m a big fan of continuous improvement and getting yourself into a sustainable way of working. How do you learn from failure or react to certain things? How do you have visibility of everything around you? If you can assemble that apparatus and those behaviours, then you can begin to eat into the other pillars. For example, operational excellence gets into how to observe if something’s working in production, or if something’s failing in production.

If something’s failing in production, how do you deal with it? Do you have ‘run books’? Do you have playbooks? What’s your playbook say about this scenario? It’s fundamental and core. It’s where I start. If I’m going into a new team or area, I’ll always start with operational excellence. This one is very consistent across all squads and all parts of the organisation. That’s probably my favourite, because I know it so well and I rely on it.

Dave Anderson

Mark, what about you?

Sustainability Pillar

Mark McCann

They’re all very good and very strong pillars. But I think my favourite well-architected pillar now is the new one, the sustainability pillar. I think it if you have all other things in place, the sustainability pillar will really drive you to that next level. If you’re trying to deliver a sustainable solution, you can’t do that without having a good handle on the other five pillars. So I think sustainability and the sustainability pillars and the questions within them, are a forcing function for good practices, processes, and architectural choices that the other pillars are continuing. With our serverless first mindset and approach, I think it lends itself well to the sustainability pillar. I think sustainability is probably my favourite now. Also, we want to make sure that we leave the world a better place than what we found it. So if we don’t deliver sustainable workloads (especially with the exponential growth of compute devices in the digital era) it’s not going to be good for the long-term health of the planet and for the people on earth.

Security, Reliability, and Cost Optimization
Dave Anderson

Very good. I am going to cheat and pick three well-architected pillars! The three I’m thinking about are security, reliability, and cost optimization. The reason why I like those three is because they’re things that a different team does. If a team thinks they’re really good but completes one of those pillars, they realise there’s a bunch of stuff they’ve never thought about but actually is their responsibility. The most shocking one is probably cost optimization. Most teams don’t really think about the cost. There’s usually an IT manager somewhere who does it. It’s magic and it happens in the background. But when you start asking teams about how they monitor or control their cost and optimise for cost, it spins their head. I like the shock factor of that and also the fact that it’s about real money. If you make a tweak, you can actually save your organisation money. It’s green dollars and not pretend money. So I always enjoy it when teams are connected back to reality. I think that’s interesting.

Photo by Sara Scarpa on Unsplash.com

Mark McCann

With carbon score tools coming online that same sort of conversation can happen: what’s your carbon score? Do you know what your sustainability for print is? I’m looking forward to that as well, for the exact same reasons. It will allow us to ask better questions of teams.

Your architecture is your cloud bill

Dave Anderson

As you say, Mark, your architecture is your cloud bill. I think that is a great question. When a team tells you about a fantastic thing that they’ve built, and you ask what it cost, it levels everything. If it’s in the thousands, you’re thinking uh oh, okay? In relation to the well-architected pillars, AWS will often come and do an audit, which I think is a good service. But they also talk about the self-service option. We’ve used it a number of times. It’s like a self-help tool for teams. Let the teams use the well-architected pillars as good practice, to see where they would like to improve. So it’s designed to be used as a support function for the teams and not a judgement on the organisation.

Mike O’Reilly

It’s a safe space. It’s very conversational and helps you to set goals and connect teams together. There are teams that do certain things well and others that want to aspire to that. So it’s awesome.

Whole team exercise

Mark McCann

We’ve written a couple of articles about this on TheServerlessEdge.com. It needs to be a whole team exercise and a collaborative facilitated exercise. It’s not a ‘one and done’. It needs to be done regularly and over time. It can’t be used to judge teams or beat teams. It’s got to enable them with better information, better questions to ask, and then empower them to actually improve.

Mike O’Reilly

Use those milestones.

Dave Anderson

There’s an interesting thing that I find with this. People ask about what’s compliant. What’s the mark that you need to pass well architected? I think not! One team’s good security might be another team’s bad! Because it depends on the workload and what the requirement is. So it’s not the fact of what’s good enough. It’s the fact of how confident you feel you meet your requirements. Every workload has different requirements. That’s the way you need to think of it. You can’t judge a team. You can ask: ‘Are you happy that you’ve done what you needed to do?’. And the framework helps you to do that.

Is your solution well-architected?

Mark McCann

There’s a great question, that you use a lot Dave: ‘Is your solution well architected?’ By listening to what a team has to say in response gives you a good idea of where they’re at on their journey.

Dave Anderson

Maybe we should end with our famous saying that we used to use all the time: ‘Are you well architected? It’s like when the doctor asks if you eat your ‘five a day’. You can say no and you’re being honest. You can say yes, but you eat fruit pastilles instead of fruit so you’re lying to your doctor! Or you can say yes and you’re informed and educated. We know that ‘five a day’ means five portions of fruit and veg. So if you lie to your doctor, it’s only you that you’re kidding. It’s the same as well architected. If you ask a team of architects, they can say no, we have work to do, or yes we are. Or the fun starts when they try to pull the wool over your eyes. That’s when it gets interesting.

Mike O’Reilly

There’s no point in being defensive. It’s a safe space.

Dave Anderson

It’s your own workload! So that’s the craic! That was the well-architected framework. You can see more on The Serverless Edge, Twitter @ServerlessEdge, YouTube, and our Podcasts. Please like, subscribe, and follow! Thanks very much.

Sustainability benefits from the AWS Sustainability Pillar

The Serverless Edge — Thu, 27 Apr 2023 09:59:04 +0000

We share our thoughts on the AWS Sustainability Pillar that forms part of the Well Architected Framework. This is the sixth and final part of a series of talks.

The AWS Sustainability Pillar is a new pillar that was announced at AWS re:Invent. What’s nice about sustainability is that it rolls up a lot of good practices and it’s a very simple measure.

AWS Sustainability Pillar on our Well Architected Series

Dave Anderson

We’re continuing our conversation on the well architected pillars.

Today we’re talking about the AWS Sustainability Pillar. We’ve talked quite a lot about sustainability. It’s a new pillar that was announced at AWS re:Invent. So we’ve talked about it a fair amount, because (1) it’s new and exciting and (2) because we’ve been following this for the past two years and it’s a brilliant addition. What’s nice about AWS sustainability is that it rolls up a lot of good practices and it’s a very simple measure.

It’s very hard to measure carbon, but very simple to understand when someone, like AWS measures for you. This pillar is slightly different, it doesn’t have all the same kind of questions. Maybe they might change it eventually. But it’s more like a list of best practices that are broken down into sections. So let’s list them out:

Region Selection,
User Behaviour Patterns,
Software and Architecture Patterns,
Data Patterns,
Hardware Patterns,
and Development and Deployment Process.

There’s a bunch of questions within those. Let’s fly through them.

Region Selection

Mark McCann

Some regions are supplied with greener energy than others. Some regions are using non sustainable resources, depending on where you are in the world. If you don’t have massive latency requirements, or a real need for super fast, low latency, then you’re probably best putting it into a more sustainable region. US 1 and Ireland are sustainable regions. There’s others across the AWS ecosystem. Google and Azure have the same. So where you put your workloads can have a sustainability impact. All other things being equal, go for the greener one. Go for the most sustainable region for your workload.

Dave Anderson

Some regions are not sustainable, and some are very sustainable. There’s a nice phrase that Werner Vogels used during the launch that Adrian Cockcroft also uses: ‘the cloud providers look after the sustainability of the cloud, they’ll make the data centres as sustainable as possible. It’s our responsibility to look after sustainability in the cloud.’. So they’ll have a sustainable datacenter, we have to design sustainable workloads. So I thought that was a nice kind of split. With region selection, if they say a certain region is green, you should try and put workload there.

The difficulty of sustainability and your own data centres

Mark McCann

With a move to the cloud, if you’re on your own data centres, you’re going to have a hard time trying to be as sustainable or green as the cloud providers, because they’re investing hundreds of millions or billions probably across the globe to sustainably power, cool and provide all the resources they need for the for the data centre.

Mike O’Reilly

What’s going through my head is the shared responsibility model. A lot of what the white paper gets into for that pillar is understanding the separation of responsibility. It’s good to touch upon those as we run through it. It’s major that cloud providers are going to keep their side of it as green as possible. And also coaching you, as an architect or business owner, on how to make good decisions in relation to what you’re doing in your space and what you’re building on the cloud and the various sustainable approaches.

Dave Anderson

This is the whole premise of the cloud. An organisation like Amazon, Microsoft or Google will do data centres better than you. If you look at User Behaviour Patterns and you use their assets in an elastic way using the latest technology, it will be more sustainable, efficient and cheaper on modern cloud. If you go down the legacy cloud route, and treat the public cloud like a data centre, then you’re not going to be very sustainable, you’re not going to be very cheap, and you’re not going to be very efficient. So it’s that elasticity thing that I know was popular 10 years ago when the cloud started, but people seem to have forgotten about it.

User Behaviour Patterns

Mark McCann

Under the User Behaviour Patterns section it’s about how do you align your SLAs with your sustainability goals. That screams out at me, especially with the COP events. With the requirement for boardroom level mandates these concerns are going to be more prevalent and visible to all teams, up and down the hierarchy. You’re going to be asked about how green your solution is. How green is your product? How green is your business? Making sure workloads and solutions on the cloud are aligned to SLAs is what we’re going to be concerned with over the next number of years.

Dave Anderson

It’s no different to when you buy a soft drink. You’ve got to know if it’s in sustainable packaging. It’s a big issue. In the future, when you use a digital service, you’ll want to use something sustainable which is effectively cloud.

Software Architecture Patterns

The next section is Software Architecture Patterns. I think this one is interesting. It’s about keeping your code base and your architecture really efficient such as refactoring optimization and more effective data access.

Mike O’Reilly

It’s good practice as it ties back into efficient design. When you work in enterprise spaces, you do question the value of older business products that are running in the background. You’ve got to constantly assess if this is worth the compute? Is this worth the cycle times? Are we really getting value for money? Now you’ve got to factor in sustainability. Is it racking up your carbon footprint? It’s another factor to consider. Should we invest time in reducing the amount of maintenance? How efficiently or inefficiently is something running? This is definitely an interesting area for people working in large organisations where they’re supporting lots of different apps and different workloads.

Impact on devices

Mark McCann

There’s an interesting question on optimising the impact on customer devices and equipment. If you have a really inefficient client side app with a lot of data processing on the device that it doesn’t need, you could sustain the lifetime of that device by having a more effective and efficient client side app or web app or mobile app. There are lots of things we can concern ourselves with.

Dave Anderson

If you’re on a mobile app, do you need to send the biggest image possible over the network? And make the device or optimise it accordingly? Or can you optimise it ahead of time? There’s a bunch of stuff around not being as fast as you need to be. Another thing about architecture is that in the olden days, there were constraints. So you had to do proper architecture. I would imagine that there’s some modern apps with massive amounts of scale. As it scales, the architecture is not ready for it and they are relying on the network. You’ve got modern technology, but it’s not optimised.

Mark McCann

The question is ‘how do you use software patterns and architectures that best support data access and story patterns?’. If you’re following a serverless first approach, you’re well on the road to being sustainable.

Think in terms of limited resources

Mike O’Reilly

Bad design has an impact on users and their devices. They could be using unsustainable resources to charge their machines or phones. I always think about IDEs and the bigger IDEs in terms of auto completion and indexing because they get very warm very quickly! I’ve seen a lot of IDEs moving onto the cloud: Cloud9 and VS code. And you’re thinking that all of that should be done in the cloud too. Right now in the UK, energy prices are going through the roof. My energy bill has doubled in the last month. So if I can do anything to reduce that, it helps me as well.

Dave Anderson

I wonder if it has come full circle. I’m old enough to remember the olden days when CPU, memory, disk and network were limited. You had to design and take into consideration your poor resources. I’s going back that way again. We should be thinking of limited resources, so you’re not using what you don’t need.

Mark McCann

A very thin client for all your needs. And everything is done in the cloud, server side, from your IDE to everything else.

Photo by Casey Horner on Unsplash.com

Data Patterns

Dave Anderson

So the next section is Data Patterns. It’s a huge one. There’s an awful lot of waste with data flying around the internet. Again, we quote, Adrian Cockcroft: ‘If you collect a piece of data, and don’t put it directly into a model, you should just delete it.’. Because you don’t need it! It is a bit extreme, but it’s a great idea.

Mark McCann

There’s a lot of good practice here. Data can be quite toxic for various reasons from privacy breaches and security points of view. You should have a good handle on this. Your data classification is critical. If you don’t extract value from it, get rid of it or it’s going to be unsustainable.

Mike O’Reilly

This is what I’m interested in. I’d love to learn more, dig into it and just see how it unfolds. Everything’s becoming more data centric, and the amount of compute that goes into chomping data is 90% of what IT. I’d love to see how much electricity or energy is used on processing data. I am keen to see how organisations approach this one.

Mark McCann

How do you minimise data movement across networks? That’s huge, right? Only move what you need for when you need it and not just move everything for the craic!

Dave Anderson

I wonder when they will start egress charges when you’re going out to the cloud? I wonder if they will start doing more of that. That’s a big one.

Hardware Patterns

The next one is Hardware Patterns, which is right sizing our stuff correctly. We’ve all been in teams where the question asked is: ‘what size box do you need?’ And the answer back is: ‘the biggest one humanly possible!’. It’s a natural reaction but you don’t need that.

Mark McCann

This is where a serverless first mindset and approach really kicks up a gear. You don’t even have to concern yourself with a lot of these questions. It automatically scales up and down appropriately. We don’t have to worry about picking hardware or incident sizes ahead of time.

Dave Anderson

A good one is the Lambda Power Tuner. It will help you pick the optimum hardware size. And sometimes it’s not the biggest that is the most efficient.

Mark McCann

With Graviton chips coming in, immediately, you are on a more sustainable compute platform without having to do too much.

Development and Deployment Process

Dave Anderson

The last section of the AWS Sustainability Pillar is Development and Deployment Process. How do you increase utilisation of build environments? Build everything all the time!

Mark McCann

We see this quite a lot where environments sprawl and asset’s sprawl for no real benefit. So again, it’s all about being smart about how you set up your clients, how you set up your pipelines and how you set up your environments to make sure they’re actually delivering value. And they’re not just there because that’s the way we have always done it.

Dave Anderson

And people running huge test suites that go on for days. And publishing results that no one ever looks at.

Avoid the sprawl

Mark McCann

The question here is: ‘how do you adopt methods that can rapidly reduce or introduce sustainability improvements?’. If you’re on a serverless spectrum, the cloud providers are working for you and they’re introducing new capabilities. Graviton is a great example. It’s lower cost, more powerful, better performing, but it’s also more sustainable. If you’re on a serverless way of delivering your solution, you can just take advantage of that instantaneously.

Mike O’Reilly

You need to make sure your design and architecture can move with those innovations. That’s a large part of the spirit of that, like Graviton and different chipsets and making the shift towards getting advantage of that.

Dave Anderson

So that’s the AWS Sustainability pillar.

That’s the craic. Next time we’ll be looking at all six pillars to see which one we like the best. Thanks for listening. There is more on TheServerlessEdge.com, our YouTube channel, Twitter @ServerlessEdge and Podcast. Thanks very much!

Transcribed by https://otter.ai

Our guide to the AWS Cost Optimization Tool

The Serverless Edge — Thu, 30 Mar 2023 11:44:08 +0000

We continue our overview of the Well-Architected Framework with our take on the AWS Cost Optimization Tool. Serverless has changed how IT is funded from large enterprise investments written off over several years to pay as you go incremental payments on a weekly or monthly basis. In other words Opex v Capex.

AWS Cost Optimization Pillar which is fifth in the series of talks on the Well Architected Framework

Dave Anderson

We continue our journey through the well-architected pillars and our quest to find our favourite pillar. There’s no order, but we’re on the fifth pillar which is AWS cost optimization. I think this is one of my favourite ones because basically no one understands it or knows what it is. I think it’s got much better now with the modern cloud. Like the other pillars, there are 10 questions and 5 subsections:

Practice Cloud Financial Management
Expenditure Awareness
Cost Effective Resources
Matching Supply and Demand
Optimizing Over Time

Practice Cloud Financial Management

The first one is Practice Cloud Financial Management. How do you implement cloud financial management? Most people say: ‘we don’t know what that is!’. I always thought it was great fun to ask a development team: ‘how much did that cost? Most of the time, you get back a blank stare!

Mark McCann

It’s a maturity step for teams to be able to respond and know how much their stack costs. If you get blank stares, then you know you need to dig a little deeper into their operational excellence, observability, and general engineering practices. Good engineers have an awareness of this but they need to be pointed in the right direction. Cloud financial management doesn’t need to mean ‘big, scary, or loads of spreadsheets’, it can be as simple as knowing your monthly or weekly bill.

Mike O’Reilly

There has been a big shift in architecture since we’ve got more visibility into cost in the last number of years. When you were working on the enterprise mainframes, you were dealing with capacity. And maybe you did get into licensing and availability of licensing but you never talked in terms of cost. Moving out from mainframes and into the cloud, you go expansive with extrapolated architecture to fit whatever scale you’re working to. You definitely have to factor cloud financial management into your decisions with regard to architecture.

Developers understanding costs

Dave Anderson

Back in the enterprise days, I used to see some of those things. The cost question was: ‘Is it five figures, six figures, or seven figures?’. You sometimes saw many hundreds of 1000s? Or millions? It’s a great question because as Mark says, you can assess if a developer knows what they’re talking about. The first question you can ask is: ‘How much did that cost?’. And if they turn around and respond with ‘$16’. You know that’s a good sign.

Mark McCann

In the serverless and microservice world, your costs are can fluctuate rapidly up and down, if you’re not aware of it. In the past, that would have been pre-bought five years ago, using tax-efficient methods, written off, and paid down over multiple years. What you designed and implemented would not have had a big impact. Now, the success or failure of your organization (depending on the scaling) could come down to how well you manage your cloud costs.

Dave Anderson

Here’s a good tip. If you are interviewing a developer, and they tell you about their fantastic system, just ask: ‘How much does that cost per day?’. That’ll unpack a lot of stuff. Sorry, if that’s unpopular advice. Sorry to the developers out there.

Mark McCann

Even though it’s one question there’s a huge amount behind it. You can go really deep into savings plans, tagging and being savvy and skilled with your cloud financial management. There’s an emerging cloud economics role.

The partnership between CFO and CTO

Dave Anderson

What’s really interesting is that cloud providers are cleverly targeting CFOs. So a partnership forms between the CFO and the CTO. The CFO team has fin ops people. This is a great excuse for a savvy architect to talk to the Finance department to figure out how billing, costs, and budgets link with your architecture. That’s a great way to drive improvement instead of just wanting to refactor because it’s cool. Instead, you can refactor to save half a million dollars because Finance has told you this.

Mike O’Reilly

Looking at expenditure awareness for serverless teams there are two types of financial plans: OpEx v’s CapEx with AWS. CapEx, capital expenditure is when you plan upfront, and OpEx, operational expenditure is not planned for ie. it’s pay-as-you-go. Your dynamic workloads typically fall into OpEx and a lot of organizations struggle with the transition from one to the other.

Dave Anderson

And that’s not just serverless, OpEx v’s CapEx in AWS applies to the cloud in general. The fact is that you don’t know what your bill is going to be for that month. With data centers you pay three years in advance, and you can offset tax.

CapEx and OpEx expectations

Mark McCann

Setting expectations around OpEx v’s CapEx with the AWS Cost Optimization pillar is critically important, especially with business partners, who maybe aren’t aware of this and will wonder why my bill went from £50 to £3,000 this week. And the explanation might be running a load test for a new feature. So you need to be very upfront and very good about setting expectations OpEx v’s CapEx AWS costs will fluctuate up and down give reasons why. It relates back to ‘clarity of purpose’, understanding what you’re doing, and being able to articulate that in a business way that links up business and IT together.

Dave Anderson

Or an even worse example: ‘Wee Jimmy ran a load test and then went off on holidays and forgot to turn it off’.

Mike O’Reilly

We’ve definitely seen a few of those incidents happen in the past!

Dave Anderson

And just to let you know that ‘Wee Jimmy’ is made up.

Mike O’Reilly

In relation to Wee Jimmy and what Wee Jimmy would have learned about cost. I’ve seen a few teams do this quite well. A lot of cloud providers show how your cost is calculated. You can replicate those algorithms in your dashboards. Through your throughput, you can try to predict costs in your own dashboards.

Dave Anderson

How many times has a developer come to your desk in the morning with the blood drained from their face saying ‘I think I have just spent $20,000!’? And you think okay, this is a good way to get some focus on well-architected!

Photo by Sharon McCutcheon on Unsplash.com

Expenditure Awareness

Mark McCann

That brings us to the expenditure awareness section of the question set. To grow that awareness, education is critical. You need to make teams aware that these things are available to you. You can go and look at these. The revamp of the console and having cost on the first screen means that cost awareness is growing more and more, especially with the stuff we talked about. Your cost is an operational expenditure critical to the profitability of your business. It’s not going to be a written-off item from 10 years ago.

Dave Anderson

Expenditure awareness is simple stuff, but for some developers, it is very new. So how do you govern usage? How do you monitor usage and costs? And how do you decommission/how do you switch things off? That’s not what developers of yesteryear, had to worry about. Back then it was a ‘sysadmin’ thing. The fact that people can potentially get alerts or emails if they leave things running over the weekend will drive the right behavior. Because there is real money being spent.

Mike O’Reilly

Tagging and tagging resources are levels of discipline that you need to get into.

Dave Anderson

That’s monitoring. Because if something’s not tagged properly, then it’s not monitored, but you still have to pay for it.

Mike O’Reilly

It’s definitely worthwhile to think about your tagging.

Cost breakdown

Dave Anderson

If you’re in a leadership position, you should be able to see a breakdown. If you have five applications in your portfolio you should be able to know the cost breakdown from those five, at the very least. That’s not that hard to do.

Mark McCann

The things to consider around governing usage, are guardrails, how you set up your organizations, and how you set up your service control policies. If you’re going to be a serverless first shop, you can turn off the non-serverless capabilities that are very expensive if they’re left running. There are ways to establish good guardrails that give you the best cost optimization.

Dave Anderson

The popular allow list? Or the allow lists that only allow serverless services to be popular Mark?

Mark McCann

It’s serverless first, not serverless only but if you come up with a well-articulated excuse or reason why the serverless capability doesn’t work then we will alter the policy!

Cost Effective Resources

Dave Anderson

An exception for EC2! The next one is Cost-Effective Resources. And that’s done quite nicely. There are lots of ways to skin a cat when you’re building something. Developers, always want to pick the fastest and wildest thing. But is it more cost-effective? Sometimes you don’t need the fastest thing and a moderate speed will do the job. This point to sustainability as well. It’s not how fast can you get it. It’s how fast do you need to provide adequate service?

Mark McCann

The total cost of ownership comes to the fore here. It’s not what is for right now. It’s the long-term operational burden and cost. You can choose a technology that’s super low cost, but the cognitive burden is massive because it’s a new technology that’s outside your team right now. Then, what’s the learning cost for that team to learn the tech stack or language that you chose for cost-efficiency reasons? You have got to take a bigger view. It’s not just for what you’re doing right now.

Mike O’Reilly

I know there’s a tonne of new stuff out there at the minute. I’ve never really gotten into it in a lot of sort of depth. But how do you plan for data transfer charges? That’s definitely one to look at if you have a large data footprint.

Dave Anderson

When you look at the operational business processes, it can have backups, DRs, or whatever. You need to be careful that you don’t get charged for those.

Mark McCann

Ingress and egress, especially if you’re going multi-region, can be a massive cost. You need to be aware that there are costs for data moving around regions.

Matching Supply and Demand and Optimising Over Time

Dave Anderson

The last two are Matching Supply and Demand and Optimising Over Time. I’ve lumped these together. There’s a piece around keeping up with the latest and greatest in AWS and tweaking your design so that you’re continuing efficiently. There’s also a bit about selecting new services as you build new stuff and selecting wisely for a decent cost impact.

Mark McCann

This is where we see the serverless advantage kicking in. Matching Supply and Demand is taken care of for you as it scales with the load. If you’re on traditional architectures or EC2, you might need to pre-provision some other stuff and have it at hand and ready to go. That’s a hard calculation to get right. You’re going to have a lot of wastage with an excess capacity just waiting to go whenever the demand comes in. So it’s a lot easier when you’re serverless.

Mike O’Reilly

Being able to extrapolate your costs based on various dimensions is important.

Dave Anderson

So that’s the craic. That’s the AWS cost optimization pillar and OpEx v CapEx in AWS. We’ll hit the Sustainability Pillar next. So please give us a like or a follow on YouTube or the Podcast. Our blog is TheServerlessEdge.com. And follow us on @ServerlessEdge on Twitter. Thank you very much.

Transcribed by https://otter.ai

How to write sustainable technology with SCORP

The Serverless Edge — Mon, 20 Mar 2023 13:37:55 +0000

Sustainable technology is fundamental

As humanity gets to grips with global warming, we are seeing a positive and welcome move from cloud providers. They are making sustainable technology and sustainability central to their operations. And in their guidance for customers.

In recent years, each of the big three cloud providers has developed its own sustainability strategies. These strategies have varied from investing in and constructing renewable energy sources to carbon offsetting and the purchasing of Renewable Energy Certificates (RECs). You can read a good overview from Wired: Amazon, Google, and Microsoft: Here’s Who Has the Greenest Cloud.

Will the environment affect how we build software? What is sustainable software development?

As active engineers working with deadlines and pressures around delivery, you can be forgiven for asking these questions.

Sustainable technology is a climatic pattern

In Wardley Strategy Cycle terms, we might describe sustainability as a significant Climatic Pattern (no pun intended). Climatic Patterns / Patterns are external forces influencing what you and your organisation do. These are the broader rules of the game, the patterns of the seasons, and competitor actions. Climatic patterns will affect you.

Google and Microsoft have been leading the sustainable technology charge in recent years by helping organisations to achieve net-0 carbon emissions. They do this by introducing the ability for enterprises to measure their carbon footprint in the cloud. Sustainability as a Climatic Pattern influencing digital organisations is now becoming a factor that cannot be ignored by leadership in these organisations. Cloud providers are doing ever more to empower organisations in measuring their carbon emissions.

We predict more ‘digital’ organisations will enact green/sustainable technical and architectural strategies. They will do this to drive down their carbon footprint towards net zero carbon emissions. These strategies will involve movement and evolution across value/supply chains that will lead to positive outcomes and sustainable operations.

Extending SCORP with Sustainability – SCORPS

In terms of sustainable software and software architectures, we can build on the advances of cloud providers. In previous posts, we talked about our SCORP continuous improvement processes for development teams. There is potential to extend the SCORP continuous improvement process to factor sustainability into decisions and goals. SCORPS 🙂

We acknowledge that sustainable change is slow and deliberate. The SCORPS process takes teams on a continuous improvement journey with the Well-Architected Framework at the heart of its doctrine. At re:Invent 2021 AWS included the addition of a sixth pillar to Well-Architected: Sustainability.

We see this as an awesome opportunity for development organisations to bring environmental sustainability into their workload and architecture designs.

Shared Responsibility Model

The AWS Well-Architected Sustainability pillar is an asset aimed at supporting development teams and organisation making environmentally sustainable decisions for their software architecture. It articulates a Shared Responsibility Model. This is intended as a meet-in-the-middle type compromise. AWS takes care of sustainability at the core infrastructure. We optimise application and enterprise design.

The AWS Sustainability pillar includes Best Practices for Sustainability in the Cloud. These practices are grouped into five categories:

Region Selection

User Behaviour Patterns

Software and Architecture Patterns

Data Patterns

Hardware Patterns

Development and Deployment Process

We would anticipate teams being able to use the pillar to assess their current state/workloads and make recommendations and decisions to improve their sustainability trends. Just as important is the need to make good decisions around new workloads and setting them on a sustainable path.

Our initial impression is that the sustainability guidance offered by AWS will be very positive for teams leveraging serverless architecture strategies. We are on the right course with our serverless-first development approach.

It’s an exciting and empowering time for teams and organisations wanting to do their bit by making environmentally friendly decisions for their software architecture. Over time I personally hope to begin to introduce the sustainability pillar into our Well-Architected Reviews and into our continuous improvement initiative SCORPS. Just doing our bit.

Our guide to the AWS Well Architected Tool – Performance Pillar

The Serverless Edge — Fri, 03 Mar 2023 13:58:17 +0000

We talk through the ins and outs of the AWS Performance Pillar that forms part of the AWS Well-Architected Tool Set. This is the fourth part of a series of talks. Performance efficiency is a work-based development conversation. If your business isn’t bringing in loads of money, you don’t need all this horsepower under the hood. It doesn’t need to be that efficient or effective from a performance point of view. The team starts with the kicker question ‘how do you select the best-performing architecture?’.

AWS Performance Pillar - the fourth in our series of talks on the Well Architected Framework

Dave Anderson

So we’re continuing our series talking about our favourite well-architected pillar! Which will be our favourite? Who knows? How exciting!

Today, we’re going to talk about the Performance Pillar, which I think is strangely interesting. It’s called performance efficiency. This one’s got a couple of different bits. Each of the pillars of well-architected usually has around 10 questions. This one has eight. And it’s got four sections: Selection, Review, Monitoring, and Trade-Offs.

It is really about the performance efficiency of your whole system. But the meaty part here is selection. There are five questions about the selection. The kicker question is the first one: ‘how do you select the best-performing architecture?’.

AWS Performance Pillar: Selection

Mark McCann

That is a good one. Because you don’t throw loads of technology at solving a problem if you don’t actually understand who your users are, and their needs. You should go really hard and deep to make sure you understand the problem you’re trying to solve for the users that are going to use a system. What are their needs? Once you have that to hand, do something like domain-driven design to break it up a little bit and make sure you have good boundaries and domains established. When you have all that you’re well informed. And now you can think about what’s the best architecture that can actually meet the needs of users.

Dave Anderson

I have been in this position three times in my career. It’s when your job is to pick an architecture for a big problem. And it’s a moment of responsibility because that architecture might need to last for 10, 15 or 20 years. And you have to be really careful about what it’s for, what it’s going to do and will do in the future. I think the few times I have done this, it has worked okay! At the start of a project, there’s always pressure to get something working. But you need to pause at the start and figure that out.

Mental model

The idea of the mental model of the system is really important. Can you explain to everyone in your company what it is? Is it X, Y, or Z? It’s like the mental model of a car. When you draw a car there’s an engine, wheels, steering wheel, brakes, and a cabin. People get the mental model. With architecture, your system needs to be that simple. This is what it is. There are lots of different ways to structure it. But you need to decide on a mental model that will work and that people will get. And that is going to evolve over time.

Future needs

Mark McCann

Evolution is critical. It might be the best architecture to meet the needs right now, but is there scope, capacity or room for it to evolve to meet unexpected future needs as well? Or have you painted yourself into a corner?

Mike O’Reilly

My experience over the last number of years of adopting the serverless first mentality is that AWS, GCP, and Azure have opinionated managed services that you can integrate and assemble. Dave, you touched on evolutionary architecture and the responsibility of building it. When you want to build fast, but also focus on the domain being correct with logic in the right place and thinking in terms of a socio-technical view of the organisation. I also don’t want to overthink or overdesign something. I want to move fast. But I reserve the right, at some point, as we scale up or the system evolves to pivot and change reasonably quickly. This is another factor with serverless. Because it’s event-driven, you’re forced to use event-driven style architectures so it lends itself to that sort of evolution. You can swap things out later on. If you need a container, a SAS, or an external vendor, it’s pluggable.

Performance efficiency

Dave Anderson

There’s something important about Performance efficiency and when you break your system down into domains and components. I would say to an engineer: ‘do you see that component? It’s got to do X, Y, Z and it’s got to work and be well architected. So figure out how to make that happen.’ And if that’s calling a managed service from AWS, then that is fine. That’s building something. But there are a bunch of non-functional requirements about that box that needs to be right. This is where you get into the idea of whether this is a commodity component. Or is it something that’s mission-critical to your business or a piece of IP? Do you need to build it? Or can you just rent it? Wardley mapping helps you to think whether or not to build. For example, we need global storage so let’s try and build that. The answer is no! Just use S3.

Mark McCann

Having a serverless first mindset and approach can help you with performance. Is there a managed service you can leverage? Does it have a serverless capability? Is it on the serverless spectrum? If it doesn’t, can you fall back to something that has serverless characteristics? So an example would be: does DynamoDB fit your needs for your data? If it doesn’t, can you fall back to something that’s still on the serverless spectrum, like Aurora serverless, if it’s a relational database? In summary, what’s the managed service I can leverage? What’s the serverless capability I can leverage? If it doesn’t meet the needs of your use case, you can fall back to something that’s further back on the serverless spectrum. That applies to compute storage, databases, and networks.

Facilitating conversations

Mike O’Reilly

Serverless is not standing still, it is improving over the years. We’ve seen cold starts reduce and we are seeing more conductivity across managed services, as opposed to directly through lambdas. You get those benefits without having to do anything. That’s another benefit to consider when deciding to take a serverless approach with your architecture. It allows you to focus on sensitive requirements like performance or the need to get it working. You can design those requirements into the workload: do we need the cash? Or are there things we optimise or streamline? You can facilitate those conversations as part of this review.

Mark McCann

I think one of the best things about a serverless approach to performance is that the cloud provider is constantly working at improving performance efficiency, reducing costs, speeding up, and adding more horsepower to your compute. By choosing smartly, with your architecture, you get a free underlying platform team that is constantly working on improving your performance. And you can just take advantage of it without having to worry. You can leverage that performance improvement.

Photo by Nicolas Hoizey on Unsplash.com

AWS Performance Pillar: Review

Dave Anderson

Moving onto the next section and relating to what you said how do you constantly review your architecture to take advantage of new releases? Cloud providers are constantly innovating and releasing stuff every week, so you want to be in a position where you can add new stuff quickly without breaking the whole architecture. You need to operate a ‘two-way door’ as Amazon calls it where you go in, do something and then get back out again. You don’t want a one-way door where you get trapped.

Mark McCann

This is where mapping can be really advantageous to your teams. If you’ve mapped out your tech stack, you understand the components and you can see where they are on the evolutionary axis. When a new capability or service comes out, you can immediately start to assess that against your current components. If you’re custom building a database you will spot the new managed service that meets your needs and evolve to use it.

Consider new managed services

Dave Anderson

We’ve done this in the past! We’ve been building something, but then you think that something’s going to come out that will do that job for me. So I build it in a way that I can replace it easily when something comes out.

Mike O’Reilly

Event Bridge is a good example. For a long time, we’ve been using an SNS SQS finite-type approach to the event. And the Event Bridge was released. The team was trying to get latency reduced and constantly looking at that. And then realise that when you get to a certain level, we’ll make that cutover. But it’s a good example of how to evolve and plan for that.

Mark McCann

We need another Serverless Craic episode on how to keep up with the pace of change and the firehose of informational updates. I think we need to explore it. There is a good return on investment on the use of time by having your radar up, being aware of how the environment around you is changing, and being open to adopting new capabilities that can save money and effort.

Monitoring and Trade-Offs

Dave Anderson

The next section is Monitoring and how to monitor your resources for performance, which is fairly straightforward. And the last one is Trade-Offs and how to use trade-offs to improve performance. A great example is Lambda Power Tuner, where you can tune your function based on memory or CPU to get that nice balance between cost and performance.

Mark McCann

That’s a great one. What are you willing to pay for? Is it worth it? Performance efficiency quickly becomes a work-based development conversation. If the business isn’t bringing in loads of money, you don’t need all this horsepower under the hood. It doesn’t need to be that efficient or effective from a performance point of view.

Dave Anderson

And there’s a sustainability thing there as well. Do you need a sub-second response time for something? Maybe a one-second response time will be okay. Don’t burn through everything, just for the sake of it.

Don’t over optimise

Mike O’Reilly

This is a good habit to get into. Is our lambda too big? What can we do to thin it down and shorten it? Anytime I run this, I normally see quite a lift. I’ve seen teams go from three-second response times to half a second response times because they’ve trimmed something down.

Mark McCann

There is a fear, when you get all this in place, that teams over-optimize. The engineering time isn’t worth the performance improvement. So you need to be mindful of that. But that’s for when you’re pretty far down the maturity curve.

Dave Anderson

Not a bad problem to have. Alright, so that’s the craic. That’s, that’s the performance efficiency pillar of well architected. Thanks for listening. There are more thoughts on the blog at TheServerlessEdge.com and on Twitter @ServerlessEdge. We are also on Medium, Dev.To and LinkedIn. Thanks very much!

Our guide to the AWS Reliability Pillar

The Serverless Edge — Wed, 15 Feb 2023 12:40:53 +0000

Mark, Mike and Dave share their thoughts on the AWS Reliability Pillar that forms part of the Well Architected Framework. This is the third part of a series of talks. All engineers need to design their systems for reliability but the team show how Serverless can free up thinking time for system design rather than trying to master non functional components.

AWS Reliability Pillar which is next in the series of talks on the Well Architected Framework

Dave Anderson

We’re continuing our conversation about the well architected framework. I think at the end, we should announce what our favourite pillar is! We’re going to talk about the AWS Reliability Pillar today. We have a couple of previous episodes on other pillars like operational excellence and security. So Reliability is a funny/peculiar pillar. It has 4 sections:

foundations,
workload architecture,
change management, and
failure management.

If you’re building in a traditional way, this is a huge amount of work. You could spend a long time getting this right. DR/disaster recovery is very complicated traditionally. But we’re serverless heads. So a lot of these things are, I wouldn’t say they’re completely taken care of by AWS, but AWS makes it a lot easier to do some of these things. A lot of service quotas and constraints are baked into the foundations. From a change management perspective, you want to get into the continuous delivery kind of mindset, so there’s a lot of monitoring if you use the modern tools. From a failure management perspective, serverless is ephemeral, so it’s built for retries. You can design so that those areas are slightly easier to work with. What do you guys think?

Foundation section

Mike O’Reilly

I agree with that. When you look at the foundation section of the AWS Reliability pillar, you’re probably looking at how to plan, not over provision or overspend but also scale up effectively. You put a lot of time into the foundation section, whereas if you are in Serverless you still need to look at foundations, but I think it’s less intensive. So you’re looking at things like DNS, or how you write effectively, and things like that.

Workload Architecture

Mark McCann

You still need to worry about quotas and some of the constraints and resource constraints of your account. If you follow the operational excellence and security pillar and you have granular accounts, you’re hopefully not stepping on too many toes in the same account. So that’s less of an issue. It’s more about being aware of your quotas and the size of your workload and making sure those higher level quotas are big enough for the demand that you’re going to have. It’s more about putting in the request for a bigger quota, which is a lot easier than ordering up another five racks or a couple of IFL’s for your mainframe.

Dave Anderson

With a lot of serverless services, there are fairly tight quotas. But they’re not there because there’s no capacity. They are there to stop you being crazy and setting off like a million different lambdas or something. It’s no problem to get them extended. They protect you rather than being a lack of capacity.

Change Management

Mark McCann

You’re starting from a more mature reliability standpoint, when you adopt the serverless and a serviceful approach. So from a change management point of view, adapting to change is built into serverless capabilities and how managed services operate. So you’re not worrying so much about it.

Failure Management

From a failure management point of view, a lot of that is baked in especially if you’ve built an event driven asynchronous workload, using SNS, SQS or Eventbridge. A lot of circuit breaker type mentality, retry and dead letter queues are coming out of the box now. Increasingly they are maturing those capabilities to make it easier for teams to have a default, resilient driver and reliable capability.

Photo by Mario Heller on unsplash.com

Influence of Serverless on Reliability

Mike O’Reilly

We’ve done talks on how Serverless influences load architecture. And here, serverless influences how we would architect workloads. For example, with serverless architecture we tend to take a micro path: micro service or micro front end. It’s opinionated so there’s only so many ways to connect these things. It’s aimed at speed, cost effectiveness and reliability. If you are using lambda, it’s 6 AZs wide, in terms of the HA side of things. It’s the same with DynamoDB or Aurora. There’s a lot of stuff that AWS has in the AWS Reliability Pillar thats thought about for you and you can benefit from that. And that influences how you actually assemble your workload in terms of the workload architecture as you’ve got to work within those constraints.

Dave Anderson

What’s interesting about the reliability pillar and well architected is that they have been there for eight years, but they’ve just recently added this new section, which is workload architecture. And one of the questions is how do you design interactions in a distributed system to prevent failures? So there’s a specific section on how to design distributed workloads. That’s more than a nod. It’s proof that a lot of customers are moving towards distributed micro service and modern application stacks. There’s a lot of depth in that. To do that well, you need an upfront design. You need to think about your system before you design it. You can’t code your way out of it.

Domain driven design

Mark McCann

I love the reference to domain driven design. We’re big fans of applying a domain driven approach and using techniques like event storming, to really break down those boundaries of domains and understand the flow of events through your system. It lends itself to breaking it into more manageable domains and chunks that you can test in isolation. And you can have different characteristics for each of those domains.

Dave Anderson

Like we said, at the top of the session, serverless makes some of these things easier, but the time that you don’t spend on retries is put into domain design. It’s an equal amount of effort and it’s still challenging but you’re putting precious time into system design, as opposed to tuning a non functional thing. It’s still hard to build the systems, but I firmly believe you get a better system at the end of the day.

Think about components and the effect of auto scale

Mike O’Reilly

Using a serverless lense with the questions on the reliability pillar is important because serverless auto scales. Some of the questions look at: if we auto scale this serverless component, what sort of load or pressures are put on something that doesn’t auto scale? It forces you to think about protection and where are the choke points? Should you be throttling your workload? Should you be setting constraints on the scalability of your serverless workload?

Mark McCann

I’ve seen the denial of wallet type questions. Do you really want to scale infinitely as it could cost you a fortune. Those types of questions get to something that we’re very passionate about, which is testing for resilience and continuous resiliency, and having test days or game days that tease out where the choke points are. Where are your failure cases? Where are the downstream systems that can’t respond or can’t take the load as you pass to it?

All of us agree that it is easier to do it serverless and it’s important that the setup is designed properly. But you can get good feedback by testing for this stuff. And you’ve seen the maturity of the fault injection service that has come out. It’s easy to use and I’m hoping to see it evolve and mature to be much more serverless focused as well. But it’s a lot easier to test for resiliency. So you’re not guessing anymore. You have real automation and you’ve baked that into your CI CD pipeline as well.

Dave Anderson

I remember building distributed system 20 years ago and you had to put a lot of time and effort to do some of the things you can do now by checking the box eg. the advanced testing and resilience practices you can put in.

So that’s the craic. And that’s the reliability pillar.

Thanks for listening. Our blog is on TheServerlessEdge.com. And we’ll be tweeting on @ServerlessEdge and posting on LinkedIn, Dev.To and Medium. Thank you very much.

Transcribed by https://otter.ai

Is it time to combine Serverless and SaaS?

The Serverless Edge — Wed, 08 Feb 2023 15:05:41 +0000

Combining Serverless and SaaS can really give your business its Serverless Edge.

Photo by Belinda Fewings on Unsplash.com

What is SaaS?

SaaS or Software-as-a-service delivers applications over the internet rapidly and in a self-service. You don’t need to install and maintain software, you simply access it via the Internet. This remove the undifferentiated burden of complex software and hardware management. SaaS products are typically sold, run, and maintained by Independent software vendors (ISVs). They usually host them on a cloud provider like AWS, GCP, Azure, etc.

SaaS Products typically have a subscription (pay-as-you-go) or consumption (pay-for-what-you-use) based pricing model. And they can scale easily to meet your needs.

Salesforce, Slack, Google G-Suite, Shopify, Zoom are all examples of SaaS products.

Meeting new org needs

Organisations, large and small have to rapidly meet the needs of their users. They must find product market fit and reduce their time to value. They need to be efficient with capital. And make sure their business model scales profitably as usage grows.

This is where SaaS comes in!

SaaS helps reduce time to value by enabling a faster feedback loop from real users. And it scales easily as your business grows.
Startup businesses are increasingly SaaS-only. They build their businesses on the cloud and leverage software as a service building blocks. This allows them to rapidly compile an offering to meet their customers needs.
Enterprises look for SaaS options first when purchasing commercial software. So that they can focus on their core business.
1 or 2 person Micro-SaaS businesses now have the same access to SaaS building blocks as established enterprises. They can rapidly meet the needs of a niche set of users.

Ask these Questions

When creating a SaaS product you need to answer a set of core questions. This focuses everyone on business goals and meeting the needs of users. Tod Golding covers this and more in his amazing SaaS architecture patterns: From concept to implementation talk. We have the important points here:

Management

How do you manage your SaaS product? Do you have a observability and analytics in place so you can analyse trends and see how your business in performing?
Do you have a good handle on billing? Do you have the ability to have different subscription and pricing models?
How do you provision and configure tenant environments on-demand and in a self service way?

Application

How do you design your application to handle multiple tenants?
How do you implement isolation so one tenant doesn’t interfere or have access to any other tenants?
How do you partition data appropriately for each tenant?
How do you deploy infrastructure and applications? Do you share common infrastructure, or do you have completely separate silos for each tenant, or a mixture?
How do you route data and load to each tenant?

Tenancy

How do you create users and associate users to a tenant identity? How does authentication and authorization work for each user in SaaS?
How do you create and onboard a new tenant into the system? How do you give them an identity, a plan and configure the appropriate policies for that tenant?
How do you offer different tiered experiences to different tenants? Basic, Premium, Enterprise, etc.

Make it real with the Serverless SaaS workshop

The AWS Serverless SaaS Workshop guides you through building a multi-tenant Software-as-a-Service (SaaS) solution. The work shop answers questions in a serverless way.

How do you implement tenant isolation in an AWS Lambda environment?
How do you support tiering and noisy-neighbor conditions?
How do you build multi-tenant-aware microservices in a serverless model?
How do you do establish Multi-tenant observability in a serverless ecosystem?
How do you isolate tenant data in a pooled model?
How do you apply tier based deployment strategies?
How do you enable tenant throttling and quotas?

AWS Serverless SaaS Workshop

At the end, you will be able to build a fully functional SaaS application, which aligns closely to the SaaS Reference Architecture solution.

Attending the workshop is a fantastic way to learn how to build a SaaS product from the ground up, and how to get it to market quickly.The workshop also is a great way to get hands on with a wide array of technologies : Cloud9, SAM, CDK, API Gateway, Lambda, Lambda Layers, DynamoDB, Cognito, STS, CodePipeline, CloudWatch, Python and the brilliant lambda power tools.

Serverless and SaaS – better together

Taking a serverless-first approach lets you focus on your SaaS business and your differentiating value, without worrying about scaling and managing servers. This approach enables you to get to market faster, reduce your operational cost, keep your initial costs low, and scale as you find product market fit.

Resources

Our guide to the AWS Security Pillar

The Serverless Edge — Wed, 01 Feb 2023 12:30:49 +0000

Mark, Mike and Dave do a walkthrough the AWS Security pillar that forms part of the Well Architected Framework. This is the second part of a series of talks. The team share their insights into how to manage this vital but often complicated aspect of modern architecture.

AWS Security Pillar which is next in the series of talks on the Well Architected Framework

Dave Anderson

We’re continuing our series on each of the pillars of the well architected framework. We talked about the operational excellence pillar last time. We’re going to talk about security this time, which is our favourite well architected pillar.

It goes without saying that a prerequisite is threat modelling. If you’re going to talk about security, threat modelling is your number one way to understand where you are. As a pillar it is quite interesting. There are 10 questions and a couple of different sections. We will fly through them.

AWS Security Pillar – how do you securely operate your workload?

Mike O’Reilly

The well architected security pillar is aimed at how secure your organisation is. It goes into things like, how you’re managing accounts, is your control tower hooked up and are you using guard duty? It promotes team’s awareness of security across the organisation and how it plays into things. The types of things I engage with when we’re 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 in on.

Mark McCann

How granular your account posture is, is a big one. In the past, you would have one big account that had everything and the blast radius was huge. 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.

Rule 1: Tightly Manage and Automate

Dave Anderson

One thing I like about well architected is the 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.

Mike O’Reilly

That, in particular, is quite important. It’s quite complex. Normally, it ties back into the enterprise or a broader policy and it gets teams asking what are the authorization controls for this component. Or, if this user was to leave the system, how do we do that in an effective, secure way. And if someone was leaving the organisation, how do we make sure their access is revoked. It forces you to have those conversations, which is positive.

Least privilege principle

Mark McCann

I think 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 an unmanageable burden and an ephemeral sort of workspace.

Photo by Yosh Ginsu on Unsplash.com

Detective Controls and Left of Attack

Dave Anderson

The next area in the AWS Security Pillar is one of my favourites: 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.

Mike O’Reilly

The tech uses machine learning to look for anomalies in your traffic or for things that look out of whack, and it raises events for you to take a look at. But in general, you’ll use everyday detection controls by making sure your observability is good, so when something happens, you are alerted or your attention will be drawn if someone’s trying something. It always ties back into good observability. I’m guilty of thinking from an AppSec perspective. If there are flows through your app and you wouldn’t expect to see traffic, someone gets notified and it’s traceable. There are a lot of cool things happening, as you describe it Dave: ‘left of attack’, where your security org is probably more active than your typical app developer.

Managing emerging threat

Mark McCann

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? Game days and security chaos engineering are ways of building good detective control capabilities and sharpening the software. ‘What happens if?’ scenarios really help. Is your observability where it should be? Do you have the right logging, monitoring, alerting and alarming for rapidly detecting and remediating these events?

Mike O’Reilly

The Log4j one is a cracker, because we use those events as they happen to find a better way to look through our Bill of Materials and assess whether we’re affected? Or how long did that actually take us to correct or detect? Are we vulnerable or not? We find things we could tighten up. That’s the type of conversation that you can have in that section.

Data Protection

Dave Anderson

I could tell many stories about ‘detective controls’! The next section in the AWS Security Pillar is ‘infrastructure protection’, but we’ll just skip over that because I mean it’s network and compute protection, which should be fairly well understood. The next one is data protection. There’s stuff here about both encryption etc, in rest and in transition. But the interesting one is how do you classify your data? Which is a tough question and does your organisation understand your data classification?

Mark McCann

We have mentioned that code as a liability. Your data can also be a liability that you need to manage appropriately. I am sure you’ve heard that ‘data is the new oil’. Well, oil if you don’t store it correctly, is toxic, damaging and flammable and has all sorts of impacts. If you don’t understand your data and haven’t classified it correctly, you won’t know what you have. One of the first things you can do is get a good handle on the data you have. Is it valuable? Is it needed? Are you getting business value and if you’re not, get rid of it. Make sure you have your retention, deletion and archiving set up properly.

Understanding data classification

Mike O’Reilly

Most 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. And typically we’ll put a link on the threat modeling template to the data classification standard, to force the facilitator to have a look at it. So then we can see if we’re dealing with sensitive information that we should be taking extra precautions with and designing controls in the workflow.

And if we’re dealing with restricted information so do we have proper encryption capabilities? Are we moving data in an encrypted fashion and we storing data in an encrypted fashion? Are we tagging it? Mark, you mentioned ‘Least Privilege’, so can we track who’s actually looked at that data? Can we track where that data was moved to? Have we got ‘Least Privilege’ access controls on that data. So that’s a very good one in terms of making sure that architecting for the data classification.

Mark McCann

From a well architected guardrails point of view, automate some of the guardrails in your provisioning infrastructure, so that encryption at rest, encryption in transit, tagging and other basic security capabilities are turned on so that no resource can be created that doesn’t adhere to these basic good practices.

Incident Response

Dave Anderson

The last section in the AWS Security Pillar 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.

Mike O’Reilly

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 exactly.

Mark McCann

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.

Dave Anderson

In the AWS 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.

So that’s the craic. Thanks very much for listening. Next time we’re going to do the ‘reliability pillar’. Look up the blog on TheServerlessEdge.com and @ServerlessEdge on Twitter.

Transcribed by https://otter.ai

Operational Excellence examples for Well Architected

The Serverless Edge — Thu, 26 Jan 2023 14:07:46 +0000

We talk through our Operational Excellence examples from our well architected experiences. Our post is the first in a series of conversations on the well architected architected framework and pillars.

Operational Excellence examples and Well Architected

Dave Anderson

We've written about well architected and the well architected pillars of SCORP or SCORPS, There are now six well architected pillars. Well architected is really interesting, because AWS, Google and Azure have their own versions of well architected. They're all quite similar. We have had great success from working through these pillars.

So we figured we'd hit each pillar and have a quick chat about them starting with operational excellence. Is there anything else you would like to say at a high level about well architected.

Mark McCann

It's something we have found to be incredibly useful. It gives a frame of reference and a structure for asking better questions of our teams, systems, structures, and our processes and practices. It has been hugely useful for trying to evolve engineering, practices and companies. It's hardened and approved, and it's been battle tested in 1000s of companies which gives it a lot of credibility. And it's not just Dave, Mark and Mike's opinions. It's good practice that has been proven to work.

Mike O'Reilly

That's a major strength, isn't it? I like the ubiquity. Whether you're an architect, an engineer or a manager in one organisation, when you go to another, it'll make sense.

Operational Excellence should be part of continuous architecture

Dave Anderson

It's not a yearly process to deliver compliance once a year with well architected. It should be part of continuous architecture. The reason why I always encourage people to get certification is not for a bit of paper or a free water bottle, it's because you have to learn well architected as part of certification. So starting with operational excellence, 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.

Photo by Ameya Sawant on Unsplash

Operational Excellence Pillar - prepare, operate and evolve

Dave Anderson

Operational excellence means a lot of things to a lot of people, but let's chat about prepare. What have your found to be in the prepare part of this?

Mark McCann

It's great to go in new areas and teams to asking these questions:

Do you know who your users are?
What is the purpose of your team ?
Do you know what your highest priority is?

Some are very simple, basic questions.

Are you set up to meet the challenges that you're faced with, the business requirements that you're going to pursue or the needs you're trying to meet?

Asking simple questions can be revealing

So simple questions like how do you determine what your priorities are can be very revealing. If you are in a safe space with the whole team involved you can get a really good conversation. We know our priorities for this week and for next week, but we're not quite sure what we're doing for the month after. It's a good conversation 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'?

Mike O'Reilly

This pillar needs the whole team involved in the conversation. Some questions require management to be involved, some require the tech lead or the engineer to understand the big picture and operations. We talk about consistency. In this section there are recommendations for playbooks/runbooks and standards for making preparations for your operation: prepare for failure or everything fails all the time.

Operational Excellence: Prepare

You have got to prepare to move onto post implementation and hand off to different team or 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. So there's a lot of good, solid foundational guidance. From an architecture perspective (we're all architects), it's table stakes for consistency across teams.

Dave Anderson

'Prepare' looks at tribal knowledge like when you ask a question and the response is 'Fred says'. In other words: 'I don't know why we do that, but Fred says, we do that'. Or the response is: 'ask my manager'. But what happens when your manager isn't there? We need leadership and empowerment within the team and written down for everyone. So 'Prepare' checks team culture.

Mark McCann

It also 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.

Operational Excellence: Operate

Dave Anderson

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.

Mike O'Reilly

It's about getting the team ready for production. A particular bugbear of mine is when teams aren't thinking about how to validate in production and how to spot regression. What are the key performance indicators of the workload? When things go wrong, are they able to spot it and have they thought about how to remediate or correct those sorts of things.

Things do go wrong

You go back to prepare again. 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.

Mark McCann

It's critical to have those information radiators and dashboards available and not just for the team. If you have proper observability you can show the C suite the 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.

Operational Excellence: Evolve

Dave Anderson

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!

Mark McCann

It's what Mike said earlier. It's about having a continuous improvement mindset with feedback loops in place. 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.

Mike O'Reilly

That's the key point. We've written about the SCORPS process, and driver of continuous improvement. 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.

There is always room for operational excellence improvement

Dave Anderson

The operational excellence pillar sets us up nicely because once you think through evolve and operations, you're evolving the other pillars of cost, security, reliability, performance, and sustainability. You can always save more money, make the thing faster, more reliable, make it cheaper, make it more secure. People think operations are done because it's rolling and it's fine. But there's always things you can improve.

Mark McCann

You set up for success and you put the foundational building blocks in place to increase your chances of a successful development cycle.

Dave Anderson

So that's the operational excellence pillar from well architected. That's the craic. We'll be talking some more about the pillars. There are posts on this on TheServerlessEdge.com, on Twitter @ServerlessEdge, LinkedIn and Medium. So thanks very much.

Transcribed by https://otter.ai

Stride Threat Model and security threat modeling tools

The Serverless Edge — Wed, 18 Jan 2023 11:05:06 +0000

Stride Threat Model and other security threat modelling tools and techniques have fired the discussion this week: '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'.

Security

Dave Anderson

When I first came across Security and Risk Management, several decades ago, I remember thinking this is so complicated. I made an effort to learn about it as much as I could. And as someone who’s spoken at security conferences, I still am a complete amateur at Security. It’s so complicated. I think you need to sit down with security people and talk to them to understand what they’re trying to do. I find 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. And they understand what the control is.

So that’s the goal. Security people will tell you that the reason why this process exists is for this control eg. application security. And you ask what it means? Security doesn’t want the source code tampered with. Then you can partner with them to find the best way of doing that. But if you fight the process, it’s not going to work.

Mark McCann

Having a shared vocabulary and a common language is critical. We have had great success with stride security and threat modelling to help bridge that common language/vocabulary. Threat modelling/stride model, 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.

And as you mentioned, there are these controls we want to meet in an automated fashion. We want to bake it into our CI/CD pipelines and our building block constructs that we used to deliver the services. Ideally, we then get these reviewed/approved by the security team upstream. So that whenever a developer comes along and composes the next application, they’re building it from security approved building blocks that allow them to go fast, but go fast securely.

Threat Modelling

Dave Anderson

Threat models are brilliant and it’s worth talking about techniques that make Security easier. Mike, do you remember the first project you and I brought into threat modelling? We spoke to a Security guy called Bill Pellet who is a good friend of mine. And his reaction was: ‘No, you’re not doing this!’. So we went off, discovered threat modelling and worked out how to do it, and then come back to him with threat modelling. And I was expecting another tough time, but his response was: ‘This is amazing. I love what you’ve done but you’ve missed something’. We felt brilliant. I couldn’t believe how warm his reception was. And I’ve experienced that ever since. 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.

Microsoft Stride Security Threat Model

Mike O’Reilly

I remember that. It was a long time ago, maybe 15 years? It’s the Microsoft threat model using STRIDE model so it’s very application centric. A manager, engineer and product owner can be in one room together working through that process and following that STRIDE exercise. It’s actually quite a fun activity as well. But it’s a really good way of designing security into your workload. At the end you can validate with a walkthrough with a cybersecurity architect or somebody who knows security and the process is actually really good. We’re taking responsibility for design and security into our system. And there’s never been a threat modelling exercise where we haven’t surfaced value or requirements that we’ve just got to address.

It’s a phenomenal approach to be proactive about security. Mark, you’ve mentioned other support like the OWASP Top 10 for Serverless. From a reactive side there’s tons of tools that we can look at.

Photo by Yiran Ding on Unsplash.com

Dave Anderson

I’ve a funny story about threat modelling. I was trying to convince a team to do threat modelling. I was talking to the security lead and he wasn’t sure if it worked or not. And it was quite a high profile project. I said ‘let’s just try it and see what happens.’. I knew the engineering team because they sat beside where I was sitting. So I said, ‘well, let’s run a quick pilot’. The Security lead said: ‘we’ve been all over this, we spent months on this and this thing is bulletproof!’. I said ‘let’s threat model and see what happens’.

And I walked over to the engineers, and I asked if there were any security problems? And they said, there’s a loophole where you can log into the application, but it’s going to be fixed later. It was something to do with a token that had been implemented incorrectly. But the team thought it was going to be fixed later! So we threat modelled, and highlighted two or three issues. I realised there was a break in communication between the security requirement and implementation.

It was an easy fix. But the engineers had thought that someone else will fix it. And security guys thought this has all been implemented. There was a very minor misunderstanding, which was caught before anything went live.

The importance of a Security Stride Team Focus

Mark McCann

That is a key point. These collaborative, facilitated team based activities, surface so much value. You get a diverse group of people in a room/zoom call and there’s a great discovery of ideas and things that you haven’t thought about, like threat modelling or the way we do well architected reviews. It’s always team focused, it’s always collaborative and facilitated. And CSPs are able to surface: ‘Oh, you haven’t thought about this? Let’s think about that.’.

Dave Anderson

You always have a good tool set and good design, but the thing that will catch you out is probably a break in communication somewhere. And the best way to catch that is through a team event.

Mike O’Reilly

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 is talking to here, what are we doing, what are we passing across? You can use it to weave in the organization’s information eg. data privacy policies and what type of data you are moving, which is a big aspect of what application developers are doing – the movement of information and how we are protecting it.

Even looking at post production, people say they have static analysis in place. But you can still design insecure systems that static code analysis will pick up on. You’ve got to take that stuff quite seriously.

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. Mark, you love talking about chaos engineering.

Mark McCann

How do you then meet those controls in an automated fashion? Here’s our test. Can we bake it into the pipeline? Can we run it every single time we make a change? It’s constant evolution and the constant security improvements that we can go to. The other technique that we love is the well architected review process. I’ve written about this and SCORP processes. We have found it valuable to ask teams to do a threat model before they go into their well architected review.

By spending 5 to 10 minutes going over your threat model before the well architected review session gives context and value to the team. You find that the well architected review becomes very slick and fast, because they’ve thought about the boundary conditions and what way the data flows. And they can visualise it very clearly. That’s a tip/technique to do a threat model first so when you do a well architected review, it adds so much value.

Security Champion

Dave Anderson

Another great piece is identifying a developer to be a security champion. And it isn’t about always identifying the most senior developer. It’s just about identifying a developer who’s interested in security, stride security and expending extra effort to inform this person, so they learn all the controls and process etc., so they can then help out the team. So it’s a win win for everyone.

Mark McCann

One big enabler is baking in security guardrails into your environment as much as possible. There’s a fine balancing act of not stopping things going ahead. In every ecosystem we’ve worked in, we’ve had guardrails in place that give you baseline security: encryption, address encryption of transit and everything was tagged. There’s a whole foundational layer. Now you can use things like AWS config, or SCP to put that in place. But having those enabling constraints in place, allows you to have a higher order conversation about application security.

Mike O’Reilly

That’s a really good point. I think it complements security design. We were introducing a team to serverless and one of the things we did was to introduce cfn-lint and cfn-nag. CFN is a very opinionated validator that will go through your CloudFormation and highlight things that could be tightened up, which is a really good way of being proactive by asking are we going out with the most secure settings or should we be looking at defaults or encryption? Is our resource policy a wild card? That can really help find things that may be slipping through the cracks in relation to the implementation. So there’s tonnes of good tools out there.

Mark McCann

In summary, Serverless is more secure. Do threat modelling, do well architected reviews, identify security champions, establish good guardrails and automate the hell out of everything!

Dave Anderson

And talk to your security department. They are not evil, they don’t have horns!

Mark McCann

Absolutely.

Dave Anderson

Alright folks. That’s the craic. There’s more on TheServerlessEdge.com). On Twitter, we’re @ServerlessEdge. So thanks very much!!

Transcribed by https://otter.ai

Secure cloud architecture - is serverless the answer?

The Serverless Edge — Thu, 12 Jan 2023 14:42:46 +0000

We talk about secure cloud architecture and how serverless and cloud providers can provide a secure solution and more time for developers to think about and design secure solutions.

Security and Serverless Episode from Serverless Craic

Secure Cloud Architecture

Dave Anderson

There’s been quite a lot of talk about secure cloud architecture in the past few weeks. We always see lots of conversations about serverless and security. It’s one of the obstacles that people think of. Sometimes there’s a CISO who doesn’t want to touch Serverless because they believe it’s not secure. What do you folks think? Is serverless more secure or less secure?

Photo by Luis Villasmil on Unsplash.com

Mike O’Reilly

It’s a good question. I’m of the opinion that it’s more secure. We’ve talked in previous sessions about rapid delivery and the fact that we’re 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.

Serverless approach is highly opinionated

I think the other element tying back into rapid delivery and serverless is that serverless terms of the approach is highly opinionated. There are only so many ways that you can go about assembling your workloads and services. That’s not to say you can’t configure things in security. There still is responsibility there for application security that lands with the teams. And I know, we’ll probably talk about this later. But there’s probably a number of things that we do and that we’ve always done, regardless of whether or not we’re in Serverless. I think serverless definitely gives us more security. But it doesn’t mean that we don’t take it seriously, or that we don’t treat it as a fundamental.

Shared Responsibility Model

Mark McCann

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, in this instance. With 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 cloud architecture and give guidance. I know a lot of the vulnerabilities are announced regularly. When you go and check your app, you find that if you’re on serverless or lambda AWS have already taken care of that and that vulnerability has been addressed.

There’s a large benefit in letting the cloud provider manage and operate that because they’re going to be better than any internal team that you’re going to assemble. Serverless is more secure as a default, but based on your responsibility you can make secure cloud architecture insecure. And that’s where the guidance for well architected helps to address any gaps. So that makes sure that responsibilities that are yours/your team’s are taken seriously.

Risk Exposure

Dave Anderson

There’s also the risk exposure. If you have a purely serverless application, then you’re responsible for application security rather than secure cloud architecture. 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.

Reduce your risk exposure with Serverless

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.

There’s also a part for me on the attitude to Security. It’s traditional versus modern thinking. Traditional thinking is perimeter detection: we’ll build a wall with loads alarms on it and we’re done.

But with a modern strategy, it’s about securing each asset appropriately to what it contains. Your castle has a big wall around it, but once you get through the gates you can get access to everything. Once you get through the wall, there’s additional security, because the crown jewels have crazy security. The park or back yard is fine, you can walk around all day long as there’s nothing there that you can damage.

So you do need some perimeter protection to keep out the opportunistic hackers. But your real security is by each asset, where it’s locked in. I fear that many companies still have perimeter access.

Evolve your security attitude from Castle and Moat to Zero Trust

Mark McCann

We’re evolving from the Castle and Moat mentality to Zero Trust. You assess the trust as you go through and every individual component has its own security boundaries. There’s strength and depth. I think serverless helps enable a Zero Trust security stance.

Mike O’Reilly

A lot of those challenges exist if you’re in with a cloud provider or in your own data centre. I’ve found since moving into serverless workloads that you have more capacity for thinking about authentication, authorisation designs, processes, touch points and boundaries.

The capacity to understand Security

I’ve certainly had a lot more time to design those things and a lot of those services are flexible. Whereas, if you’re in the data centres, you’re working across a polyglot and have to support many different COTS capability. That can become challenging. The other way has a certain degree of flexibility or (what’s the word?) it’s a bit more accessible.

Mark McCann

With serverless and the responsibilities shifting left, teams have more visibility, ownership, and control over security. In the past with the traditional architectures and systems we worked on, security was almost taken care of for you by another team and you weren’t really exposed to it. It was on the perimeter somewhere: we’re fine because the permanently will catch up and we don’t need to worry about security!

Whereas now, it’s a requirement for the team to understand and have a handle on. Even though the burden is lowered, they still need to be aware of it, own, test and secure it.

Don’t shift left, start left

Dave Anderson

It’s no longer shift left when it comes to secure cloud architecture. I met Ian Heritage at AWS re:Invent 2021. His talk was about don’t shift left, start left. You need to identify your assets on Day One, and establish access control from the off. It’s part of what you need to do.

Mike, you mentioned, authentication and authorization. I think people beginning to understand this better now. You could be authenticated to get in somewhere, but still not authorised to do a bunch of stuff. Traditional security authenticated and let you in to go nuts on everything. Understanding authorization as a design consideration on Day One is absolutely critical. It’s hard to retrofit that.

OWASP Serverless Top 10

Mark McCann

There’s been a maturity around what security means for serverless workloads as well. The emergence of the OWASP serverless top 10 has been a big fall back in our careers. If you hear something, you can check OWASP and make sure we’re covered for it. So it’s good to see a tailored version for serverless workloads. And a lot of it is standard stuff that we would be addressing. But it’s good to see it called out that there’s different attack vectors here. The code that you use, the dependencies and NPM that you bring in are things you need to be aware of. But it’s good to google the OWASP serverless top 10 to get good advice.

Working with Security

Dave Anderson

So what about security itself? Do we still need a security department if developers can start left? Or do we still need a security presence: evil security people versus good developers? I think the relationship between security and developers is very important. And just for the record, I don’t think security are evil. I’m afraid that somebody will press a mute button on me.

Mark McCann

We’ve talked about this. You want security to be an enabler. You don’t want to be the ‘Department of No’. Historically that may have been the perception.

But typically, we’ve interacted with brilliant (security) people. They have buckets of integrity and they’re trying to do the right thing and balance a lot of different concerns: speed versus security, tech debt versus going fast etc. Some of the best people in the industry are in security. You should want to have a good working relationship and take them on the journey with you as you as you explore new stuff.

Shared responsibility between developer and cloud provider

Mike O’Reilly

It’s a symbiotic thing. Going back to the shared responsibility between the developer and the cloud provider, it’s the same thing between the developer and cybersecurity or the security department in your organisation. You’ve got to have a good working relationship. We’ve talked about this in previous discussions. The responsibility that a service team has for security, reliability, resiliency, performance costs, the operational side and security means that the application team has a duty to take security seriously. If they’re doing that then the relationship with cybersecurity is good. The interaction can be productive because it can be a consult or coaching session.

In threat modelling, you should never invent your own mitigations. You should be using well known ones, so you need that expertise within the organisation. If you’re not sure, it’s always good to have support from a cybersecurity expert to consult with and give you confidence that you have taken a good approach to security within your workload. And you haven’t come up with something that isn’t a good mitigation to a particular threat. It’s a symbiotic thing and it can be quite complimentary when everyone’s working at a good level.

Dave Anderson

You need to talk to security people and understand what you’re trying to do.

So that’s the craic. There’s more about this on TheServerlessEdge.com. On Twitter, we’re @ServerlessEdge. So thanks very much!

Transcribed by https://otter.ai