The Road to
Microservice Architecture

Published:
Genre: Non-Fiction: Technology
Available Formats: eBook and Paperback
Author: Raymond Pairan

Synopsis

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, freedom, 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.

For instance, an Enterprise Architect/Thought Leader within an Agile/Open Source horizontally defined organizational power structure will be someone who has the business, marketing, technical, inspirational, entrepreneurial, and innovative abilities to help guide an organization's fused business and technical direction.

That's right, the large lethargic organization will eventually shift from a hierarchical to a horizontal power structure with the resulting outcome being the elimination of many useless layers of bureaucracy and procedures. We are moving from the age of the monolith both technical and business into a world of nimble employee empowered organizations.

Essentially, the new Enterprise Architect or whatever we end up calling this position will be a thought leader for the firm, having the insight across many disciplines to contemplatively drive the company into the 21st Century. In a flattened firm all the previously siloed departments like marketing, finance, leadership, technology, and... are united into cross discipline teams similar to how we utilize Agile in technology. The entire firm is Agilized - not a word yet but maybe it should be.

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.

Table of Contents

About the Author

Ray Pairan Jr is currently a Senior Technology Architect for the Infosys FSSTAR Digital Center of Excellence. Over his more than 22 years of technology experience as a Senior Software Engineer and Lead Engineer he has architected many systems including a System-of-Systems Army integrated network for DARPA’s Future Combat Systems. Our modern technology adventure owes its beginnings to some of the early technologies he extensively helped architect and develop.

Early Years

Falling into the profession of what was then called programming my skills and interests were tickled at a very early age by an after school class in FORTRAN. Miami Killian Senior High back in the mid-1970s was situated within an upper-middle class neighborhood in what was termed South Dade - geographically the Dade county metropolis dominated by Miami, Florida.
You have to understand that way back when dinosaurs roamed free across unfenced villages programming was considered a far-out fringe occupation that engaged super-brainy types who worked for IBM and a few other very large computer companies. Sometimes the U.S. military through its network of military contractors like Lockheed would also grab those who had the requisite knowledge in technology. So for a high-school to setup a large room with many large green bar printer terminals linked to the school district’s IBM mainframe just to teach programming to a bunch of math wizards was quite the leap off the deep end....

Welcome Back the Change-Agents

Autocratic organizational structures with their integrated chains of command mimicked in the software processes, tools, and tightly coupled outcomes of synchronized production are diametrically contrary to the dynamic and ubiquitous freedom of expression of the billions of individuals now using the Internet. Our organizational structures are therefore not in sync with a more enlightened freedom and interflow of innovation and expression streaming across the Internet.
In their attempt to stifle intellectual expression, many firms locked down their developers in even more stringent over the top processes ow fully integrated into the tools they were using to design and code applications. There just was no letup by the process hounds fresh on the trail to more fame and fortune. No one even thought to ask the technologists doing the work how this would impact their productivity, innovativeness, and especially the quality of the systems they were supposed to produce like so many widgets popping off a production line....

The Open Source Revolt

Progress is a byproduct of built up historical imperatives. Epochal dynamism that shifts humankind into new modalities is a flood of progressiveness finally allowed free expression and general support. Once the Agile methodology and the associated empowerment of former production oriented workers were let loose there would be no stopping its spread - especially into technology startups hankering for ubiquitous communication pathways and supercharged idea generation.
Production dazed technology workers; the cubicle deadened developers getting a taste of an enlightened business subculture in Agile started dreaming of charting their own destinies with other techies. By expanding the Agile processes throughout an entire organization not centered upon profit - at least not initially - these lovers of technology could experience the thrill of creating something where nothing existed before, they could dare to dream big dreams....

What Is Inspiring the Evolution of a Microservice Architecture Orientation?

Shifts in paradigms never originate from a single event but are the result of multiple changes merged and transformed in environments conducive to their insights. Internal and external cultural ground must be fertile enough to support the monumental reorganizing of how human being’s comprehend their world. We never end up substantially reworking something just because it entails some emotional stimulus. Dramatic changes in all spheres of human endeavor occur because of a need to fix something — a desire to make our lives easier or more rationally ordered.
Similarly, the Microservice Architecture thrust did not happen because someone decided they just wanted to disrupt the proverbial 'apple cart'. On the contrary, microservice architectural insights were the result of the dysfunctionality of corporation hierarchical command structures that had been infused into technology....

