Serverless Craic from The Serverless Edge

Send us Fan Mail

We're continuing our series on Modern Cloud looking at the Modern CEO.

What does a CEO expect from Modern Cloud? They want capability from your engineering or IT organisation. They also want speed. And flexibility. I don't think they care about Lambdas or Kubernetes! It's good way to really frustrate your CEO if you tell him all about Kubernetes and Lambdas.

As a CEO, you're going to have the needs of your customers in your mind. You're going to have user groups needs for your company to meet. You can look at Modern Cloud and think, how can I rapidly meet the needs of those customers or users? What capabilities does Modern Cloud provide me with? They are looking to Modern Cloud to quickly stand up capabilities to meet those needs.

A big part of Modern Cloud is aimed at integrating with things that exist. Let's not build it. Let's not start way back with nothing and work our way up. It's the Buy, Rent, Build question! In my experience, CEOs are obsessed with the customer in the business domain that they're in. They're very focused on that industry. The healthy question to ask is: 'why are we building that?'. Why are we building that thing if it doesn't have anything to do with our core business. There's a value chain that you can draw. 

There's a new appreciation that modern cloud can actually drive your business. It's not just a cost centre. If you have a modern cloud attitude in your company, engineering is actually part of the business. Engineers are not stuck in the IT department. If everything is stuck in the IT department and it is treated like a black box, you might be doing modern cloud, but you're not getting the commercial benefits from bringing the tech potential to your business leaders.

The next one is Speed. We've talked previously about 'Time To Value'. It's not how fast the developer can type in the code. It's the value stream from an idea to how quickly that makes it into the hands of the customers. That's not just IT. It's the whole org from front to back. And obviously, in the modern cloud, you can speed that up. You should be able to go from ideation, discovery and framing through to production and into the hands of a real customer and delivering value in days if not hours.

There's a nirvana point where you're having discovery and framing sessions with the business and your end users, and you're actually showing them real prototypes in real production environments that have been toggled appropriately so that they're not exposed to the existing customer base.

There is a flywheel effect here! But if the flywheel gets stuck and you're spending ages iterating, there's inertia and stoppage. When you start executing quickly, Product realises they can ask for things quickly. The flywheel starts to turn. 

The third item is flexibility. There's a couple of different ways to think about this: the ability to pivot a line of business or the ability to scale in different ways or different global locations.

You're able to do 'safe to fail' experiments in a rapid fashion.  Your feedback loop is a lot tighter. You can pivot more efficiently and effectively to find that product/market fit. From a CEO's point of view, they want to have lots of options and they don't want to go through one way doors, They want two way doors. So if it doesn't work out, they can come back out and try something else.

There are data implications as well. Organisations that embrace modern cloud are able to leverage data capabilities and expand into new products or ventures or experimentation. They're not fixated on yesterday's success. They've got their heads on a swivel, looking for that next opportunity. It's a radical target for orgs that embrace successful modern cloud.

Serverless Craic from The Serverless Edge

theserverlessedge.com
@ServerlessEdge

Serverless CrAIc from The Serverless Edge
Check out our book The Value Flywheel Effect
Follow us on X @ServerlessEdge
Follow us on LinkedIn
Subscribe on YouTube 

Send us Fan Mail

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

In this episode we describe how a modern cloud team can do everything themselves. They rarely need to go outside their team for help.  They're ‘fast flow’. There's very few handoffs, You still need, not necessarily a DevOps team, but you need enabling teams.

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. 

Check out our book The Value Flywheel Effect
Follow us on Twitter @ServerlessEdge
Follow us on LinkedIn

Serverless Craic from The Serverless Edge

Serverless CrAIc from The Serverless Edge
Check out our book The Value Flywheel Effect
Follow us on X @ServerlessEdge
Follow us on LinkedIn
Subscribe on YouTube 

Send us Fan Mail

Over the last six episodes, we have gone over the well architected framework from AWS. As a recap, we think this is a fantastic framework. It's about your workloads. Like a physical building, if the foundation is not solid, it may cause structural problems that undermine the integrity and function of the building. So you need to look at all six pillars for your workloads. And that's what you do to effectively produce sound and stable systems.

Operational excellence: it's the ability to run and monitor systems to deliver business value, and continually improve support, processes and procedures.

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

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

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

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

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

