Reactive healthcare microservices unleash business scale

Is your organization growing rapidly? Anticipating challenges with scale? It might be time to move from a monolithic application structure to a polylithic structure with reactive microservices.

Monolithic (single structure) and polylithic (multi-structure) applications each offer advantages, depending on the stage of an organization’s life. Eventually, organizations will reach a point where monolithic application structures restrict productivity and limit scale. The solution is the exploration of polylithic application structures, commonly referred to as microservices.

When the complexity is high

Why do we use microservices? Microservices are used when the complexity of a system is too large to manage as a monolithic application. If the application can’t be reasonably managed as a single application, in most cases, polylithic architecture structures are the most efficient. In a recent blog post, Martin Fowler outlined three reasons microservices are the answer for organizations with rapid growth.

  1. Reduced baggage: For complex systems, the additional overhead of microservices decreases overall complexity.
  2. Improvements in productivity: The more complex the system, the more productivity is impacted.
  3. Reduced attenuation: Productivity variability is narrowed when monolithic applications are decoupled.

For complex systems, the reduced baggage required to manage microservices improves productivity. As the complexity of the base system increases, productivity falls quickly without using microservices. Also, as the demand for scale magnifies, the application becomes bloated with complexity. The explosive need for scale raises the urgency to realize productivity gains. These gains are accelerated by the decreased coupling of microservices, that limit productivity attenuation. As a result, the environment becomes more stable, and the release cadence improves.

Conway’s Law

In his book The Mythical Man-Month: Essays on Software Engineering, Fred Brooks popularized the phrase “Adding manpower to a late software project makes it later.” We all understand that adding substantial resources to make aggressive software development milestones when changing monolithic applications rarely works. If most large single applications do have a degree of modularity, then why do these applications still fail to scale? It could be it’s not about the application at all. Applications are built around organizational communication structures or business processes. If those processes are efficient, guess what? The application functions well. But if business processes are ineffective, software applications mimic the inefficient processes.

Brooks’ experience leading development for the OS/360 at IBM led to many of his observations. Another comment Brooks made was on a 1967 paper written by Melvin Conway, a computer scientist and hacker. The paper was rejected by the Harvard Business Review and later accepted by Datamation, a popular IT publication at the time. Conway’s thesis was that “any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.” Brooks coined the term “Conway’s Law” in his book, and the name stuck.

Conway’s Law is this: “Organizations which design systems… are constrained to produce systems which are copies of the communication structures of these organizations.”

Monolithic types

Monoliths are large blocks of stone used to build structures or monuments. These colossal stones were used by ancient civilizations with primitive technology. Cueva de Menga in Antequera, Spain, is a dolmen made of megaliths and weighed up to 180 tons, built in 2500 BC. The Kerloas menhir often called the “standing stone” is located in Brittany, France, with the latest structure weighing in at 150 tons.

Similarly, monolithic applications are single-tiered structures where the user interface and code are combined into a single program from a single platform. Monolithic applications are easier to debug and test. Easily accessible coarse-grained application security, managed as one application, makes authentication and authorization straightforward. Collectively, these benefits produce applications that are faster to plan and quicker to design. However, eventually monolithic applications that were once efficient and produced near-flawless releases become repositories of technical debt. As vendor-partner integration become a minimum requirement for growth, security modules don’t have the granularity needed to expose particulars of functionality. The all-or-nothing access model doesn’t have a long life span. At this point, we turn to polylithic application types or microservices.

Polylithic types

There are benefits to managing independent sections of a core application as opposed maintaining all functionality as one large application. In his book The Art of UNIX Programming, Eric Raymond outlined the 17 Unix rules that align to polylithic application types. The design rules Raymond identifies also have applicability to the deployment of microservices.

