We've heard a lot over the past few months about the pros and cons of Microservices. Are they really just SOA? Can they really help with architecting complex systems? Whatever the discussions may suggest, several companies have already moved to a microservice-based approach or are doing so today. As they do so it's only natural that we will hear about their experiences, both positive and negative. Recently Tom Livesey from Droplet has shared their experiences. To put some context around the discussion, Tom starts by discussing the needs of Droplet:
Like many startups who want to get an initial product out quickly, we started out with a monolithic Rails app that handled everything from payments to push notifications. While there was no immediate concern about scaling, we thought we could probably benefit from separating some concerns and breaking out some functionality. Over time we started breaking out smaller and smaller pieces of functionality and we now have over 20 services mostly using Sinatra or Go.
Tom's article covers 7 lessons learnt in their development, including:
Don't do too much: The micro in microservices really should be taken pretty literally. While I don't think there are any hard and fast rules about the size or number of lines of code, you should think very carefully about what your service is doing and whether its responsibilities are few and well defined.
This is interesting since we have heard how people are assuming the term microservice necessitates a specific quantity of code, even going so far to consider Nanoservice as a new term. Then in Tom's list he mentions that they decided to publish everything:
To deal with asynchronous events like sending emails and push notifications it made sense to use some kind of messaging queue to allow other services to listen out for certain events and then take action on them. [...] Our motto is publish everything, however boring and insignificant it may seem to the rest of the system. Publishing is very lightweight and the publisher does not need to know whether 0 or 1000 other services are interested in that particular event, just fire and forget. This is extremely powerful and is what enables microservices to be built and deployed extremely quickly.
In terms of microservices and data, Tom has this to share:
When we built the new version of Droplet, we added about 10 new services in a matter of weeks. [...] The service listened for any account update events and updated its own version of the data appropriately. Each service should have its own datastore and it's bad practice to share databases between services but there is nothing wrong with keeping cached data from other services as long as the mechanics are there to keep it fresh.
Over the years we have discussed SOA and contracts a great deal. Whether it was a contract maturity model, contract versioning, or an accepted part of SOA patterns, contracts have been an important part of SOA development over the years, both with Web Services, REST or other implementation approachs. So it is that Tom also mentions the need for contracts:
Changing the interface of a service means that all services that use it also have to be changed. This could be 1 or it could be 1000. This actually promotes good API practices as you are forced to think ahead and design an API that will cater for all future clients. It is possible to version the APIs or have versioned representations of data but it's much easier to put in the work upfront.
Tom's conclusion clearly shows that Droplet believe their investment in using microservices was well worth it:
There is no denying that choosing to build a microservice infrastructure is an investment. We have only recently 'broken even' at Droplet but we are really experiencing the benefits now, building and deploying services is extremely quick and easy. It's nice knowing that we can easily use the best tool for the job or try out new technologies with minimal impact on the rest of the system.
We're sure to hear more and more about experiences using microservices, just as we did with other approaches to SOA, REST etc. over the past few years. These experiences may help sway people in one direction or another. Where necessary they may also help to evolve microservices with best practices, patterns etc.