Designing Microservices – a Critical First Step
Designing microservices will be critical as you rework your code to fit into this new technology. The way I think of designing microservices is the same way I think of a Java or C++ object. The microservice tries to hide all the gory details that make it up. All of the programming logic is in the microservice – just like with object oriented programming (OOP).
The objects expose just what the end user needs to know about. So thinking of a microservice as an object makes it easier to understand since we have been using objects for years and years. However, not everyone implemented OOP with a clear design in mind – a mistake.
The same best practices that apply to OOP apply to microservices. For example, the interface level for a microservice is typically the REST API. In OOP, it’s the public methods of the class. Breaking backward compatibility of these interfaces is something you want to do as a last resort. Instead, create a new interface and deprecate the old one. Deprecation of the microservice gives you time to get all of the consumers moved over to the new interface. Another, example is circular references between microservices. In my book, circular references is a result of poor planning and coding practices. We know from OOP what a pain circular references can be a pain so don’t do it with microservices. Naming conventions from OOP, such as package and class names, can be applied to microservice REST APIs.
Try not to re-invent the wheel but instead pull from OOP practices and apply them appropriately.
When designing microservices, I look back to the data model for a starting point. A database table will typically map to a microservice. The microservice provides Create, Read, Update, and Delete (CRUD) to a table. Therefore, going down to a lower level that has one microservice = one transaction is too granular and creates too much work for managing them. In addition, even having microservices at the database table level will still produce too many to manage but grouping microservices into functional groups may be help. For example, put users and user groups into a single microservice instead being separate.
The one advantage of microservices vs OOP programming is that you can have multiple versions running at the same time. The disadvantage is knowing what a microservice does especially when you just know the a container id running a microservice. Container -> microservice -> microservice version -> dependent microservice versions back to the source code version that created the microservice is key to microservice management. DeployHub Pro has the functionality built in to track the relationships from the source code -> git commit -> issue tracking -> binary repository -> stage in the continuous delivery pipeline -> test cases run -> applications consuming the microservice -> microservices consuming other microservices -> container images -> AWS, kubernetes configuration -> deployments -> AWS, Google Compute, on premiss hosts -> running containers. DeployHub Pro enables you to visualize these relationship for easy management of your microservices.
Just a note, DeployHup OSS (Open Source) provides a similar mapping starting at the build job to the microservice.