Mike's favourite is: operational excellence. I'm a big fan of continuous improvement and getting yourself into a sustainable way of working. How do you learn from failure? How do you react to certain things? How do you have visibility of everything around you? If you can assemble that apparatus and those behaviours, then you can begin to eat into the other pillars. For example, operational excellence gets into how to observe if something's working in production, or if something's failing in production. If something's failing in production, how do you deal with it?  If I'm going into a new team or area, I'll always start with operational excellence. This one is very consistent across all squads and all parts of the organisation. That's probably my favourite, because I know it so well and I rely on it.

Mark's favourite is the sustainability pillar. I think it if you have all other things in place, the sustainability pillar will really drive you to that next level. If you're trying to deliver a sustainable solution, you can't do that without having a good handle on the other five pillars. So I think sustainability and the sustainability pillars and the questions within them, are a forcing function for good practices, processes and architectural choices that the other pillars are continuing. With our serverless first mindset and approach I think it lends itself well to the sustainability pillar. 

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

Serverless Craic from The Serverless Edge

theserverlessedge.com
@ServerlessEdge

Serverless CrAIc from The Serverless Edge
Check out our book The Value Flywheel Effect
Follow us on X @ServerlessEdge
Follow us on LinkedIn
Subscribe on YouTube 

Send us Fan Mail

We're continuing our conversation on the well architected pillars looking at what is our favourite pillar. Today we're talking about sustainability.  There's a list of best practices that are broken down into sections:

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

Region Selection is quite straightforward. Some regions are supplied with greener energy than others. Some regions are using non sustainable resources, depending on where you are in the world. If you don't have massive latency requirements, or a real need for super fast, low latency, then you're probably best putting it into a more sustainable region. So where you put your workloads can have a sustainability impact.

User Behaviour Patterns is about using assets in an elastic way with the latest technology. It will be more sustainable, efficient and cheaper on modern cloud. If you go down the legacy cloud route, and treat the public cloud like a data centre, then you're not going to be very sustainable, you're not going to be very cheap, and you're not going to be very efficient.

Software Architecture Patterns is about keeping your code base and your architecture really efficient such as refactoring optimization and more effective data access. It's good practice as it ties back into efficient design. When you work in enterprise spaces, you do question the value of older business products that are running in the background. You've got to constantly assess if this is worth the compute? 

Data Patterns: there's an awful lot of waste with data flying around the internet. There's a lot of good practice here. Data can be quite toxic for various reasons from privacy breaches and security points of view. You should have a good handle on this. Your data classification is critical. If you don't extract value from it, get rid of it or it's going to be unsustainable. Everything's becoming more data centric, and the amount of compute that goes into chomping data is 90% of what IT. I'd love to see how much electricity or energy is used on processing data. I am keen to see how organisations approach this one.

Hardware Patterns: is right sizing our stuff correctly. We've all been in teams where the question asked is: 'what size box do you need?' And the answer back is: 'the biggest one humanly possible!'. It's a natural reaction but you don't need that. This is where a serverless first mindset and approach really kicks up a gear. You don't even have to concern yourself with a lot of these questions. It automatically scales up and down appropriately. We don't have to worry about picking hardware or incident sizes ahead of time.

Development and Deployment Process: how do you increase utilisation of build environments? We see this quite a lot where environments sprawl and asset's sprawl for no real benefit. So again, it's all about being smart about how you set up your clients, how you set up your pipelines and how you set up your environments to make sure they're actually delivering value. And they're not just there because that's the way we have always done it. The question here is: 'how do you adopt methods that can rapidly reduce or introduce sustainability improvements?'. If you're on a serverless spectrum, the cloud providers are working for you and they're introducing new capabilities.

Serverless Craic from The Serverless Edge

theserverlessedge.com
@ServerlessEdge

Serverless CrAIc from The Serverless Edge
Check out our book The Value Flywheel Effect
Follow us on X @ServerlessEdge
Follow us on LinkedIn
Subscribe on YouTube 

Send us Fan Mail

We're continuing our talks on Well Architected with the fifth pillar which is AWS cost optimization. There are 10 questions and 5 subsections: 

1. Practice Cloud Financial Management, 
2. Expenditure Awareness, 
3. Cost Effective Resources, 
4. Matching Supply and Demand, and 
5. Optimising Over Time. 

Practice Cloud Financial Management is a maturity step for teams to be able to know how much their stack costs. There has been a big shift in architecture, since we've got more visibility into cost in the last number of years. When you were working on the enterprise mainframes, you were dealing with capacity. And maybe you did get into licencing and availability of licencing but you never talked in terms of cost. 

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

