The Road To Microservice Architecture

Microservices cannot be simply ‘wired up’ with some basic technical knowledge about what constitutes a Microservice Architecture. There is more to a Microservice Architecture than developing isolated and unique services with a blueprint like set of architectural artifacts. Successfully understanding microservices requires a paradigm shift no less radical than moving from a procedural to an object oriented programming language. Microservice Architecture is not just technical but also a new business philosophy rooted in antifragility, employee empowerment, and flattened power structures.

This book will take you on an expedition to a yet to be fully explored ‘planet’ with a divergent philosophical underpinning that is completely alien to some technologists. Our voyage of discovery will be traveling through a landscape that is unrecognizable. If it were not for the historical map that explains the origins of this empowering technical perspective most would be disoriented at the outset of the voyage.

New conceptualizations are found throughout the book.

Each microservice is synonymous with an individual. Both the microservice and an individual are unique self-contained and expressive units best integrated within an orchestrated horizontal interface. From the interactions of many individuals or microservices emerges a concerted set of behaviors that are deterministic or nondeterministic depending upon a multiplicity of environmental interactions. Orchestration is not autocratic rule, but an adaptable and suggestive set of goals and outcomes that individuals and microservices may resolve to during their interactions with their environments. Overt control is out. Cooperative group goal achievement is in. Orchestration can be achieved in a Microservice Architecture with a Microservice API Platform Management/Gateway (MAPI-PMG) comprised of an API Manager, API Gateway, Developer Portal, and Administrative Portal. The MAPI-PMG can effectively coordinate microservices into meaningful combined system behaviors. Like the laws of our human world that keep us from straying off onto pathways that may spawn emergent group and individual behaviors that could be self-destructive a MAPI-PMG keeps the microservices coordinated - orchestrated towards achieving behaviors consistent with the requirements of the application. Orchestration of micro units whether human or artificial like microservices must still adhere to some form of minimal process restraints or else anarchy is the unintended outcome. Granted, over blown processes, those that strap us and our systems down so tightly that nothing positive can be achieved are not desired. Light, loose, broad goals and outcomes can be best realized in small groups that meet regularly without the need to maintain burdensome records or adhere to a ritualistic agenda. Cooperative, iterative, collaborative, openly progressive, and Agile process work environments that value the individual over the corporate entity are typically the most successful implementing a Microservice Architecture.

The term that I use for my new analysis of system and technical architecture dynamics is Technical Archimetrics. Prefacing Archimetrics with the word technical is essential because this term is also used in the brick and mortar architectural profession. Not satisfied with simple descriptions of various technical architectural states my intention is to quantify and qualify these changes with intuitive linear diagrams. Let us first look at what happens when the decision is made to move from a Monolith or ESB SOA Architecture to a Microservice Architecture. Microservice Architecture having many single purpose, decentralized, autonomous, replaceable, small, and simple microservices enables a higher change velocity as a function of time than a multipurpose, centralized, dependent, not easily refactored or replaced, large, and complex monolith.As change velocity increases, system production safety decreases and the probability of production errors or malfunctions also increase. Microservice Architecture only operates at a higher level of system production safety as a function of change velocity when DevOps, operations automation, CD, CI, CDeploy, Agile, and all the requisite changes have been made organization wide to make a Microservice Architecture a success. The fewer the components that a system has and the dependence of each component upon other components or what can be called a Controller Design Pattern where each component is subservient to a core or central logic layer the more monolith the system. Gradation in monolith characteristics - a continuum from non-monolith to absolute monolith is a more realistic measure of system centralization, inter-component dependency, and the flexibility or adaptability of a system to change - its resiliency and antifragility. The monolithic characteristics of a system are a function of the number of independent components that a system processes and their overall autonomy and independence.

Traveling to this new land of freedom requires that explorers not take any neat and tidy preconceptions with them - come along without any baggage. This book will challenge how you view technology to the core of your being. When you have finished this journey all that you believe and cherish from a technical standpoint will be cast aside.