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, its 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 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 will 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 a large number of microservices to manage. In order to keep management easier, grouping microservices to functional groups may be the initial way to go. 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 of a microservice 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.