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.
Join the DZone community and get the full member experience.Join For Free
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.
|Application Matrices||App Dynamics||
|Data Management||Event Source||Eventuate||
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|
|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|
|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|
|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.
|Service Deployment Platform||Docker Swarm + Kubernetes|
|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|
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.
Opinions expressed by DZone contributors are their own.