Happy the 4th! I would like to put down some thoughts about microservice today while I am waiting for the BBQ and fireworks!
Microservice has been buzzing in very recent years, partly due to industrial cloud players like AWS, Azure. True Microservice is really revolutionary because it is against the traditional organizational layout of companies. From front end developers, midware developers to database designers, organizationally they are typically separate groups. The grain goes horizontally instead of vertically. A true microservice relies on vertical grain in that same group of people with a team size of 6-8 handles front/middle/backend. One microservice is cared by only one such a team that knows things up and down. In a big organization, this kind of set up is truly new and generally hard to change into.
Splitting front and middle layer into many modules is not considered microservice. That is modularization or SOA at the best. True microservice should start from the model/DB layer. Splitting DB layer into collections of related entities to me is the most challenging part of microservicing in that it is against our traditional ways of doing things. For the same reason, microservice should start from the model layer, setting up boundaries and interfaces between them, as well as shared concept and models. In my opinion, jobs of developers of microservice should become more focused and simpler (not necessarily easier), and jobs of architects will get harder and harder. Risk of imperfect architecting gets even greater.
So how would you start your own microservice architect in a traditional organizational set up, especially for old monolithic applications? My view is that you can always start with those components in your application that don’t require backend layer or only relies on other services. I know this is basically avoiding the problem of slicing backend layer. But for getting onto the microservice bandwagon, it is a good start with low risk. This approach should provide valuable lessons from both technical and organizational aspects. Amazon.com has microservice that only provides a submit button or only calculates tax. These kind of microservices typically don’t need backend layer redesign or their backend is very simply isolated. I would imaging many common services such as encryption/decryption, logging, scheduling can be implemented as such microservices.
Last, microservices really works well with DevOps. Imagine how hard it is for testers and sysadmins when you have hundreds or thousands of microservices in your data center! But I will leave DevOps to another post.