Well-Architected Performance – Push it to the limit!

One pillar of the AWS Well-Architected Framework is Performance Efficiency. At first blush this appears to be an oxymoron. If your focus is entirely on performance, then you’re probably not too concerned with efficiency. A Formula 1 car comes to mind. While such a car may be extremely performant, it’s never going to be as fuel efficient as a Prius. In contrast, efficiency often supplants performance in the interest of economy. But in the world of cloud, this is a false dichotomy. You can have your performance when you need it and do so in a cost-efficient manner. How? Simple. By following the recommendations from AWS, of course!

Let’s pretend you’re running our favorite company, Echidna Electronics. You recently launched a service, Project Bandicoot, that lets users subscribe and be notified when a newer version of their favorite gadget is released. The service includes videos and reviews of the new device, along with a trade-in program for loyal customers, aka Bandicoot Bandits. The architecture for the Bandicoot service uses multiple AWS components, including SNS, Elastic Beanstalk, DynamoDB, and SQS. You expect that the performance requirements for Bandicoot will be variable, with demand spiking when a new gadget is announced. This demand is somewhat predictable, but product announcements can sometimes come as a surprise, so you need to be ready to ramp up capacity at a moment’s notice.

When it comes to cloud performance efficiency, AWS offers five core design principles to consider.

1. Democratize advanced technologies

The first principle is to consume advanced technologies as a service. There usually isn’t a significant business advantage to having your team focus on building advanced infrastructures, when those same services are already available in the cloud. Instead, your Bandicoot team can focus on crafting the best experience for the end user.

2. Go global in minutes

You want to be ready to expand to other regions whenever needed. Performance tends to be latency sensitive, and you want your Bandicoot Bandits to have the best possible experience. Leveraging services that reduce latency minimizes customer churn and improves the user experience.

3. Use serverless architectures

Your Bandicoot team is all about shipping new features to the Bandits, and not about managing infrastructure and operating systems. Serverless lowers your operational burden and add on-demand scalability to every component of the architecture.

4. Experiment more often

In case you didn’t already know, the cloud moves at a furious pace, with new services and features being offered almost every week. It’s important to have your Bandicoot team try out new features to see if they can improve the performance of the system.

5. Mechanical sympathy

In the same vein, when selecting a platform for the Bandicoot components, you should consider how end users will consume the service. Understanding what the demand on the system looks like will help your team select platforms that match this demand.

As you progress in your design for the Bandicoot system, it’s vital to test your assumptions against realistic data. To this end, you’ll put Bandicoot through its paces to benchmark the baseline performance of its components, and to determine how the application as a whole handles heavier loads. The good news is that load testing and benchmarking are simpler in the cloud. Deploying a fleet of testing resources is as simple as running a few scripts and deploying a CloudFormation template. Load testing at and above a production load can help expose any potential bottlenecks or weak points in the design that might crumble under the pressure.

Of course, Bandicoot isn’t finished on day one. Sure, you held ideation sessions, performed a design exercise, and built a killer app. But demands shift, reality sets in, and things may not be performing as expected. That’s why it’s critical to regularly monitor and review your application design to look for potential performance bottlenecks and areas needing improvement. Monitoring shouldn’t happen in a vacuum, though. Ultimately the performance must benefit your Bandicoot Bandits in their relentless pursuit of the hottest gadget. It doesn’t matter if your DynamoDB table has a million read capacity units reserved if it turns out your web tier in Elastic Beanstalk is undersized and impacting the performance of the mobile app. The Bandits don’t care about your reserved database capacity; they care about a snappy, consistent Bandicoot experience. Make sure you’re monitoring their experience at the endpoint and finding ways to get feedback to materially improve the performance of the service.

While performance efficiency is a laudable goal. It’s not the only goal. As we’ve covered in previous posts, you also need to take into consideration the security, reliability, and cost associated with each design decision. Every decision represents a tradeoff between priorities. It’s an extension of CAP theorem, a.k.a. consistency, availability, and partition tolerance. As you progress towards one particular goal, you will necessarily move away from another goal. When reviewing performance within an application, you need to know how each aspect of the application is prioritized and be prepared to make tradeoffs. Understanding these tradeoffs and allowing them to inform your design will help you achieve performance efficiency.

To learn more about this Pillar of the AWS Well-Architected Framework, check out the official AWS whitepaper: Performance Efficiency Pillar. And if you’d like to see how your application stacks up, please feel free to schedule your free Well-Architected Review with a Certified AWS Solutions Architect from Anexinet.