{{announcement.body}}
{{announcement.title}}

Microservices Implementation: Software Stacks and Concepts

DZone 's Guide to

Microservices Implementation: Software Stacks and Concepts

This article on microservices explains which tools and software stacks can be used to resolve specific microservices implementation concerns.

· Microservices Zone ·
Free Resource

In the last article, I had tried to explain how a Spring Boot application can be developed and deployed using Spring Cloud offering and how various cross-cutting concerns (service discovery, circuit breaker, distributed tracing, routing, connector, configurations) can be handled.  

In this article, I will try to put various software stacks available in the market which can be implemented to resolve these concerns and very briefly describe what benefit one can get while choosing a specific tool. 

Pattern Concern Software Stack DETAILS/Features
Observability Audit Spring Envers  
  1. Embedded with Spring boot code
  2. Developer has complete control what to log
  3.  Version upgrade and auto Logging of User and Date
Elastic Search
  1. Scalability and resiliency 
  2. Rest APIs
  3. Security, Management and many more
Distributed Tracing Jaeger
  1. Distributed Tracing Monitoring 
  2. Performance and Latency Optimization
  3. It has a dedicated deployment documentation section.
  4. It leverages open tracing libraries
Zipkin
  1. It is a Cloud Native Computing Foundation project
  2. Various Language supported including C and JAVA
  3. It provide Docker image and Java Program
  4. It supports Popular Framework
App Dynamics
  1. Service to Service tracing capability
  2. End to End tracing, applicable for Mobile Apps
  3. Tracing dashboard is provided  
Application Matrices App Dynamics
  1. Application Performance Monitoring
  2. Server Monitoring 
  3. Database Monitoring
  4. Insights and Analytics

New Relic
  1. Application Performance Monitoring
  2. Server Monitoring 
  3. Database Monitoring
  4. Insights and Analytics
Log aggregation Splunk
  • Analyzes the aggregate of logs from a big service cluster
  • Finds real-time logs and generate reports and alerts for each search
  • It provides enhanced GUI and real-time visibility in dashboard in various formats 
Stack Driver
Log Stash
LogDNA
Data Management Event Source Eventuate
  1. Maintain data consistency using SAGA
  2. Implements Queries using CQRS
  3. Communicate using transnational message
Kafka

Kafka is publish - Subscribe Messaging system which is highly durable, reliable, scalable and performant . 

NoSQL DB There are various NoSQL DB available like MongoDB, Cassendara which can be used
Elastic Search
Domain Event JMS Licensed MQ Based Messaging service
RabbitMQ RabbitMQ is an open source message queuing system that allows us to execute the code of our applications asynchronously.
Active MQ ActiveMQ is an open-source, messaging software which can serve as the backbone for an architecture of distributed applications built upon messaging.  
Database PostGreSQL Open Source Database
Oracle Licensed Database
MySQL Open Source Software Database
MSSQL Microsoft SQL - Licensed
API Call Spring Fiegn Client Embedded with Spring Cloud
RestTemplate Embedded with Spring Framework
Service Discovery
NetFlix Eureka Server Embedded with Spring Cloud
Consule Embedded with Spring Cloud
Environment Variables Read Kubernetes, Cloud or other environment variable
Reliability Circuit Breaker Hystrix Embedded with Spring Cloud
Istio Side car to Micro-Services, deployed along with Service
Deployment Service per VM VM VM can be created using VMWare
Service per container Kubernetes + Docker Container Orchestrator Platform
Open shift Micro-service deployment and management software. Fully managed and managed services exposed
PCF
Server Less Deployment AWS Lambda Server less platform provided by AWS
Google Cloud Functions Google Cloud Functions is Google's serverless compute solution for creating event-driven applications. It serve as a connective layer allowing you to weave logic between Google Cloud Platform (GCP) services by listening for and responding to events.
Azure Function
Service Deployment Platform Docker Swarm + Kubernetes
Elastic Beanstack
Cross Cutting  MS Chasis Spring Boot and Spring Cloud
External Configurations Spring Cloud Config Server
Kubernetes Config Server
API API Gateway Spring Cloud API Gateway
Mule Soft API Gateway
AWS Gateway

