Microservice migration complete
It is done. And I like it.
The extra service which had been causing problems is no longer causing problems AND is also now a separate microservice.
In the process I split some of my error reporting functionality into a common library as well. Part of the bane of the hybrid solution is that you end up duplicating code because you aren't building with the idea that everything will be shared in mind. So it felt nice to clean up some of that and make some of that code reusable.
The main service is now a bit leaner and has fewer points of failure. I also took the opportunity to refactor some of my NHibernate connection related code to make that a bit more re-usable as well.
In hindsight I would say it worked out as planned. As I had stated before; my architecture was already hybrid, so I had smaller services which acted as microservices and all of the infrastructure to support it. This was also a more independent service in the first place.
In short, there were no surprises.
This project moved out my maintenance activities around backing up data out of the main project. And, in the process I identified a few other things I want to address in other Microservices later.
I also want to point another benefit of making background services like this into separate microservices; I can turn them on and off and reconfigure them without any need to take down the main application or add any infrastructure one might add to eliminate those if the services were coupled.
So the next projects are:
- Create a separate microservice for my Sync activities
- Create a separate microservice for my Restore activities
Basically, the Sync pushes records in near real-time to a secondary database so that there is little or no data loss in the event of a catastrophic failure. Whereas the restore functionality takes the last good backup and applies any missing Sync events to restore the database.
Right now these are both handled in the main application service. But, like the backup functionality, they aren't technically part of the main application and aren't coupled to it beyond the schema and DB connection. And the schema is defined in a shared library and the DB connection simply comes from a secret. So, these can moved to their own services. And they can be turned on or off as needed.
Comments
Post a Comment