A key differentiator of the cloud is the way applications are designed and deployed, with services-based architecture being the most popular. Services matter because they allow for applications to be designed into ever smaller components that have faster deployment velocity allowing business ideas to come to market quicker. In addition, the smaller a service or function, the smaller the blast radius, meaning that a fault or bad code only impacts a relatively small amount of connected services. This reduced blast radius has a significant improvement on the risk profile of code deployments and the time required to roll back if something bad was introduced:
The preceding diagram shows a monolithic system, deployed to multiple instances for high availability, but using a design pattern to deploy the full application functionality into an application server on each instance. In this case, the business functionality boxes are an example of a subsystem that would have many different functions, or primitives that are included to complete the required functionally. In this example, the deployment of new code must be done at the system level and will likely require scheduled downtime and a full redeploy of the entire application artifact. If any of the newly deployed code has an unintended bug in a subsystem or primitive, the entire application will be impacted since it's all deployed together. This unscheduled outage will roll back the entire application artifact, even subsystems that were working as intended in other parts of the system. This design is not very flexible and causes long and stressful big bang deployments that need to be planned for weeks or months in advance.
By decoupling systems and the business functionality into separate subsystems, the interaction points between these subsystems is significantly lowered and often they will never communicate at all. Using subsystems and primitives in the form of services allows for the changes being made to be vastly less impactful to the wider organization, causing the risk associated with those changes to go down because the blast radius is reduced to only those services directly related to it. Depending on the requirements, a subsystem might still be an isolated coupled component or broken into many primitives:
In the preceding diagram, the original monolithic application was redesigned and deployed into separate subsystems and primitives, using a mix of instances, containers, functions, and cloud vendor services. Not all services interact with each other or persist data, so if there are problems in the environment most are still usable. Subsystem 1 shows as having an outage due to bad code being deployed, which will be discovered and resolved by the appropriate services team. Meanwhile, all other services are still operating with no impact, unless they were to interact with subsystem 1. The diagram also shows the impact of a single instance outage due to hardware fault, a common occurrence that should not impact the entire system or any individual service. Subsystem 3 would detect that it lost an instance in its fleet and automatically deploy a new instance or container to keep up with incoming requests. Primitive Microservices 5 and 6 are executed as event-based code blocks that interact with other primitives to persist data, interact with message queues, or perform a business function.
Services matter since they allow for separation of functionality, reduce blast radius, increase business velocity and, if done correctly, reduce the cost to run the full system.