Digital transformation utilizing microservices & Java-based APIs:
Microservices have become one of the enablers in the digital transformation services journey as it is always focused and built on Business Need" and Single Responsibility. Microservices pattern enables scalability, speed, efficiency, and agility because of De-centralized API.
De-centralized data and independently deployable, manageable, scalable. Also, inter-communication between Microservices is easily achievable through patterns – HTTP REST or Message Brokers.
Microservices Orchestration Pattern:
Let’s take a look at the microservices orchestration pattern and see one of the most effective ways of doing orchestration within microservices. Unless in twenty-three, the differences between orchestration and choreography and we can see with orchestration it was almost like an orchestra well you've got different players doing their own thing, for example, the violin and the baritone here and you can see that the requests get all data for customer one two three requires an orchestration to get all the information across multiple microservices.
Microservices Orchestration:
- And we need some sort of conductor in front of that Orchestra that's the orchestrator. Let's see where that might occur now. One place it might occur is in the gateway in the API gateway.
- But let me show you the problem with that because as you will be knowing the API Gateway used in microservices is really not the same thing as an Enterprise Service bus and so the Gateway is great for things for example in microservices like security things. Like request ID generation to support traceability so that every request going through microservices ends up getting a UUID or a GU ID that forms that request ID that can be traced across all microservices for any given request.
- Things like service discovery are another great thing to put in an API gateway. Audit wiretap to say every request must be audited for example this is a great place to put that inside the gateway.
- Metrics based on request times for a business request, not each microservice is another thing there and you'll notice all of these have something in common and that is they're all cross-cutting concerns but since most gateways are implemented as Enterprise Service buses, one kind of pitfall is to say let's just do Orchestration.
- All of those boxes in the above image share a piece of code. There is some complexity associated with orchestration. The first is multicasting in other words if I've got 10 services to call now.
- Can I call all of those in parallel or do I have to call the first eight and then take some of that information as input into the other ones? What if something times out in the middle of all that orchestration? Can I just keep holding and return what I can or do I need all the results accumulated?
- And the third piece who owns the contract and when I say the contract is the actual JSON object that's returned from that getAll customer data. You can see the Gateway would own all these things and when in a microservices ecosystem that starts causing problems.
- Let me show you why my recommendation and advice is not to put that orchestration up in a gateway for example if I make a breaking change. So, for example, if I make a breaking change, to that in other words a breaking change requiring a change in the callers of that I need to change both of these flows within the Gateway.
- This is because the contract is also up there and now when I go to deploy, unfortunately, I need to deploy the entire Gateway and so this will kill an effective deployment pipeline within microservices.
A Glance Microservices Architecture:
Microservice architecture is based on services and their intercommunication. So, in other words the ecosystem is organized as a collection of interconnected APIs/services. The services or the APIs are fine-grained where each API endpoint performs a specific task and they are lightweight. One thing that is important here that the services are loosely coupled with each other and each API/service logically represents/holds a business functionality with a specified objective & outcome and is self-contained.
It is nothing but a black box for its consumers if seen from outside where you shouldn't need to know anything about its ecosystem or inner functionalities, and it may build upon the underlying system which is again a set of different microservices. I've given this diagram above which demonstrates how individual different microservices makes up the entire ecosystem and inter-communication happens to provide business functionality to the User Interface.
The benefits of microservices are due to the loosely coupled behaviors among the services, hence the modularity is improved by boosting them easier to build & develop, service management, and deployment of those Java development services. In another aspect, it also promotes parallel development also promotes scalability
Java Microservices API Composition:
A service referred to as the API composer queries data from multiple services and then performs an in-memory join of the data obtained to produce the final result. An example of this from an eCommerce scenario is illustrated here.
The product recommendation service that will be the API composer, in this case, requires the customer's order history and the product details of the items in each order to be able to recommend new products to a customer.
The product recommendation service will send the request to get the order history data from the order history service and the product data from the product service. Data retrieved from both these services are then combined in memory to generate the required result.
Scalability of Microservices:
With microservices architecture and we developed an application called an app1 also we deployed this application to AWS ec2 instance and we used a small site of AWS ec2 instance now over a period our application grows up and we would have multiple numbers of microservices and if you see the size of microservices is varying app5 is bigger in comparison to 4 and 6 is bigger in comparison to app2.
We are deploying all of these microservices to the same AWS ec2 instance down this AWS ec2 instance has certain limitations of hardware certain amount of CPU utilization certain amount of RAM and beyond that, it will fail so if more microservices would come into the picture we would eventually going to reach 100% CPU utilization and when we reach 100% CPU utilization applications will start to fail randomly and you would have no control on that so what is the solution for this how would you control out this in your applications.
So let us take an example of two simple solutions to prevent outage now talking about the solution the first thing that comes into mind is increasing the number of servers so what if instead of the single AWS ec2 instance we would replace the single AWS ec2 instance with more number of AWS ec2 instances.
We would place both of these AWS ec2 instances behind a load balancer another way to resolve this outage instead of using multiple machines what if we increase the size. We will use a bigger AWS ec2 instance it could be a medium or it could be a large instance.
Factors that decide for Scaling:
- 1. Individual microservices’ CPU utilization factor
- 2. Individual microservices’ Memory Consumption
- 3. Network traffic consideration for individual microservices
Horizontal Scaling: Number of Physical servers to be increased when the number of users increased and it requires a load balancer. In the case of horizontal scaling, due to HTTP network calls for interservice communication, so network latency can be experienced.
Vertical Scaling: In this type of scaling, the servers are not increased instead the capacity of individual existing servers gets increased by increasing the RAM/ Memory and OS upgrade. Network Latency is not a concern here as servers are limited. But here one limitation is at times you can’t go over a certain limit of increasing the memory/RAM.
Microservices Capabilities:
Java in Cloud Computing & IoT Space: Only running the business model logic and predictive analysis models on low-resource IoT or edge devices and thereby processing data locally at lower cost with smarter and faster response
Containerization & Cloud-native Deployment: Deploy via docker containers to any cloud, on-premises, or hybrid infrastructure that supports dockerized/containerized services. Leveraging Java frameworks /technology on Amazon Web Services (AWS) with instant cloud deployment and pay-as-you-go flexibility. So, there are many cloud providers available that can be taken advantage of.
API Management: Availability of many API-led strategies for application development and enable both internal and external microservices development ecosystems to securely scale, leverage, and innovate using your underlying systems, data, and IoT/Edge services.
Fine-grained Java microservices Integration with enormous functionalities: By Leveraging the advantage of the event-driven (which is fine-grained) patterns of serverless and function-as-a-service (FaaS) deployment where a little chunk of code responds quickly to an event for hyper-efficient. As the popularity of microservices and "cloud-native" architectures grows, the concept of a "service mesh" has emerged. The main idea with a service mesh is to maintain all the business logic in the service itself and discharge the network communication logic part to the inter-service comm. infra.
Microservices inter-service communication and composition:
Application/Service integration or creating smart API endpoints is all about integrating the different APIs /microservices, their data, and systems in the aspect of cloud-native applications & microservices. The integration runtime is also cloud-native and hence it can run safely and smoothly within the cloud env or Docker/Kubernetes and delivers seamless integration with the cloud-native ecosystem.
