Just like any other company, AWS held his virtual conference. At this virtual conference, CTO Werner Vogels had the most compelling story. He stresses the importance of a good foundation when developing applications. You can only innovate and develop quickly on a well-designed foundation.
Many developers will immediately think of their favourite frameworks, with which they are busy developing new applications on a daily basis. Amazon Web Services (AWS) and Vogels refer more to the design of your infrastructure, not so much the language you are developing in. For the design of your infrastructure, AWS came up with the “Well Architected Framework“.
Vogels describes the Well Architected Framework as a reliable foundation with which applications can be built for the long term. Applications built with this framework are by default stable, secure and efficient. Both in performance and cost, according to Vogels. Nowadays, designing and building a cloud-native application involves a lot of work. AWS offers hundreds of services that can speed up application development and take the application into production, making it more efficient or cheaper. Achieving an efficient design that works well for your business model and application is not easy. It does require some study. The documentation around the Well Architected Framework and associated tooling can help. If there is no time for this within your organisation, an external cloud architect who is very familiar with the Well Architected Design principle can also do the trick.
The basic principles of the Well Architected Framework
Designing an application architecture is not that complex for a simple application in itself. However, if you are going to build a comprehensive SaaS solution or an application with millions of users, the costs quickly increase, and a well-designed architecture is fundamental. It can make a big difference in the usability and speed of the application, but also in the costs.
The Well Architected Framework has five pillars that are all equally important when designing an architecture. These pillars are:
- Operational Excellence, the ability to execute and monitor systems to add value but also to improve processes;
- Security, the ability to secure information and systems while assessing the risks and possible improvements in the security strategy;
- Reliability, the ability to restore a system in case of possible failures, but also the ability to scale up and down resources during busy and less busy periods. In addition, provide solutions in case of configuration errors or network problems;
- Performance Efficiency, the ability to use computing resources efficiently and meet minimum system requirements. At the same time, this efficiency must be maintained when demand for resources fluctuates;
- Cost optimisation, the ability to save costs by running systems at the lowest cost.
Based on these five pillars, an application can be designed that meets the needs of the business model. However, there are always considerations within the framework to save costs or improve performance. You can, for example, choose to save costs by sacrificing reliability. There is a big difference in costs whether you roll out the application in multiple regions or only in one region with some off-site backups. Whether this makes sense, depends on how critical the workloads are. A hospital may opt for multiple regions because it always has to be available, while a small retail organisation can live with a small downtime in the event of a major failure.
Key design rules
AWS has also included several essential design rules that apply when building a modern cloud application. Especially compared to running an application on-premise a lot has changed. One of the most important rules is that you no longer estimate in advance how much capacity you need to run the application. You make sure that an application can scale so that the cloud can use autoscaling to deploy extra resources when there is more or less demand for resources. Once an application is up and running, and you can identify your basic load, you can start looking at cost optimisations. The most important thing is that you don’t decide in advance how many VMs to deploy, you want to stay away from running many idle workloads, as you do on-premise.
It is also important to test systems properly. Not with a handful of users, but on a production scale. This way, you can see how your architecture responds to heavier workloads or during busy times. That is the only way to find and solve bottlenecks before they become a critical problem. Since you can pay for workloads per minute in the cloud, a heavy simulation of 10 to 15 minutes allows you to map out where your bottlenecks are, without the immediate need for substantial investments.
Where possible, use automation to build or expand your architecture. This allows you to react faster to changing circumstances without manual intervention. In addition, you can easily monitor this process and refine it where necessary.
Ultimately, the most important thing is to remain open to innovations and take them into account in your architecture. Try to see each component in your architecture as separate from the whole. If you treat it more or less like building blocks, innovations can be tested and possibly replace an entire building block with a more modern alternative that is more efficient, faster or cheaper. In the past, architecture choices were often made indefinite: for example, the decision was made for a MySQL database. As a result, all data was stored in this database. Many alternatives are now available. Primary data may still be in MySQL, but for caching or timing data, AWS offers solutions that can do that much better, faster and even cheaper.
The fact that there are now hundreds of services and solutions that you can use to build an application, does not mean that you have to use them all. The wisest thing to do is to analyse specific parts of an application, look for alternatives when components are expensive or need a lot of resources, tests new technologies, and decide based on the data what the best architecture solution is for that situation.
In order to make the right choice or to provide you with advice on possible good alternatives, AWS has designed the Well Architected Framework Tool. Based on your current application and used resources it can offer advice on where improvements can be made.
This tool has an enormous amount of best practices that AWS has gained from all its customers and can offer advice on how deploy or change workloads. This tool can be found in the console and will ask the necessary questions about the workloads you are currently using and come up with a piece of advice, based on comparing your workloads with best practices. Based on this advice, you can continue to design and test where improvements can be made.
AWS Well Architected Framework can accelerate innovation
Designing your application architecture according to the Well Architected Framework is not something you’ll master in a week. It requires an effort to understand it and work accordingly. In this article, we have gone no further than a small summary. If you use AWS a lot, but also other cloud services, it is certainly worth to dive into this framework. It changes the way you design and develop applications, but at the same time, it also allows you to innovate faster, save costs and improve security. In the end, there are many ways to enhance your cloud workloads. Although the AWS Well Architected Framework is based on AWS, it is also interesting and applicable for companies with a multi-cloud strategy. Ultimately, it’s all about designing an excellent cloud-native application.
If you want to know everything about the Well Architected Framework, follow this free course of AWS.
Tip: AWS will be dominant in every big city with Local Zones
10 hours ago
