Designing your workload service architecture is key to reliability. You can use either a service-oriented architecture (SOA) or a microservices architecture to build highly scalable and reliable architectures. While a service-oriented architecture (SOA) focuses on making software components reusable by resorting to service interfaces, a microservices architecture goes even further than that and focuses on making components smaller and simpler. In this article, we will discuss a series of best practices recommended by AWS that will help you design your workload service architecture with reliability at the top of your priority list.
Choosing how to segment your workload
Stay away from monolithic architectures, as these can lead to increased latency, increased complexity when debugging, and increased operational burden. Instead, you should choose either SOA or microservices. By using smaller segments, you have the potential for more agility, organizational flexibility, and scalability.
Microservices offers smaller segmentation than SOA, which tends to be preferable as it makes for a modern, scalable, and reliable architecture. Service-oriented architectures can benefit from the use of AWS App Mesh, a service that provides reliable discovery and access of services. Meanwhile, SOA has the advantage of allowing segmentation while avoiding some of the complexities of microservices. According to AWS, it’s best practice to use a microservices architecture whenever possible, as this will help you achieve the best agility and reliability.
Useful resources:
Implementing Microservices on AWS
Building services with a focus on specific business domains and functionality
When choosing the best alternative to design your workload service architecture, you should focus on the specific needs of your business. Each alternative provides different benefits that might be more necessary or not, depending on the type of business you’re running. On the one hand, SOA builds services that have well-delineated functionalities that are, in turn, defined by business needs. Microservices, on the other hand, domain models and bounded context, which result in services that do just one thing each. In order to differentiate the reliability requirements of different services, you should focus on specific functionality. This will enable you to target investments more specifically and obtain better results. By decomposing your services into the smallest possible components, you can enable organizational scaling and agility.
It’s best practice to perform Domain Analysis to map out a domain-driven design (DDD) for your workload. This will provide the information needed to choose the architecture type that best fits your workload’s needs. You should also take into account your workload’s design goals, limits, and any other considerations for use when defining the API. In addition, your API definition should allow for future growth and additional parameters.
Useful resources:
How to break a Monolith into Microservices
Getting Started with DDD when Surrounded by Legacy Systems
Eric Evans “Domain-Driven Design: Tackling Complexity in the Heart of Software”
Implementing Microservices on AWS
Providing service contracts per API
Service contracts can be extremely useful. These are documented agreements that take place between teams on service integration and include information such as machine-readable API definition, rate limits, and performance expectations. You can employ a versioning strategy to allow for the continued use of the existing API while the migration to a newer API is happening. Under this model, deployment can take place at any time, as long as the parts respect the contract. Service contracts also allow the service provider team to use their technology stack of choice to satisfy the requirements set out in the contract. In the same spirit, the service consumer is also encouraged to use the technology of their own choice. It is highly advisable for developers to use Amazon API Gateway. This fully managed service makes it easy to create APIs at any scale. API Gateway allows for versioning and deployment of the APIs.
Useful resources:
