The Opinionated Hybrid Stack Microservices
using Microservice Architecture Responsibly
|The Hype||The Guidelines||The Criteria||Pros/Cons|
|Select a content section anchor button and then use the Browser’s back button to return to selections|
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 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
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.
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
The following two tabs change content below.
I am a Principal Architect at Liquid Hub in the Philadelphia area specializing in Agile Practices as a Certified Scrum Master (CSM). I use Test Driven Development (TDD) and Acceptance Test Driven Development (ATDD) with Behavior Driven Development (BDD) as my bridge to Agile User Stories Acceptance Criteria in a Domain Driven Design (DDD) implementing true RESTful services