What is “Microservices”?
Microservices is the “new kid” on the block; a new paradigm that seeks to replace monolithic enterprise applications with a suite of small services that use lightweight mechanism like REST to communicate with each other. These services are built around business capabilities and independently deployable by fully automated deployment machinery.
The crux of microservices can be epitomized by this illustration as defined by Martin Fowler.
Frameworks
There are couple of frameworks available in different software ecosystems that make it easy to create distributed applications using microservices architecture.
- Java – Spring Cloud using Netflix OSS
- Node.js – Seneca
The reference architecture developed by us builds on the Spring Cloud ecosystem.
There are number of components available within the Spring Cloud and Netflix OSS ecosystem that solve common problems for distributed applications (e.g. configuration management, service discovery, circuit breakers, intelligent routing etc).
Target Architecture and Components
The application consists of 8 different services that are available in Synerzip GitHub repository.
- config-server – setup external configuration
- webservice-registry – Eureka server
- auth-server – OAuth2 authorization server
- user-webservice – User microservice
- task-webservice – Task microservice
- comments-webservice – Comments for task microservice
- api-gateway – API gateway that proxies all the microservices
- web-portal – Single Page Application that provides the UI
All the different services lend themselves to the following target architecture.
While there are existing samples available for using the different Spring cloud/Netflix OSS components, we did not find anything that merged all of them together to provide an enterprise architecture. Additionally the documentation is sporadic and widely distributed so it becomes hard to understand how the components interact with each other.
This reference architecture can be used as a starting point to understand the Microservices paradigm and then expand to scale to your architecture needs.
Considerations for building production-ready systems
The thought process for the reference architecture revolved around 2 concepts –
- Making it easy enough so that beginners can understand
- Making it complete enough so that it can serve as the starting point of enterprise applications.
When you are ready to build your application with this reference architecture, keep the following things in mind –
- The application uses an endpoint to check if the user is authenticated; this leads to a very chatty application. When building your system instead use the Json Web Token (JWT) wherein the token itself contains enough information for the resource server to do simple user authentication.
- The Single Page Application that provides the UI is part of the reference architecture, whereas applications might be better off having the SPA as separate application that just needs to interact with your distributed system and not be part of the distributed system.
- There are additional Netflix OSS components like Turbine, Feign and SideCar that might be applicable to your architecture.
