Friends , as part of Ejyle’s knowledge sharing initiative, I will start blogging frequently on technology and architecture 

Here comes the first blog on Microservices, where I will share my thoughts on what it is and a high level architecture of how we should see it!

What is it?

There are many definitions of micro services out there, and probably you will get confused, However I will try to define it using the most common concepts. A microservice is an engineering approach whose primary focus is to decompose or break down application functionality into smaller single function modules( one function or responsibility) with well-defined interfaces which can be independently deployed and operated in silos and there can be smaller teams that owns the entire life cycle of that service .

So, instead of having one large application, we decompose it into separate, different, mini applications (services).

Each service handles a specific business domain (logging, authorization, logic 1, logic2 ) and provides the implementation for the user interface, business logic, and connection to the database.

Why?

Microservices accelerate delivery by minimizing communication and coordination between people while reducing the scope and risk of change.

Caution!

Microservices solves problems that occurs in the large application from scaling, managing, but it is not always the way to go. Most of the problems in Microservices are inherited because of having separate components. For example, communication between methods in monolithic is much faster when compared to services asynchronous communications, which slower, harder to debug, and must be secured. And for sure, there will be an extra effort for operations, deployment, scaling, configuration, monitoring and testing as each service is separate and also we need to have a skilled DevOps team to handle the complexity involved in deployment and monitoring automation so you should weigh in these items and if you have controlled and managed all these issues, then go for it after careful assessment.

Architecture View

Some Points on architecture

• In Microservices infrastructure for the client to make a request, the client needs to know the network location (IP address and port) of a service instance.
• In a traditional application running on physical hardware, the network locations of service instances are relatively static. However, in a modern, cloud‑based microservices application, however, this is a much more difficult problem to solve as Service instances have dynamically assigned network locations.
• Moreover, the set of service instances changes dynamically because of auto scaling, failures, and upgrades. Consequently, your client code needs to use a more elaborate service discovery mechanism and Service registry comes to our rescue! The Service registry is a key part of service discovery. It is a database containing the network locations of service instances.
• For most microservices‑based applications, it makes sense to implement an API Gateway, which acts as a single-entry point into a system. The API Gateway is responsible for request routing, composition, and protocol translation. It provides each of the application’s clients with a custom API.
• Any architecture that uses many services and is distributed raises concerns for service levels such as availability during instance failures, security for exposed surfaces including APIs, on-demand scalability to address load increases, latency, and performance impacts during peak times. These concerns apply both for the traditional services as well as for the loosely coupled microservices that compose the business applications, So in order to scale the client and microservices independent of each other, a client interacting with a microservices-based application does not need to know about the instances that are serving it. This is precisely the de-coupling that a reverse proxy or a load balancer provides; load balancing is the answer to ensure that the microservices can handle load, security and remains available.
• Look at integrating Authorization service at Gateway so that there is single point of authentication and authorization.

Conclusion

Thank you for reading! If you enjoyed it and If you have any questions or comments you know where to reach me! Part2 can be found at https://ejyle.com/blog/technology/microservices-part-2-inter-service-communication-service-registry-discovery-load-balancing/