After hearing the term “microservices” back in mid 2016 and reading up about the design pattern I thought, yes I want to develop microservices. Then in early 2017, I was given a chance to work on a new greenfield project.
The project itself needed to be broken down into two different processes, but both processes would need a primary service to handle the primary process and then auxiliary supporting services.
Before I was aware of the microservice pattern I might have created?one service host to handle the needs of the project. However, at the moment I had identified three windows services.
Even though it pains me to say it one of the services had to poll the database, and the two others were going to subscribe to their?own RabbitMQ queues.
I started the project by creating one Visual Studio solution and started creating my class library projects.
After a couple of weeks I had gone from one Visual Studio solution to five, each one in their?own source controlled?repository; one for each of the windows services and the other two for class libraries?which contained code which the 3 services needed.
The class library?projects had to be published to Nuget?and then referenced?via Nuget. I set up our build tool, TeamCity, to publish to Nuget on each check-in
A few more weeks passed and the three services had grown to five. The two new services needed to monitor the tables in the database to ensure that items which needed manual intervention or could not be published to RabbitMQ were not lost.
As the services were independent of each other I was able to finish development on one service and get that into the hands of QA and into production, opposed to if I had decided on developing one service which handled everything.
So to summarise what I have learnt…
Even though I probably?spent more time actually coding, using the microservice pattern the project was delivered quicker than if we went with one service. Why it was quicker, well, after we signed off the first service, during testing of the second one a bug was found. But because the services followed the microservice pattern the bug was isolated?to that service. If I had developed one service then the whole thing would have needed to be tested again. The QA team were actually able to test the other services while I was resolving the bug.
After the solution went into production an issue was discovered?in one of the services and the service had to be tempory stopped until it was resolved. The rest of the services were able to carry on, so the severity of the outage was minor compared to if one service was handling everything then it would have been a major outage.