Disclaimer: This article is based on my professional experience. I acknowledge the trademarks and IPs owned by others. This post is based on James Lewis and Martin Fowler Microservices article - https://martinfowler.com/articles/microservices.html.
- Overview
This article describes few experiences on solution strategy for Microservices and DevOps with webMethods Integration platform.
- Introduction
The first question everyone would ask on the context of Microservices Architecture(MSA) would be "What are Microservices and why does anyone wants to move towards MSA?" Well there are different definitions like SOA done right, loosely coupled SOA with bounded context, small autonomous services that work together. It has been always easy for me to explain about this with the below article from Sander, and if you are a beginner you would enjoy reading this:
Well this is not something new for Software Engineering - if you see below linux command we are doing something very similar.
ps -ef | grep java > result.txt
In this example we are saving the result to a file of two different chained commands (micro commands).
In simple words Microservices means - do one thing and do it right.
- Assessment
It's a known fact that everyone wants to assess the needs of customer before proposing a conceptual architecture. Below are few areas where I gave more importance for the enagements I have worked on.
Questionaire on needs of the Organization:
Questionaire on needs of the Technology:
- Layers & Needs of Microservices
Is it really enough of knowing the Integration and Containeraization for MSA? Well It turns out to be not. It needs to have good understanding on Layers and needs of Microservices. There is a very good article written by Susan Fowler - https://www.susanjfowler.com/blog/2016/12/18/the-four-layers-of-microservice-architecture on this.
There is an another article from Bilgin Ibryam on the similar lines that explains the needs of MSA - https://thenewstack.io/introducing-microservices-hierarchy-needs/.
- Implementation Governence - Logical Design
Most of the webMethods consultants would raise a question on Implementation Governance with MSA. Most of the organizations have Microservices in their strategic roadmap and they would need the current ongoing developements also to follow the Governance that would enable them to easily move towards MSA when they are ready. So, the important question - What should be the right way for implementing a Microservice?
Well the answer is very simple - follow the TDD (Test Driven Developement). Use Unit Test Framework (formerly known as wMTestSuite) for designing your test cases before you start your developement. I have always been great fan of Martin Fowler and his articles, please read an article about TDD and Microservices from Toby Clemson - https://martinfowler.com/articles/microservice-testing/#anatomy-connections.
Layered Implementation:
Protocol Layer: All the consumer specific implementations like Protocol Handlers (e.g. header extractions, content negotiations etc.) implemented in this layer. By having this dedicated layer, developers can continue to concentrate writing the domain specific implementation in the lower layers. This will also allow having different consumer specific implementations (e.g. REST, JMS, SOAP, TCP etc.)
Service Layer: All the domain specific implementations for validation, orchestration, choreography with the provider systems or system micro services are implemented in this layer. This layer can use the Domain specific objects created in the docs folder (is called Domain Layer in the design diagrams). Any invocations to the backend systems (with JDBC, TCP adapters etc.) should be implemented via wrapper layer (repository layer) with a generic contract. This will help to makes the changes minimal within the Microservices in case of any changes in the provider systems.
Provider Layer: All the invocations to the provider systems (e.g. SOAP connectors, JDBC, TCP Adapters, connections) are referred to as Provider layer.
- Messaging & In-Memory Data Grid:
If you are from a SOA/API background then if you would know that every service should emit events. Microservices are also being a flavour of SOA - would also keep on emiting events with multiple contexts. Those contexts can be Audit logs, Aysnchronous Service Communication and so on. You would need a strong messaging bus to process these evens. It is a known fact that MSA can contain heterogenous systems and would require a good messaging bus that allows communication with multiple protocols like native pub-sub (webMethods clients), JMS, AMQP, MQTT, WebSockets, NSP/NHP. Universal Messaging from webMethods is a good fit in these kind of usecases.
Every organization is consists of legacy back-end systems which can neither be replaced or will work faster as expected by customer. It is very a common usecase to bring in IMDG layer to make the microservices to work faster. Terracotta BigMemory is one of the best offering from SoftwareAG stack.
- Running webMethods Microservices in Production
Building a Microservice != Running Microservice
Let me make it clear about the above statement - this is true for any microservice (either it is implemented with wM platform or else on any other opensource technology/platform). Because microservices runtime has few requirments that we have seen as layers/needs in the above sections.
- Service Registry
When you think of MSA that went live - there will be minimum of 50 microservices running in at any point of time and managing them is not really a cake walk. One of the concerns will be about where the microservice is actually running? What I mean is microservices will be running in a container, can run on any available host (we will see this in the sample deployment architecture in the coming sections) and it is not easy to find endpoints of the microservice. So what we need is a dedicated software that maintains the details of the microservice endpoints. This is known as service registry. You might have came across Netflix Eureka and Consul by Hashicorp when you are reading about MSA.
If any container orchestration(like Kubernetes/Docker Swarm) in MSA then you would need to go for Self Registration with consul/Eurekha otherwise out of the box service mananger would handle the service end point registration.
- Service Discovery
Now, how does the client discovers this microservice end point? there are few cases where clients would go for client side load balancers like Netflix Ribbon which is upto the clients consuming the microservices. But on the server side based on the Service Manager type a different discivery mechanism can be followed.
Few of you may ask why do we need an API Gateway here? Yes, we do need an API Gateway and in fact I would strongly recommend an API Gateway for MSA. Because when anyone implements a microservice they would never think of Authentication/Authorization (Basic/Token Based/Limited Access/SSO), Intelligent Routing, Traffic Optimizations (Rate limiting, Service result caching), Transformations, Service consumption metrics (for Metering & Billing), Circuit Breakers, Mocking etc. This is where API Gateway comes in. webMethods API Gateway comes up with these features and makes it very easy to enable these policies on the Gateway.
- Microservice Configurations
It is a common requirement for every Microservice to point to different provider systems and every time the Microservice is being promoted to higher environments there might be a need to point the Microservice to respective provider systems. These configurations also have to be implemented as code and packaged with the Microservice package. As configuration is written as source code, you can use all best development practices to optimize it. Below are few examples for Microservice configurations.
These configurations can be dynamically injected at run-time everytime the microsrvice is started without rebuilding a new microservice just for these configuration changes. The new offering from SoftwareAG stack webMethods Microservices Runtime (introduced as webMethods Microservice Container from 10.1 version) supports these configurations to be dynamically injected as Docker environment variables.
- Microservices - Classifications
We discussed about the number of microservices that might be running in Production in MSA. It is equally important to classify the requirements into type of microservice and identify if the microservice already exists for such requirement to aviod redundancy. Please note that with microservices redundant deployments are also allowed so that they can be independently managed. Just like API classification for API managment Microservices also fall under similar classification.
- Microservices are not always the same as APIs
Since this article refers microservices as a flavor of SOA/APIs in this article, there might be an impression that Microservices are same as APIs. But it is not true. Every API can be a microservice but not every microservice can be an API. Let us take an example to explain this. Let us assume that there is a business functionality which loads data from legacy systems to upstream systems and its a batch job that runs every day at 12 AM. This does not expose any functionality to any other system but just loads the data. This means this functionality is definetely not an API.
In Monolithic way we would have deployed this business functionality on any server and scheduled it to run at 12 AM. By doing this - the server would load the functionality allocating some resources to this and block those resources all the time from other capabilities that are deployed on the server. In MSA - this can be packaged as a microservice and scheduled to only run at 12AM and stop once it completes it's job. By doing this we will save the resouces and no other capabilities gets impacted if there is an issue with the batch processing.
- DevOps
We all know how important is to have Automation & Monitoring in place with MSA. Microservices needs alot of concentration on - Open Container Initiative (OCI) - https://www.opencontainers.org/, Open API Initiative - https://www.openapis.org/, Open Tracing Initiative (Distributed Tracing) - http://opentracing.io/ under this category. There are other aspects like container resource consumption, server resource consumption, log aggregation under monitoring. For deployments containers and container orchestration(Docker, Kubernetes, Docker Swarm).So we would need another community article on this (if you like this article 
). Please look forward to it.
- Deployment Architecture
If you have a look at Netflix deployment architecture - https://www.nirmata.com/2014/08/13/getting-started-with-microservices-using-netflix-oss-docker/
If you try to read other MSA usecases like Uber/Amazon - the deployment architecture won't differ much other than technologies that they are using.
Below would be something with webMethods Integration Platform and it does adds alot of value as you have most of the capabilities that you need for MSA are available out of the box.
- Conclusion
This blog article is written with the current view of Integration and Microservices usecases in MSA and is purely based on the professional experience of few colleagues. In future this could be revised as required.
Many thanks to Sahana MS (https://www.linkedin.com/in/sahana-ms-130000a3/) for the continued support in compiling this Article.