We look at the AWS Performance Pillar in this article. We have worked on many technical teams in various roles, and one of the most common challenges that came up time and again was performance. In traditional, on-premise environments, efficiently achieving performance goals can be challenging. One of the hallmark innovations of cloud infrastructure is the ability to rapidly scale up and down to maintain consistent performance, regardless of demand, and to align your spending with your usage.
AWS’s well-architected framework is one of the best collections of best practices available for organizations in a cloud transformation. The “Performance Efficiency” pillar of the Well-Architected Framework introduces itself this way:
“The performance efficiency pillar focuses on the efficient use of computing resources to meet requirements and how to maintain that efficiency as demand changes and technologies evolve.”
We talk through the ins and outs of the AWS Performance Pillar in the fourth part of our series of talks on well-architected pillars. Performance efficiency is a work-based development conversation. If your business brings in little money, you don’t need all this horsepower under the hood. It can be something other than that efficient from a performance point of view.
The Performance Pillar is strangely fascinating. It’s called performance efficiency. Each of the well-architected pillars usually has around ten 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, and the kicker question is the first: ‘How do you select the best-performing architecture?’.
AWS Performance Pillar: Selection
You only throw loads of technology at solving a problem if you understand your users and their needs. You should go deep to ensure you know the problem you’re trying to solve for the users who will use a system. What are their needs? Once you have that to hand, do something like the domain-driven design to break it up and ensure you have established good boundaries and domains when you have all that you’re well informed. And now, you can think about the best architecture that can meet users’ needs.
We have been in this position three times in our careers when you pick an architecture for a big problem. It’s a moment of responsibility because that architecture might need to last 10, 15, or 20 years. And you have to be careful about what it’s for, what it will do and will do in the future. The few times we 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 beginning and figure that out.
Mental model
The idea of the mental model of the system is fundamental. 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. It 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.
Future needs
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?
From our experience over the last number of years of adopting the serverless first mentality, AWS, GCP, and Azure have opinionated managed services that you can integrate and assemble. When you want to develop fast, focus on the correct domain with logic in the right place and consider a socio-technical view of the organization. Refrain from overthinking or overdesign because you want to move fast. But reserve the right, at some point, as you scale up or the system evolves to pivot and change reasonably quickly. It is another factor with serverless because it’s event-driven. You must 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
There’s something important about Performance efficiency and breaking your system down into domains and components. To an engineer: did you see that component? You have to do X, Y, and Z; the systems must work and be well-architected. So figure out how to make that happen.’ And if that’s calling a managed service from AWS, that is fine. That’s building something. But many non-functional requirements about that box need to be corrected. Do you understand whether this is a commodity component, 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.
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? Can you fall back to something with serverless characteristics if it doesn’t?
An example would be: does DynamoDB fit your needs for your data? If it doesn’t, can you fall back to something 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
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 can optimize or streamline? You can facilitate those conversations as part of this review.
One of the best things about a serverless approach to performance is that the cloud provider is constantly improving performance efficiency, reducing costs, speeding up, and adding more horsepower to your compute. Choosing smartly with your architecture gives you a free underlying platform team that constantly improves your performance. And you can just take advantage of it without having to worry. You can leverage that performance improvement.
AWS Performance Pillar: Review
The following section concerns reviewing your architecture to take advantage of new releases constantly. Cloud providers are constantly innovating and releasing stuff every week, so you want to be able to 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.
Mapping can be advantageous to your teams here. If you’ve mapped out your tech stack, you understand the components and can see where they are on the evolutionary axis. When a new capability or service comes out, you can immediately 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.
We’ve done this in the past! We’ve been building something, but then you think something will come out that will do that job for me. So, build it so you can replace it quickly when something comes out. Event Bridge is a good example. We used an SNS SQS finite-type approach to the event for a long time. And then Event Bridge was released. The team was trying to get latency reduced and constantly looking at that. And then realize that we can make that cutover when you reach a certain level. But it’s an excellent example of how to evolve and plan for that.
We need another Serverless Craic episode on how to keep up with the pace of change and the firehose of informational updates. There is a good return on investment in using time by having your radar up, being aware of how the environment around you changes, and being open to adopting new capabilities that can save money and effort.
Monitoring and Trade-Offs
The following section is Monitoring and how to monitor your resources for performance, which is relatively 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.
What are you willing to pay for? Is it worth it? Performance efficiency quickly becomes a work-based development conversation. If the business brings in little money, you don’t need all this horsepower under the hood. It can be something other than that efficient from a performance point of view. And there’s a sustainability thing there as well. Do you need a sub-second response time for something? A one-second response time may be okay. Don’t burn through everything just for the sake of it.
Don’t over-optimise
It is an excellent habit to get into. Is our lambda too big? What can we do to thin it down and shorten it? Anytime we run this, we typically see quite a lift. We’ve seen teams go from three-second response times to half-a-second response times because they’ve trimmed something down.
When you get all this in place, there is a fear 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. And it will be an excellent 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 and LinkedIn.
4 thoughts on “AWS Well-Architected Framework: AWS Performance Pillar”