Micro-services are very much essential in the application paradigm. We can not talk about back-end applications without discussing microservices. They are not about the programming language, microservices are the source of truth for the business domains. Indeed they act as the technical implementation of the ubiquitous language derived from Domain-driven design. The paradigm shift that happened over the last decade in transitioning from monolith to microservices has taught many good application development practices.
Unlike the older SOA days, microservices has given freedom of development for the development team working on a specific business domain. Let us see how the modern-day microservices start from development till deployment and go on to change management.
Check – 1) Domain-driven isolation
Once when the business domain is identified, the number of microservices should be identified based on the subdomains. Isolate the services and stick to the identified bounded context. Do not encourage to have inter-services communication. Rather a Domain Graph Service (DGS) along with a resolver and gateway can address the data aggregation between services.
Check – 2) Efficient code run coverage
Every microservice is nothing but a piece of code. Some code in the service may run whenever there is an invocation and some may run only in some specific cases. And some may run only for graceful handling of an error. The simplest goal of microservice is to do one single unit of work and to keep the services lean. Check if the error handling logic can be isolated from the main logic. That way the error handling scenario can be moved to event-driven design.
Check – 3) Cost to run the microservice
Businesses may run local or global. This is crucial to determine the type of cloud, the microservices would run on. Local businesses with local data center which serve the local customers in a region need not worry about CDN deployment worldwide. This can save a huge cost in deployment. Similarly, understanding the microservice and trying to break it as much as possible based on 1) the high-level business logic, and 2) graceful handling of the error scenarios is important. If the latter part can be moved to an event-driven design we can make sure that the bandwidth of the compute is wholly available for the main business logic.
Check – 4) Support lift and shift to any cloud
As we decide to use the existing on-prem or self-maintained infrastructure, and as the businesses grow, we can scale the infra capacity at the on-prem data centers or decide to scale out using the cloud providers. Containerization is a very common solution that many enterprises make as a standard way of packing the applications to operate in scale. The same technique helps to seamlessly move the microservices run on the cloud with very minimal deployment changes.
Check – 5) Determine the multi-cloud vendors
Any data centers may go down at any time. Be it cloud vendors or on-prem data centers, there is no 100% up-time. So how do we handle the business continuity plan during data center downtime? Going multi-cloud can eliminate downtime chances. Running our containerized microservices with one cloud as primary and another cloud as secondary helps here. But what about the cost? The same old blue-green deployments are possible with cloud vendors without paying any cost upfront. The serverless cloud helps in achieving the same.
Check – 6) Choose the cloud offerings
The serverless cloud offers a risk-free operation for businesses without having to worry about the idle time of the compute instances. Nevertheless, every offering seems more attractive, there are still chances to improve it. Not all the services have to run every time in a dedicated instance. Some may run only for specific cases but still may be crucial to the business. How do we handle this? Choose containerization as the model for most frequently ran microservices. On the other hand, take the advantage of managed cloud offerings from cloud vendors and move towards event-driven microservices.
Check – 7) Choose the DevOps
As the microservices are developed by the development team there should an easy way for the team to move it from one stage to another and eventually moving to production without having to do any manual tasks in-between. DevOps is matured than earlier and different vendors provide different solutions. Considering the multi-cloud model, use the on-prem data centers as a CI server to generate the container images and perform unit, functional tests to achieve gated commits. This way the images can be deployed on-prem or any cloud easily. Another thing to consider while using the managed cloud offering is to move towards infrastructure as a code (IaaC).
Check – 8) Federate the microservices
We have used the API gateways as the way to expose the microservices to the client or front-end. However, in this model, any changes to the microservices would impact the client directly. This can be eliminated by abstracting the gateway layer and the microservices with a DGS (Domain graph service), resolver, and a service registry. At a high level, any changes to back-end microservices should not have any impact on the front-end applications. Also, there is no need to coordinate the deployment releases, maintain multiple versions of the endpoint, and so on. In this model, the DGS and the gateways take care of inter-service communication if more than one microservice has to be called to fulfill a client request.
Check – 9) Choose GraphQL for smart API’s
Businesses and enterprises exist as multichannel. Many end up changing the API gateway continuously to support different channels. Worst case, different APIs for different channels. This process is cumbersome and difficult to manage as the services keep on growing. Also difficult for the microservices development team to keep track of backward compatibility with each channel that consumes it. So, how do we handle this? GraphQL is the answer. This is not new. But unlike with its inception where it was seen as a way to query on APIs, GraphQL is seen as a more powerful tool that can even help in completely isolating the front-end channels from the back-end microservice.
Check – 10) Derive the cost of a transaction per customer – Cloud cost of a customer
Yes, the next is to derive the cloud cost of a customer. We are not there yet. But the increasing adoption of the cloud also raises eyebrows on how much cloud bill an enterprise should expect. There is a variety of ways to derive an estimated cost for the future. This is derived in bulk and passed on to the consumer as a standard flat rate. We can not go to the grass-root level of determining the per customer cloud cost. If we can leverage the above techniques and arrive at a cost per transaction or cost per customer, that would greatly help in shaping the future business models of the enterprises.
As I said earlier, microservices gave a lot of freedom for the development team to design the business domains. Because of that, there is no strict checks or guidelines on how you start your microservice and then move on to deploy and manage the services on a production load. Every team can have their way of implementing and managing the services. However, the only goal is to have higher agility, lesser disruption on services, and thereby leading to higher availability of the overall application that results in higher customer satisfaction.
Share your thoughts in the comment!
Happy learning!
Shankar's Blog 