When designing a workload’s architecture for a distributed environment such as the AWS cloud, you must design first to try and prevent failures, and second to handle failures. As previously mentioned in the design principles, your workload design must be able to cope with variations in the workload’s demand, detect failures, and automatically heal itself.
Before going any further, it is important to note that the AWS Well-Architected Framework, on which this book relies broadly since it is the backbone of AWS best practices, strongly recommends that you avoid building a monolithic architecture and prefer service-oriented or microservices architectures instead. Debating on monolithic versus any other style of architecture is beyond the scope of this book. However, it is noteworthy that monolithic architectures are often wrongly associated with evil big-ball-of-mud systems. It is unfair, considering that monolithic systems may have a very neat and structured design that has nothing to do with a randomly structured spaghetti code jungle, also known as a big ball of mud. On the other hand, a poorly built microservices architecture can very well turn into a distributed big ball of mud, which is considerably worse than a well-structured monolith; thus, make no mistake here; distributing the components of your system doesn’t make it more organized, it just makes it distributed. Adopting a service-oriented or microservices approach doesn’t keep you from bringing structure to your workload. In other words, it doesn’t keep the architect – that’s you – from properly designing the system to meet its requirements.
As mentioned in the preceding section, the Well-Architected Framework advises building service-oriented or microservices architectures for your workloads on AWS, but that remains a generic recommendation. Which approach should you take? Well, it depends.
Start by assessing your workload requirements and the environment in which it will operate:
Answering these questions will help you make an informed decision on which architectural style is best for you. Every architectural decision is eventually a trade-off between the pros and cons of each option. Selecting an architectural style is no exception. The rationale driving your choice must consider the highest benefits over time while reducing risks and costs. And, in some cases, it may even mean starting with a monolithic architecture, as counter-intuitive as this may sound.
Whatever your choice is, keep in mind the point that was made previously about one-way versus two-way door decisions. Your workload architecture will evolve over time and it is paramount to keep your options open for as long as possible. So, even if you decide to implement a monolithic architecture to start with, make sure to take a modular approach so that you can evolve toward a different architectural style, such as SOA or microservices, in the future.
I cannot stress enough the importance of looking at best practices, from AWS or other trustworthy sources out there. In particular, you will find a link to a whitepaper about microservices architecture on AWS in the Further Reading section at the end of the chapter.
Acedexam Training Policies
Learning resources
Other resources
Our Training Providers
