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 Tune
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
Serverless Craic Ep11 Well Architected Performance Pillar