The Opinionated Hybrid Stack Microservices

using Microservice Architecture Responsibly 

The Hype, Promises and Reality

One of the challenges in our modern technological world is separating the “Hype” from the “Reality” of New Technologies.

The “Geek Appeal” of new architectures and processes seems to overshadow the real “Business Value” that new ideas claim to bring to the table most of the time.

Business Drives Technology …

… Technology Does Not Drive Business

Technology in the Global Business Environment has value only when it is a Practical Solution to a Business Requirement as it is managed throughout the entire Software Development Life Cycle (SDLC) of the deployed Business Solution.

Embracing new ideas must be tempered with the reality of the Cost of Maintaining, Managing and Upgrading the application.

Do not be unduly influenced by the Hype and Promises of popular new ideas without vigilant due diligence

This “Pulp Fiction” satire image might be a little drastic but the misuse and improper implementation of Microservices has caused a very real dislike for an architecture that does have a place in the Business Technological Ecosystem.

Guidelines for Microservice Architecture

The Delivery Guidelines for World Class Business Solutions are structure through the Pillars of Object Oriented Programming and  defined with Design Principles and Design Patterns.

These OOP Principles and Patterns are enforced by defined Code Standards and managed using Development Code Reviews to ensure Source Code Quality.

A Successful Client Engagement must have
all of Delivery Guidelines
Tailored to the
Client’s Current Corporate Culture

This development series is based on Opinionated Technology Stacks.

The Microservice Architectures in this post are predicated on compliance with the following Delivery Guidelines:

• The OOP Pillars: Encapsulation and Data Hiding though Abstractions

• The S.O.L.I.D. Design Principles: Single Responsibility Principle and the Open Closed Principle 

• The Best Practice Design Principles: DRY Principle and the CQS Principle 

• Domain Driven Design: The Bounded Context Aggregate Root Entities

Complexities are Introduced with Microservices.
The “Pros and Cons” of Managing
these Complexity throughout the
Software Development Life Cycle must be
Diligently Assessed and Justified

Criteria for a Microservice Architecture

The Tech Stack Series using a Hybrid .NET Technology Stack that uses a WebAPI Layer sitting on top of a Domain Driven Design Model Driven Design domain layer.

The Microservices acts as an Isolation Abstraction Layer between the C# .NET Stack and the JavaScript MEAN.js Stack.

The clearly defined Bounded Contexts of the Technology Domain Model creates the DDD Aggregate Root Entities.

These Aggregate Root Entities have Global Identity

They can be created and destroyed, at will, as a collection of other Entities and Value Objects that only have Global Identity when in the context of an Aggregate Root Entity Collection.

Each Bounded Context exists independently
from each other within their own solution module

This architectural isolation allows these Aggregate Root Entities to mature over time completely decoupled and independent from other Aggregate Roots.

This Architecture Model is Perfect for Managing
access to the Root Entities through the same
Decoupled philosophical concept:

THE TECHNOLOGY STACK MICROSERVICE

Pros and Cons of Microservices

The Definition of Microservices:

Microservices is a software architecture style, in which complex applications are
 composed of small, independent processes communicating with each other using language-agnostic APIs

These services are small, highly decoupled
and focus on doing smaller tasks

Microservices are detailed in a Martin Fowler’s Detail Blog

The Perceived Benefits:

• Each Microservice is relatively small
• Easier for a developer to understand
• The IDE is faster making developers more productive
• The web container starts faster, which makes developers more productive, and speeds up deployments
• Each service can be deployed independently of other services – easier to deploy new versions of services frequently
• Easier to scale development. It enables you to organize the development effort around multiple teams. Each (two pizza) team is responsible a single service. Each team can develop, deploy and scale their service independently of all of the other teams.
• Improved fault isolation. For example, if there is a memory leak in one service then only that service will be affected. The other services will continue to handle requests. In comparison, one misbehaving component of a monolithic architecture can bring down the entire system.
• Each service can be developed and deployed independently
• Eliminates any long-term commitment to a technology stack

The Possible Drawbacks:

• Developers must deal with the additional complexity of creating a distributed system.
• Developer tools/IDEs are oriented on building monolithic applications and don’t provide explicit support for developing distributed applications.
• Testing is more difficult
• Developers must implement the inter-service communication mechanism.
• Implementing use cases that span multiple services without using distributed transactions can be difficult
• Implementing use cases that span multiple services requires careful coordination between the teams
• Deployment and production complexity
• Increased memory consumption

Additional Considerations

The Microservices architecture replaces N monolithic application instances with N x M Services instances.

If each service runs in its own Virtual Machine, which is usually necessary to isolate the instances, then there is the overhead of M times as many Virtual Machine,run-times.

Moreover, if each service runs on its own Virtual Machine, like an Amazon EC2 instance, as is the case at Netflix, the overhead is even higher.

Concluding Thoughts

The opinionated use of the term Microservice in the context of the Technology Stack Domain is much simpler than a full implementation described above and in the Martin Fowler’s Blog.

These Microservices encapsulates access to the isolated Domain Driven Design Bounded Context Aggregate Root Entity, as a Globally Identified Composite Object,
that is managed by a MongoDB Document Distributed Cache System.

The API Service Endpoints are Isolated Encapsulated WebAPI Services that can be managed throughout the Software Development Life Cycle (SDLC) as a Companion Component Module to the Technology Domain Model.

Both the Aggregate Root Entities and the supporting Domain Entity Microservice can be created, destroyed and even replaced at anytime during the SDLC without any residual effects from any other Isolated Technology Domain Entity.

The Tech Stack Microservice is a small, easily serviceable
Component of the .NET Hybrid Technology Stack
using the JSON Hypermedia Content Type
without any knowledge of the Client’s
intended use of the JSON Hypermedia delivered

Wisdom Pearl # 121 – Work Quality Concept

Your Work is Only as Good

… As How it is Perceived by the Next Person who Touches It

Positive Acceptance of your Work is Your Preeminent Responsibility