The Rule of Modularity stresses that programs are built from simple parts, so problems are local. The Rule of Clarity asks developers to write for developers, not for computers, making code easier to read. The Rule of Composition encourages developers to divide monolithic applications into small, simple programs to aid with simplicity. The Rule of Separation instructs developers to divide the program from the policy (front-end interface and back-end interface). The Rule of Simplicity aims to discourage complete but beautify complexities, which in practice become bug-ridden programs. The Rule of Parsimony directly states, “don’t write big programs,” which limits final waste (products built but not used). The Rule of Transparency reduces redundancy by designing pieces that other developers can see and access. The Rule of Robustness ensures that programs can undergo stress and therefore output reliable products. The Rule of Presentation has developers when necessary make the data more complicated rather than injecting additional procedural logic into programs. The Rule of Least Surprise means to build on expected logic — e.g. the “+” sign should always mean addition in a calculator program. The Rule of Silence attempts to keep developer output limited to prevent unnecessary parsing through output. The Rule of Repair suggests that programs should “fail noisily” and therefore be easy to fix. The Rule of Economy has developers value a developer’s time, over machine time, ideally reducing project costs. The Rule of Generation focuses on building code from abstract high-level programs, to limit writing code by hand thereby reducing errors. The Rule of Optimization suggests designers should prototype before polishing any code, preventing excessive time spent pursuing marginal gains. The Rule of Diversity supports designing programs to be leveraged in ways other than those initially intended by the developers. The Rule of Extensibility requests developers to build programs where functionality can be extended, stretching the life span of programs and improving utility.

The design rules created for Unix have many similarities with the microservice layout. The evolution from monolithic kernel-based operating systems to microkernel-based operating systems provided the near-minimum amount of software that could provide mechanisms that when implement together form an operating system. Traits such as correctness, consistency and completeness were applied to Unix and microkernels, and today they apply to microservices.

The Reactive Manifesto

Organizations working in different domains were in search of patterns to build software that looked similar. The need for portability resulted in the Reactive Manifesto, which states that systems built as reactive systems are more flexible. Four principles govern reactive systems:

  1. Responsive: timely responses driving usability and utility.
  2. Resilient: responsiveness even during failure (replication, containment, isolation and delegation).
  3. Elastic: responsive under varying workloads (dynamic resource) achieving elasticity.
  4. Message-driven: explicit message-passing to enable load management, elasticity, and flow control.

Systems that are responsive, resilient, elastic and message-driven are reactive systems. Microservices is a particular approach for service-oriented architectures used to build flexible, independently deployable software systems. By applying the principles of reactive systems to microservices, we create reactive microservices. These easy-to-replace services, organized around capabilities, can be implemented in a range of programming languages, databases, hardware and software environments.

Is a microservice strategy on your road map? Evaluate when it’s the right time for your organization to move from a monolithic to a polylithic application structure. Enabling reactive healthcare microservices might be the answer. The business will thank you.

Previous articleMicroservice ecosystems for healthcare
Next articleMonolithic vs. microservice architectures for innovation
Peter is a technology executive with over 20 years of experience, dedicated to driving innovation, digital transformation, leadership, and data in business. He helps organizations connect strategy to execution to maximize company performance. He has been recognized for Digital Innovation by CIO 100, MIT Sloan, Computerworld, and the Project Management Institute. As Managing Director at OROCA Innovations, Peter leads the CXO advisory services practice, driving digital strategies. Peter was honored as an MIT Sloan CIO Leadership Award Finalist in 2015 and is a regular contributor to on innovation. Peter has led businesses through complex changes, including the adoption of data-first approaches for portfolio management, lean six sigma for operational excellence, departmental transformations, process improvements, maximizing team performance, designing new IT operating models, digitizing platforms, leading large-scale mission-critical technology deployments, product management, agile methodologies, and building high-performance teams. As Chief Information Officer, Peter was responsible for Connecticut’s Health Insurance Exchange’s (HIX) industry-leading digital platform transforming consumerism and retail-oriented services for the health insurance industry. Peter championed the Connecticut marketplace digital implementation with a transformational cloud-based SaaS platform and mobile application recognized as a 2014 PMI Project of the Year Award finalist, CIO 100, and awards for best digital services, API, and platform. He also received a lifetime achievement award for leadership and digital transformation, honored as a 2016 Computerworld Premier 100 IT Leader. Peter is the author of Learning Intelligence: Expand Thinking. Absorb Alternative. Unlock Possibilities (2017), which Marshall Goldsmith, author of the New York Times No. 1 bestseller Triggers, calls "a must-read for any leader wanting to compete in the innovation-powered landscape of today." Peter also authored The Power of Blockchain for Healthcare: How Blockchain Will Ignite The Future of Healthcare (2017), the first book to explore the vast opportunities for blockchain to transform the patient experience. Peter has a B.S. in C.I.S from Bentley University and an MBA from Quinnipiac University, where he graduated Summa Cum Laude. He earned his PMP® in 2001 and is a certified Six Sigma Master Black Belt, Masters in Business Relationship Management (MBRM) and Certified Scrum Master. As a Commercial Rated Aviation Pilot and Master Scuba Diver, Peter understands first hand, how to anticipate change and lead boldly.