Microservice Architecture Is an Extension of “Open Source” Neighborhood Philosophy

Microservice Architecture encompasses not just the technical aspects of designing a resilient, adaptable, secure, and scalable framework but also ensures its successful implementation by infusing it within an organizational structure that embraces the microservice philosophical paradigm. Simply providing an organization with the technical understanding of what comprises a Microservice Architecture and all the base technologies that can be utilized is a recipe for failure....

Essential to the Success of a Microservice Architecture


...

Microservice API Platform Management/Gateway (MAPI-PMG)

Bona-fide MAPI-PMG orchestration management gateways like Kong and Tyk were built not by control oriented but an “Open Source” flat startup free spirited culture that values cooperation and collaboration. That is why Kong and Tyk do not send their spider webs out to ensnare zombie services, subsystems, and processes to be micromanaged by some complex yet fragile central control core....

Antifragile Characteristics of Microservice Architecture

Having many components or parts, a Microservice Architecture maximizes the antifragility of the entire structure. Microservice Architecture inherently enhances system noise due to the many microservice interactions. This increased noise reduces the fragility of a Microservice Architecture and optimizes its antifragility with environmental stressors that tug and pull at the system in many different ways allowing the system to get stronger....

Service Mesh

Independence of each microservice in a Microservice Architecture is the primary objective needed to maintain flexible continuous change and the ability of this design pattern to easily scale. Objectives are not hard fast rigid constraints, in a world that continually changes and adapts too many stressors and triggers we cannot be absolutely certain that when building a real world system that there will never be the case when two microservices will need to pass messages....

Enterprise Service Bus (ESB) Is Not a MAPI-PMG

There seems to be quite a bit of confusion surrounding an MAPI-PMG. Some believe that an Enterprise Service Bus (ESB) like MuleSoft, especially given how this framework has been recently marketed, has now been miraculously transformed into a modern MAPI-PMG microservice orchestration management/gateway. All ESBs, especially MuleSoft are tightly bound distributed monoliths that glue all the components, dumb services, and disparate subsystems of a tightly coupled system to its central control architecture. Just stay away from these beasts like a werewolf when there is a full moon....

How is a Microservice Architecture Different from a Monolith

Centralization, absolute control, and the always increasing size of the Monolith are radically different from the decentralized and totally decoupled Microservice Architecture. Spending most of my early career trying to create crystal palaces, pure monoliths that most of us dinosaur ranchers believed could anticipate every eventuality or stressor that the real world would throw at them, every state, either resting, transition, and that perfect never achieved state, let me say unequivocally that this is a fool’s waste of time. We humans, all our imperfections, in an imperfect, but very stressor adapted untidy world are wholly incapable of creating anything perfect and that is especially true when it comes to maintaining or managing any system state effectively....

Using Technology Archimetrics to Contrast Microservice Architecture from a Monolith

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....

Decomposing a Monolith

The entire conceptual origin of a Microservice Architecture design pattern came from the need to logically breakup unwieldy, unmanageable, and inflexible, process constrained, and tightly coupled monoliths. These beasts were infused into overly complex frameworks like Java EE and .NET that also had application servers requiring constant maintenance and technical handholding....

Deploying a Microservice Architecture on the Cloud

Along with the unreality that ESB SOA is somehow a Microservice Architecture another equally disturbing misconception is that a Microservice Architecture is integrally tied to the Cloud. Cloud technologies like AWS, Azure, and a host of others are distinct and separate from a Microservice Architecture. Whether an organization decides to utilize the services of a Cloud for PaaS, IaaS, or SaaS is a mutually exclusive decision distinct from whether to use or not use a Microservice Architecture....

Microservice Architecture Security

Obfuscating the backend microservices in front of a reverse proxy like a Microservice API Platform Management/Gateway (MAPI-PMG) similar to Kong and Tyk goes a long way in securing microservices that prior to the advent of a MAPI-PMG were externally exposed on the web. The Open Banking legislation in Europe and the UK mandates that all banks provide information that can be used by customers and Fintechs (operating as 3rd party aggregators for customers) to enhance the online banking experience....

There is nothing more desired by an author than hearing from his readers. Please contact me at...
ray@tomorrowwedancetofreedom.org
raypairan@gmail.com
Durant, Iowa
830-387-8634
Author Page on Amazon
Author Page on Goodreads
LinkedIn
Facebook
Author Page on Facebook