I won't explain each and every component and software mentioned above. However, I have provided the link in every software stack, from where you can get more details. The idea was to provide you software which can be leveraged to resolve specific implementation concern. 

There are few other microservice implementation patterns that need to be understood while designing and coding the application and no external tool can help but the concept. I will just highlight those concept below and small write up

  • Decomposition - Idea of having multiple services is to decompose the application in various small services which can be individually developed, deployed and maintained. Ideally, each service should follow SRP (Single Responsibility Principal). Now Its a development team responsibility to understand the functionality well and decompose the application in such a way so that most of changed requirement only affect single service and here CCP (Common Closure Principle) comes into picture. However, challenge is how to decompose the application in various services. This is purely an application team concern how to they define their services. however, few things can be considered 
    • Decompose application by business capabilities
    • Decompose application by Sub domain
    • Self Contained services
    • Common Services

For better understanding of how to define your business service, I would suggest to read "Domain Driven Design" By Roy Fielding.

  • Testing - We have applied micro-services architecture and written numerous small individual services. Now challenge starts for Testers. How to test these services independently ? How to perform End to End testing ?  Following things can be done to resolve these concerns
    • Prepare Test suite that test services in the isolation  
    • Deploy all micro-services and perform end to end testing with all live services
    • Mock other micro-services during unit/integration testing
    • Write the Stubs 

Above mentioned solution has its own advantages and disadvantages and should be               considered while applying one of them. Spring Cloud Contract is another solution which can be used

  • UI Pattern- As we have developed various small micro-services which are developed based by business  capability and they are also responsible for resolving UI concerns. Some of screens require multiple services to display the required data. So, now challenge arises, how to invoke multiple services from UI?  This concern can be resolved two ways 
    • Client Side UI Composition - Every team develops Client Side UI and it is their responsibility to segregate the responsibility in the client side code by assigning job to specific components. Use Frameworks like Angular which supports this pattern (Model, Component, Services, View) . Every page/screen component, aggregates the responses from different services and display the required data in the screen.
    • Server Side Page Composition ( Aggregator ) - Same way, every team who is developing the UI Components, should write server side code for aggregating the responses from different services and send response to UI/Screen for final display 
  • Data Management — It is also another concern which the development team needs to resolve. How are you going to handle your data that is something depends on the development team keeping their services autonomy in the mind. There are various pattern available
    • Database per service - Main forces for choosing this service is that every service should be loosely coupled so that it can be developed, deployed and scaled independently. So keep persistent of data to service and accessible for its API only 
    • Shared database per services - Some data needs to join data owned by multiple services and it adds complexity. To avoid this complexity, use a single database (logically separated) that is shared by multiple services. Every service accesses data owned by other service using local ACID transactions.
    • Command query responsibility segregation - Let's assume you have applied Database per service pattern to implementing your micro-services. As a result there is no easy way to implement queries that join data from multiple services. So how to make this happen. So one solution is a to make a view (read-only) of database which is the replica of production DB which is only responsible for querying the data. The application needs to maintain the replica up to date by subscribing to Domain events. This pattern supports multiple de-normalized views that are scalable. It also improves the separation of concern. Though this model always has complexity, it is good to have Command and Query segregation to improve the performance.
    • SAGA - When you implement Database per service and each service has its own database. Some business transactions require to interact multiple services to complete the transaction. so how would you ensure data consistency in this scenario. there are two ways to implement this patterns. 
      • Choreography - Each transaction publish its domain events that are subscribed by other services to trigger transaction.
      • Orchestration - Orchestrator object prepare chain of events that are going to participate in one transaction and maintain the data consistency

There are various design patterns. However, these are few which I wanted to highlight as they are the most important ones.

That's it for this article. In the next article, we'll tackle microservices testing in detail. 

Topics:
microservices, microservices implementation, microservices tools, software stack, tools

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}