Expenditure awareness: To grow that awareness, education is critical.  You need to make teams aware that these things are available to you.  So how do you govern usage? How do you monitor usage and costs? And how do you decommission/how do you switch things off?  If you're in a leadership position, you should be able to see a breakdown. If you have five applications in your portfolio you should be able to know the cost breakdown from those five, at the very least. That's not that hard to do.

Cost Effective Resources:  Developers, always want to pick the fastest, craziest and wildest thing. But is it more cost effective? Sometimes you don't need the fastest thing and a moderate speed will do the job. This point to sustainability as well.  It's not how fast can you get it? It's how fast do you need to provide adequate service?  The total cost of ownership comes to the fore here. It's not what is for right now. It's the long term operational burden and cost.  You can choose a technology that's super low cost, but the cognitive burden is massive because it's a new technology that's outside your team right now. Then, what's the learning cost for that team to learn the tech stack or language that you chose for cost efficiency reasons? You have got to take a bigger view. It's not just for what you're doing right now. How do you plan for data transfer charges. That's definitely one to look at if you have a large data footprint.

Matching Supply and Demand and Optimising Over Time.  I've lumped these together. There's a piece around keeping up with the latest and greatest in AWS and tweaking your design so that your continuing efficiently. There's also a bit about selecting new services as you build new stuff and selecting wisely for a decent cost impact.  This is where we see the serverless advantage kicking in.  Matching Supply and Demand is taken care for you as it scales with the load. If you're on traditional architectures or EC2, you might need to pre provision some other stuff and have it at hand and ready to go.  That's a hard calculation to get right. You're going to have a lot of wastage with excess capacity just waiting to go whenever the demand comes in. So it's a lot easier when you're serverless.  

Serverless Craic from The Serverless Edge

theserverlessedge.com
@ServerlessEdge

Serverless CrAIc from The Serverless Edge
Check out our book The Value Flywheel Effect
Follow us on X @ServerlessEdge
Follow us on LinkedIn
Subscribe on YouTube 

Send us Fan Mail

In this episode we're continuing our series talking about well architected pillars.  Today, we're going to talk about the Performance Pillar which is called performance efficiency. 

It's got four sections: Selection, Review, Monitoring, and Trade Offs. It is really about the performance efficiency of your whole system. There are five questions about selection. The kicker question is the first one: 'how do you select the best performing architecture?'.

You should go really hard and deep to make sure you understand the problem you're trying to solve for the users that are going to use a system. What are their needs? Once you have that to hand, do something like domain driven design to break it up a little bit and make sure you have good boundaries and domains established. When you have all that you're well informed. 

Evolution is critical. It might be the best architecture to meet the needs right now, but is there scope, capacity or room for it to evolve to meet unexpected future needs as well?  I want to move fast. But I reserve the right, at some point, as we scale up or the system evolves to pivot and change reasonably quickly. This is another factor with serverless. Because it's event driven, you're forced to use event driven style architectures so it lends itself to that sort of evolution. You can swap things out later on.  If you need a container, a SAS or an external vendor, it's pluggable.

But there's a bunch of non functional requirements  that need to be right. This is where you get into the idea of is this a commodity component? Or is it something that's mission critical to your business or a piece of IP. Do you need to build it? Or can you just rent it? Wardley mapping helps you to think whether or not to build. For example, we need global storage so let's try and build that. The answer is no! Just use S3.

I think one of the best things with a serverless approach to performance is that the cloud provider is constantly working at improving performance efficiency, reducing costs, speeding up and adding more horsepower to your compute. By choosing smartly, with your architecture, you get a free underlying platform team that is constantly working on improving your performance. And you can just take advantage of it without having to worry. You can leverage that performance improvement.
 
Moving onto the next section and relating to what you said is how do you constantly review your architecture to take advantage of new releases? Cloud providers are constantly innovating and releasing stuff every week, so you want to be in a position where you can add new stuff quickly without breaking the whole architecture. You need to operate a 'two way door' as Amazon call it where you go in, do something and then get back out again. You don't want a one way door where you get trapped.

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

The next section is Monitoring and how to monitor your resources for performance, which is fairly straightforward. 

And the last one is Trade Offs and how to use trade offs to improve performance. A  great example is Lambda Power Tuner, where you can tune your function based on memory or CPU to get that nice balance between cost and performance. 

Serverless Craic from The Serverless Edge

theserverlessedge.com
@ServerlessEdge

Serverless CrAIc from The Serverless Edge
Check out our book The Value Flywheel Effect
Follow us on X @ServerlessEdge
Follow us on LinkedIn
Subscribe on YouTube 

