A decade ago, large-scale services were an edge-case scenario, often designed as one-off systems.
Then, in the mid 2000s, the financial services industry began using algorithmic trading and automated trading systems, which required scalability under extreme low-latency in a stateful transactional system. It quickly became clear that the classic tier-based architecture which was popular at the time was insufficient for this use case. That led me in 2007 to write about one of the first alternative architecture patterns for building large-scale systems, also known as Space-Based Architecture (SBA).
Today, applications like social networks, networking services and IoT have made large-scale systems the norm rather than the exception. As a consequence, we need a more systematic model for designing and implementing large-scale, SBA-type systems. Microservices architecture, in conjunction with the TOSCA modeling language, offers an excellent solution.
Let’s explore how this solution works.
Model-driven microservices
The key concept behind a microservices architecture is to break large systems into a set of loosely coupled autonomous services. The TOSCA language lets us describe the domain model behind each individual service, whether it is based on containerized or non-containerized components.
Model-driven design is an architectural concept in which the application or service domain model is defined first, and the rest of the interaction with the service is driven from that domain model. Take a look at this graphical illustration:
The building blocks provided by TOSCA to model this service include...
Node: Analogous to class in other object-oriented languages, a node can define specific interfaces and inherit others. TOSCA comes with a set of built-in nodes, and open source orchestration tools (i.e., Cloudify and ARIA) add a set of built-in node libraries that cover popular cloud resources like AWS, OpenStack, VMware, GCP and Azure.
Relationship: This defines the relationships among nodes.
Group: This feature packages nodes in “pods” and is used to manage the lifecycle of the group as a single unit.
Adding Custom Resources as Node Types: This capability adds custom nodes through imports of other libraries, as is done with similar languages.
Remote Execution Through Workflow: Workflow defines business logic, and TOSCA defines implicit and explicit workflows. Implicit workflows (i.e., install) execute the nodes’ lifecycle operations according to their dependencies. Explicit workflows provide a way to interact with the service nodes in an abstracted manner (i.e., upgrade).
Discovery Through Relationship: Relationships let one node discover other, related nodes.
Service composition pattern
So far we discussed how we can use the TOSCA language to describe the domain model of a particular microservice. Open source orchestration platforms that use TOSCA introduce a new pattern known as the service-proxy in which we can describe a service as a single node type to the other related service. The service-proxy pattern uses the service input/output as a generic way in which a service interfaces with the outside world.
The example below defines a composite service comprising a set of node types with two special service-proxy node types. The service-proxy node type is responsible for representing the output properties of external services as local properties of that specific node type. It is also responsible for either discovering or launching the related services (Microservice 1 and Microservice 2):
This lets us leverage existing TOSCA features for modeling the internal components of a specific service and also the relationship with external services.
Deployment-update is a feature in the open source orchestration approaches noted above that lets us update a service topology after it has been deployed. We can update existing services after deployment with new nodes, and we can change existing nodes.
In the example below, we use the service-proxy pattern in conjunction with deployment-update to add a new service to an existing composite service. We use deployment-update to add a new service-proxy node and point it to the new microservice.
Container support with cluster management options
TOSCA can be extended to support integrations with popular cluster management tools like Docker Swarm, Docker Compose, Kubernetes and Apache Mesos. TOSCA can manage container infrastructure and orchestrate services running on container platforms.
The need for generic service orchestration
Most large-scale systems never fit into a single platform and quite often come as a set of composite services that are linked together. To automate the processes of managing and delivering those applications, we need a generic service orchestration that is not bound to any of the underlying platforms but instead can integrate with many of them in order to fulfill cross-domain automation tasks.
This generic services orchestration doesn’t have to be an alternative to the more purpose-built orchestration (a.k.a. domain orchestration). It could actually use the domain-specific orchestration as an abstraction layer that hides the complexity of managing a particular service on a given target platform. The built-in neutrality and openness of TOSCA makes it an ideal service orchestration modeling language.
In summary
The explosive growth of IoT and distributed networks—and the degree to which they are now woven into the fabric of our lives—has created a dire need for large-scale computing systems that can scale, offer low-latency and high-availability, and are highly automated and manageable. A microservices architecture built with TOSCA is an excellent way to meet these objectives. This approach not only offers all the benefits afforded by microservices (scalability, fault isolation, flexibility, etc.) but also enables integrations with cluster management tools, container platforms and popular cloud resources like AWS, OpenStack, VMware, GCP and Azure. Best of all, the capability to build large-scale systems with microservices and TOSCA is readily available through the open source orchestration tools.
