Principle #4 – Experiment More Often – Meeting Performance Objectives – SAP-C02 Study Guide

Principle #4 – Experiment More Often

On AWS, you have instant access to all these advanced, serverless, and many other services. Therefore, you should feel encouraged to experiment with them, either to validate a concept or simply to test different configurations (compute, storage, and others) until you find the one that helps your solution deliver the best performance. In most cases, you can use any such service and only pay for the resources you’ve consumed, which is usually a factor of time and, occasionally, other elements, such as the amount of data (stored or transferred), the number of requests, and so on. So, there should be no barrier to experimentation.

Principle #5 – Consider Mechanical Sympathy

The idea behind this principle is to select the technology that best fits your objectives. For example, before selecting a database technology, make sure to factor in all the use cases involving the database and take into consideration items such as data access patterns, data structure, data lifecycle, and non-functional requirements.

These five principles provide guidelines to drive your rationale when designing the solution for your workload. The next section will cover, step by step, the major building blocks of any solution (compute, storage, database, network) and help you make choices depending on your performance objectives.

Architecting for Performance

As you can probably imagine, there is no single solution design that will provide optimal performance for all kinds of problems. Therefore, you must architect to address the problem at hand and then leverage the AWS services that can provide the best performance for your architecture.

First, you will need to design your solution using industry best practices and reference architectures. Are you building a website to serve end users globally? Are you creating a data pipeline to help data engineers? Are you crafting a platform to collect data in near real time from a fleet of devices? Each of these problems will call for different design patterns and distinct architecture approaches. Suppose after an initial phase of research and analysis of the industry best practices and available reference architectures, if any, you have designed a solution that combines multiple design patterns. Now what? Well, here starts the phase of selecting the right AWS services to best fit your design. But how can you do that?

First, architecting for performance should become part of your solution design process. Make sure to integrate some mechanism to benchmark your solution designs and ensure they offer optimal performance. Optimizing for performance will strongly influence the user experience but also impact the cost of your solution. So, opt for the solution that provides the best cost/performance compromise while meeting your business objectives and providing a great user experience.

Secondly, given the breadth and depth of the AWS portfolio, chances are that you will have more than one option to build your solution. To pick the right building blocks, you need to understand very well how the relevant AWS services could help you optimize your solution for performance. For that, you need to dive deeper into categories that are crucial to every solution: compute, storage, database, and network.

Finally, you can count on AWS resources to help, such as solutions architects or professional services consultants, or on AWS partners to assist with your design. You have the option to reach out to such resources and ask for guidance, or even just a second opinion.