What is an Organic (Microservice) Architecture?
Because Glasnostic is an operations solution that lets enterprises run the vast and continually evolving service landscapes that their teams create, we are often asked about our learnings and how they might apply to them. Our learnings tend to revolve around two facts. First, that subjecting each new service to a central “command and control” architecture is one of the biggest impediments to innovation. The second is realizing that a service landscape is ideally operated as an organic architecture.
In this post, we’ll explore at a high level what an organic architecture is, how it complements the organic enterprise, how enterprises typically transition from a static to an organic operating model and what technologists and operators need to watch out for when running an organic architecture.
TL;DR
The best architectural style to support an agile enterprise is that of an organic architecture. An organic architecture is a service landscape that consists of digital business capabilities and evolves through organic federated growth and that is thus able to adapt readily to the needs of an agile enterprise.
The Agile Organization
A long time has passed since we viewed enterprises as fixed machines, designed for stability, with siloed business units and a strict, hierarchical structure. These organizations evolved in a linear fashion, guided by linear, long-term planning. Today, we recognize them as organizations that seek to adapt to the numerous and diverse, as well as rapidly and continually changing business needs with as much agility as possible. Often driven by digital transformation, they have organized around parallel, self-managing teams and adopted rapid decision and learning cycles that allow them to adapt to and evolve in step with business needs.
This continuous adaptation to business demands in turn has forced technology organizations to adopt a different operating paradigm as well. Instead of designing and creating a fixed enterprise architecture, technology groups increasingly operate new services on top of and next to existing applications. This results in a continually changing landscape of services. Because new services are built on top of existing ones, what used to be regarded as an application becomes an independent digital business capability, ready to support new services as needed. Also, because service landscapes evolve through organic federated growth, i.e. the organic addition of new federations of services, they are ideally suited to provide the business with the technical agility it needs to adapt to business demands.
An organization that is able to adapt to changing market needs can be thought of as an organic enterprise. Similarly, a service landscape that is able to adapt to the changing business needs of an organic enterprise is an organic architecture. In that respect, organic architecture mirrors and supports the organic enterprise. Like an organic enterprise, organic architecture is not a machine and is capable of exhibiting complex emergent behaviors that need to be managed. And like leadership in an organic enterprise, the role of operations in an organic architecture changes to one that sets direction and enables action.
Technology Journey
While transitioning from a “traditional,” static operating model to an organic one, enterprises typically pass through a number of stages that impact almost all business and technical groups within the organization:
- At the organizational level, top-down hierarchy is replaced by parallel, self-managing teams. Subsequently, the culture of “command and control” is replaced by fast decision and learning cycles.
- At the software architecture level, decomposing monoliths into microservices allows static architectures to grow organically. This in turn prompts some microservice components to become digital capabilities, which ultimately help realize an organic architecture.
- As APIs become commonplace, the middleware in use typically transitions from integration technologies to API gateways. At the communication level, it likely transitions to communication libraries and possibly service meshes for some fast-moving environments. Finally, as interactions between applications and services continue to proliferate, a cloud traffic controller becomes indispensable.
- Operations teams typically will have moved to a DevOps model and possibly adopted SRE practices before creating a new, “mission control” operations group.
- At the infrastructure level, enterprises will typically find themselves operating a service landscape consisting of a wide array of technologies, everything from VMs to containers, serverless, IaaS, PaaS, managed services and SaaS.
While this model of the technological journey from a static to an organic operating model is typically representative, it should be noted that in practice, individual journeys may assign different weights to the various sub-journeys. For instance, a traditional enterprise looking to modernize aggressively on the organizational level may be able to leapfrog some stages or de-emphasize individual sub-journeys.
Microservices and Organic Federated Growth
Moving from a microservice architecture to a service landscape is a crucial step in transitioning to an organic operating model. This step is often the least understood by technologists as it is driven by organic federated growth, which can be viewed as a bad thing. Because of this, I’ll make this point more concrete with the help of an example.
The figure below shows an exemplary microservice architecture consisting of an application frontend, an API server, and a number of microservices, each with their own data storage, and a few managed services. A cache intermediates some of the services for performance reasons, while workers and a message queue handle asynchronous tasks. The “backend” of the architecture consists of a number of master data stores, an ETL pipeline, and a separate administration application. An event system finally updates each microservice with relevant changes to the master data.
Microservice architectures like this can exist for a long time if the business has only one product. However, in an enterprise, with numerous applications, it typically takes little time for other applications to depend on them, in particular if they prove to be valuable. Moreover, it is not only applications appearing next to the architecture. Other services such as e.g., a mobile gateway or a new partner integration are quickly built on top of it, adding more unforeseen demand on the architecture.
Of course, there is a natural separation between development teams which dictates that any addition to the architecture will be done strictly without changes to, or knowledge by, the original microservice architecture. The new application “tapping” the architecture therefore registers a separate event system to notify its own microservices of any master data updates. Any service built on top of the original microservice architecture will shield itself from its inner workings and future changes through adaptive services such as data access layers, filters or facades.
Subjecting the originally designed microservice architecture to such examples of organic federated growth turns it in effect into a service landscape.
It is this multifaceted blend of various blueprints, teams and business needs that, while being able to adapt perfectly to the agile organization, also makes it difficult to manage.
Organic Architectures in the Wild
So, where do organic architectures exist today? Because enterprises often don’t know how to operate a growing service landscape, most organic architectures are kept under wraps. However, there are three telltale signs that an enterprise is running an organic architecture:
- First, a company with a fast pace of innovation often experiences continuous growth in the layers supporting that innovation. For instance, a cloud service provider introducing new cloud services at a rapid pace will run its backend systems as an organic architecture.
- Similarly, any architecture whose requirements are in constant flux is likely run organically. Examples include systems with a significant and growing set of internal and external clients, for instance, the systems operated by car manufacturers to intermediate and manage access to and from the connected car.
- Finally, an enterprise embarking on a prolonged digital transformation or modernization effort with multiple teams working in parallel will realize that it is essential for them to run their continually changing architecture, organically. Given how continuous modernization is rapidly becoming the norm for leading enterprises, this means that such an enterprise will be increasingly running an organic architecture.
Conversely, a company expecting a long steady state of IT deployments (and thus worrying about “vendor lock-in” with respect to cloud adoption) will largely be hampered in its ability to innovate.
Emergent Behaviors
While organic architecture is ideally suited to adapt to the rapidly changing business needs of an agile organization, its continually evolving nature also implies that it is prone to complex emergent behaviors. These behaviors are conversational, arising from often subtle changes in the communication between services. They are also large-scale and systemic in nature and tend to occur suddenly, in real-time. For instance, an updated deployment may introduce a configuration change that triggers a failover to another availability zone, thus introducing large-scale slowness and incurring additional cost. In this situation, it is paramount that operators have the ability to insert a bulkhead between zones to ensure misconfigurations won’t contravene operational intent.
Complex emergent behaviors at the interaction level pose a fundamentally new challenge to operations groups that must be managed to run organic architecture successfully.
Cloud Traffic Control
The solution for managing these complex emergent behaviors is to use a cloud traffic controller like Glasnostic. Unlike service meshes such as Istio or Linkerd, which aim to simplify service-to-service calls for developers by abstracting away the inherent network intricacies, Glasnostic auto-discovers any services that are interacting in an organic architecture and allows the “mission control” operations team to apply arbitrary measures to remediate behaviors between arbitrary sets of endpoints.
Examples of such measures include typical operational patterns such as ringfencing (“quarantining”) new deployments, inserting bulkheads between architectural partitions, exerting backpressure against certain interactions or shedding load to protect compromised services via circuit breakers and the like. What these operational patterns have in common is that they are operational concerns that are in the purview of the “mission control” level, above those of developers.
Summary
The best architectural style to support an agile enterprise is that of an organic architecture. An organic architecture is a service landscape that consists of digital business capabilities and evolves through organic federated growth.
The changes many enterprises are already undergoing across several levels, from infrastructure to culture, all work together to help them transition from a “traditional,” static operating model to an organic one. On the technology level, the most important transition is that from a service architecture to a service landscape.
Organic architectures are common in environments that are subject to constant change. That change may be driven by a high pace of innovation, a large and changing set of internal or external client applications, a large-scale digital transformation initiative or in general by a prolonged, “continuous” modernization effort.
While organic architecture is ideally suited to support the business demands of the organic enterprise, it is also prone to complex emergent behaviors that are large-scale, dynamic and grounded in interaction patterns. These complex emergent behaviors must be managed for an organic architecture to be successful. Glasnostic manages these behaviors by making them visible and allowing Mission Control to remediate them by applying operational patterns between arbitrary sets of endpoints.
Originally published at glasnostic.com.
