Software Architecture: Microservices
So, you now heard of Microservices Architecture... What is it?
Microservices Architecture (to be written as Microservices) is a way to breaking a large software into a smaller, separately-deployed system that communicates using Application Programming Interfaces (API). Its popularity rises as Agile Development Practice getting more and more common to the industries these days as Microservices enables each small team to focus on one service instead of all the service as a whole.
What is the benefit of using Microservices?
Microservices solve many of the common issues found in both monolithic and service-oriented architecture as microservices are more robust, have better scalability, and can easily support continuous delivery. Microservices also provide the capability to do real-time production deployments, significantly reducing the need for the traditional monthly or weekly production deployment.
How is it implemented?
There are dozens of ways to implement a microservices architecture. However, three main topologies stand out as the more common and popular: the API REST-based topology, application REST-based topology, and centralized messaging topology.
API REST-based topology is useful for websites that expose small, self-contained individual services through some sort of API. It consists of very fine-grained service components that contain modules that perform specific business functions independent from the rest of the services. These fine-grained services then accessed using a REST-based interface implemented through a separately deployed web-based API layer. This topology is commonly found in single-purpose cloud-based RESTful web services in Yahoo, Google, or Amazon Services.
Meanwhile, Application REST-based topology differs from the API REST-based approach as the client request is received through traditional web-based business applications rather than through a simple API layer. The service components in this topology tend to be larger, more coarse-grained, and represent a small portion of the overall business application rather than fine-grained, single-action services. This topology is commonly found in small to medium-sized business applications that have a relatively low degree of complexity.
Centralized messaging topology is typically found in larger business applications that require more sophisticated control over the transport layer between the user interface and the service components. The benefit of this over simple API REST-based topology are advanced queuing mechanism, better overall load balancing and scalability, and asynchronous messaging, monitoring, and error handling. This topology may introduce a single point of failure or architectural bottleneck issues (as commonly found in the centralized broker). However, this issue can be solved by broker clustering and broker federation (splitting a single broker instance into multiple
broker instances to divide the message throughput load based on
functional areas of the system).
What to consider?
While using microservices makes your service more robust, provide better scalability, and provide the capability for continuous delivery, its distributed nature also make the system have complex issues found in the event-driven architecture pattern, including remove system availability, remote access authentication and authorization, and contract creation, maintenance, and government. Also, while you can implement a microservices architecture that performs very well, this pattern does not naturally lend itself to high-performance applications due to the distributed nature of the microservices architecture pattern.
Conclusion
For small or new companies, starting off by implementing monolithic architecture may be simpler, faster, and cheaper. However, you should consider planning to microservices later on the road to get the benefits of it and avoid monolithic architecture drawbacks. On the other hand, huge companies with millions of users and hundreds of staff who haven’t migrate to microservices should consider it as soon as possible to ensure uptime, scalability, and modularity of their services.