Send us Fan Mail

In this episode the team continue their conversation on the well architected framework with the Reliability Pillar. 

It has 4 sections: foundations, workload architecture, change management, and failure management. If you're building in a traditional way then reliability can be a huge amount of work. But we're serverless heads. AWS make it a lot easier to do some of these things. 

A lot of service quotas and constraints are baked into the foundations. From a change management perspective, you want to get into the continuous delivery kind of mindset, so there's a lot of monitoring if you use the modern tools. From a failure management perspective, serverless is ephemeral, so it's built for retries. You can design so that those areas are slightly easier to work with. 

When you look at the foundation section of the reliability pillar, you're probably looking at how to plan and not over provision or overspend and how to scale up effectively. You put a lot of time into the foundation section, where as if you are in Serverless you still need to look at foundations, but I think it's less intensive. 

From a change management point of view, adapting to change is built into serverless capabilities and how managed services operate. 

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

There's lot of stuff that AWS has thought about for you in relation to the foundational side and you can benefit from that. And that influences how you actually assemble your workload in terms of the workload architecture as you've got to work within those constraints. 

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. 

Some of the questions look at: if we auto scale this serverless component, what sort of load or pressures are put on something that doesn't auto scale? It forces you to think about protection and where are the choke points? Should you be throttling your workload? Should you be setting constraints on the scalability of your serverless workload? 

Those type of questions get to something that we're very passionate about, which is testing for resilience and continuous resiliency, and having test days or game days that tease out where the choke points are. Where are your failure cases? Where are the downstream systems that can't respond or can't take the load as you pass to it?

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

Serverless Craic from The Serverless Edge

theserverlessedge.com
@ServerlessEdge

Serverless CrAIc from The Serverless Edge
Check out our book The Value Flywheel Effect
Follow us on X @ServerlessEdge
Follow us on LinkedIn
Subscribe on YouTube 

Send us Fan Mail

This week, we're continuing our series looking at each of the pillars of the well architected framework. We talked about the operational excellence pillar in the last episode.

We're going to talk about security this time which is our favourite well architected pillar. There are 10 questions for this pillar and a couple of different sections.

The well architected security pillar is aimed at checking how secure your organisation is. It goes into things like:

How are you managing accounts? 

Is your control tower hooked up?

Are you using guard duty?

It promotes team awareness of security across the organisation.

The types of things to engage with when looking at workload are blast radius:

If something goes down, how are we going to recover it?

Or is there a case there for failover?

Or resiliency?

It is broad but there are things you can zoom in and focus on in that question.

With the modern techniques, capabilities and improvements, you can be fine grained and have more accounts. Single sign also helps manage that burden. And AWS organisations, control tower and cloud trail are mature capabilities that help you get a good initial posture.

One thing about well architected is that there is a nice flow to the questions and sessions.

The first question: 'how do you securely operate your workload?', straight away gets into identity and access management, your inventory of people on machines and how you manage that. Or how do you manage blast radius, permissions, and the process of adding and removing people, accounts, machine accounts and different resources.

In a modern cloud environment, rule number one is that it is tightly managed and automated. Normally, it ties back into the enterprise or a broader policy and it gets teams asking what are the authorization controls for this component.

The next is one of my favourite: detective controls, how you detect and control security events. I always love the way security people talk about 'left of attack': all the things that happen before the attack. There is the time when the attack happens and that's panic stations. But there's usually a whole bunch of stuff before that, that you can act on. And that could be two years prior. So there's a whole mindset around detecting weird activity when people are probing your system, before the actual attack. That's the hunter side of cybersecurity when people try to find breaches.

The next one is data protection. There's stuff here about both encryption etc, in rest and in transition. We have mentioned that code as a liability. Your data can also be a liability that you need to manage appropriately. Organisations have a good data classification document or something that describes data classification as it pertains to the industry or the organisation.

The last section is 'incident response'. It's fairly self explanatory. How do you respond and recover from incidents? You want to be well drilled with as much automation as possible. Sounds straightforward. But it's complicated. It ties back to the operational excellence pillar. You're anticipating these events ahead of time. If you're anticipating them, you have associated runbooks or playbooks to facilitate squads in particular circumstances. 

In the security pillar, there's a nice arc that starts with people and ends with people. It goes through all the technical stuff in the middle. But security is a 'people' responsibility.

Serverless Craic from The Serverless Edge

theserverlessedge.com
@ServerlessEdge

