Apr 16, 2015

MicroServices


Microservices ain't about splitting each function into its own process and call them micro service.

"In computing, microservices is a software architecture style in which complex applications are composed of small, independent processes communicating with each other using language-agnostic APIs." - Wiki
That means mutiple modules running in different processes. Earlier we have monolithic EAR with multiple modules, but now we will have mutiple WAR's (generally) running independetly. 
Indeed a module is a microservice which is like a Resource (a row in table) exposed as service( REST service with operations GET, PUT, POST, etc.) and probably each running in its own embedded server (using Jetty or Spring Boot). 
If you have a DB with tables and relations. We can assume a table to be resource and eligible candidate to be exposed as microservice. We can expose CUSTOMER table as REST services, all REST services packaged inside one WAR with embedded server.
Introduction to MicroServices in Java EE
If you are looking for the simplest possible microservices architecture, then you dont know how simple can it be. I was bit confused initially while thinking about microservices and finally came up with below design.
Design
Create multiple schema's (depending on microservices you can think of). An schema can be as small as single table.
Create POJO and create a controller class (to handle persistence, business logic if any, boundary, control, etc.)
Do not create an interface for controller class.
Place JAX-RS annotations on the class, optionally same class can be exposed as JAX-WS and can also act as CDI and can be injected into JSF.
Package the controller and entity in a war and deploy.
Now my war is a micro service.
Similarly create other schema's and war' correspondingly.
WAR's can call each other's REST services.
WAR's can communicated with each other with asynchronous events. Situation may arise in below design, if customer is placing several orders, we might need to asynchronously update the credit limit. If credit limit is part of Customer schema, and customer is calling Order services, then Order service can generate events for Customer service to update credit limit.

And you define services based on resources, its simple. 
But if you are confused of how to create business functions (that may involve multiple microservices), then Arun Gupta has a good blog post. 
If you know how to decompose, you should know how to compose….
Below blog has good simple deigns for Aggregating micro services.

Microservices and freedom
"No system-wide technology Stack means no struggle in getting new technology applied and no dependencies on unnecessary technologies & libraries, AND not bounded to company specific framework"
Yes, that's one of the benefit I see of moving to microservices architecture. I work in an organization which is very standardized, but in technology we can't be rigid. Sometimes I hate the time & money we spend on developing our own in house framework and which gets outdated so soon, even by the time it completes. We exactly reinvent the wheel, we limit our developers, we we create dependencies, we spend lot of time on database modeling, analyzing lot of requirements, making things exceptionally generic, and worst is we end with lot of layers.
When we think about microservices in Java EE context we think of multiple war's. In many cases, a war will be ECB. Some entity (or entities), some logic, and service, i.e. entity exposed as service allowing CRUD along-with business boundary. Now a war can be developed using Jersey or Spring Boot, and code inside war is so small that it can be maintained & developed by single developer or few developers. Ideally we should have Decentralized data management, and asynchronous event-driven updates. Using Java EE, technology stack can be - JAX-RS+CDI+JPA, optionally EJB. Indeed, everything is optional, its your choice to decide in technology within WAR, and don't decide standardize a framework with lot of layers.
To me microservices look very simple, and removes lot of complicated design pattern discussions. Its my war, and I decide on code inside it, you need the service, I will provide you a REST service and support all operations using HTTP actions, nothing other. REST has already standardized the protocol.
No doubt microservices are modular and facilitate faster deployment and reduce governance activities (add agile for this).

Share:

No comments

Post a Comment

Comment

© Shift, ShEkUP, Shape, and Surprise | All rights reserved.
Blogger Template Crafted by pipdig