Serverless CrAIc from The Serverless Edge
Check out our book The Value Flywheel Effect
Follow us on X @ServerlessEdge
Follow us on LinkedIn
Subscribe on YouTube 

Send us Fan Mail

There's been a lot of good conversation about well architected and the well architected framework. And we've written about this in the blog: well architected and SCORP or SCORPS, which is the five and now six pillars of well architected. 

So we figured we'd do operational excellence first,  the AWS pillar breaks down into three areas. Each area has five or six questions. So the three areas (in the operational excellence pillar) are prepare, operate, evolve.

It's great to go in new areas and teams to asking these questions: Do you know who your users are? Do you know what what the purpose of your team is? Do you know what your highest priority thing is? If you are in a safe space with the whole team involved you can get a really good conversation. It's 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'? 

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.

It checks simple stuff like: do you have enough people to meet the challenges? Do you have assigned owners who are going to be responsible for processes, practices and operations. If you can get these foundations in place early, you evolve, go down through the lifecycle and start applying the other well architected pillars. Your chance for success greatly improves because your operational excellence pillar has set the foundation.
 
The next pillar is operate.  So you start with prepare and then move to operate. I like operate because there's a lot of observability.  I like thinking of a workload as an asset, how to understand the health of that asset and how to monitor it to make sure it's working well.

It's about getting the team ready for production. There's always something that is going to go wrong, something you haven't predicted or an alternate path has been missed. So when those things happen, have you got the correct procedures for learning what that defect teaches so you can bake it in and toughen up your operation going forward. It's an holistic way of thinking and you need those mechanisms to show you how your workload performance by product. 

If you have proper observability you can show the C suite 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.

The last one is evolve. You go through prepare, operate and then evolve. And it's quite simply about how you evolve operations which doesn't mean cutting costs and reducing the budget!

We're big into mapping and evolution is a cornerstone of Wardley mapping. If you don't take these signals from your systems and your workloads on board and use them to evolve improve and get better than there's no point having observability and dashboards.

Your operations are going to generate a lot of data and  useful information that you, as an engineer, manager or architect can use to evolve your current setup. You should be always looking to learn.  You set up for success and you put the foundational building blocks in place to increase your chances of a successful development cycle.

Serverless Craic from The Serverless Edge

theserverlessedge.com

Serverless CrAIc from The Serverless Edge
Check out our book The Value Flywheel Effect
Follow us on X @ServerlessEdge
Follow us on LinkedIn
Subscribe on YouTube 

Send us Fan Mail

The team talk about serverless and security. 

Sometimes there's a CISO who doesn't want to touch Serverless because they believe it's not secure. Is serverless more secure or less 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. 

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 and give guidance. 

There's also the risk exposure. If you have a purely serverless application, then you're responsible for application security. And if you mess up application security then maybe somebody might steal detail or data or hijack a session. But you know that it's at an application or session level and infrastructure security is handled by the cloud provider. But if somebody compromises your infrastructure security such as ransomware, then your whole company is down. Losing customer data is bad. But losing your entire company's data centre is catastrophic. So the exposure is slightly less with Serverless. .

You need to sit down with security people and talk to them to understand what they're trying to do. 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. 
 
Having a shared vocabulary and a common language is critical. We have had great success with threat modelling to help bridge that common language/vocabulary. Threat modelling, as a technique has been awesome, not only for good application design, but also for having conversations with security partners/teams on the threats we have identified and what we're doing to mitigate them.

When you come to the Security Team and say: 'This is what I think you want to do. And this is how I think we should do it.'. You're opening up the conversation. That is a key point. These collaborative, facilitated team based activities, surface so much value. 

As an architect, I think it's a really good exercise for making sure you understand how teams are going about certain things as well. So you're constantly validating your thinking. When you are walking through the Microsoft threat model, you're building DFDs (data flow diagrams), and you're constantly reaffirming what it this talking to here, what are we doing, what what are we passing across?  

One last point on the threat modelling piece is when you get into the mitigations, and how you verify your mitigations, it leads you down the path for creative testing. You are arming your engineers with ways to test the system through a different perspective and you look at different techniques. 

Another great piece is identifying a developer to be a security champion. And it isn't about always identifying the most senior developer. 

Serverless Craic from The Serverless Edge

theserverlessedge.com
@ServerlessEdge

Serverless CrAIc from The Serverless Edge
Check out our book The Value Flywheel Effect
Follow us on X @ServerlessEdge
Follow us on LinkedIn
Subscribe on YouTube