#Microservices - Size Doesn't Matter!
I work as part of a team at MYOB that has been building a new platform for accountants for the past year using a microservices architecture. We're now running approximately 20 microservices in production and we've learned a lot about the right size and granularity of microservices during the project.
"Microservice" is a very loaded word, it immediately evokes connotations about the size of what you are building - what is the right size and granularity for a microservice? If I go too large am I doing it all wrong? It's gotta be small because it's a microservice , right?
Well, when it comes to determining the right size for a microservice, unfortunately the answer is "it really depends".
If you go too small you'll end up with a very chatty system where a lot of processing time is spent waiting on remote calls between services. If you go too large then there is a danger that your code will become too complex and more difficult to maintain as more and more functionality gets added. Your services need to be the right size to make them composable and reusable.
So when you are determining the appropiate size for a microservice I think that it really depends on three things
- the maturity of your team and automation
- the complexity of your business domain
- how long your project has been running
###Size varies depending on the maturity of your team and your automation
Firstly, you need to acknowledge the fact that you are introducing an overhead every time you create a new service. Martin Fowler describes this as a microservice premium, which I think is a pretty appropiate term. This overhead is bigger or smaller depending on your team's maturity with microservices and how good or bad your automation is. For example, if you have invested in building a template project with the right scaffolding to make a new service immediately deployable then the overhead to create a new service is much smaller but you need to invest in good automation to avoid the high microservice premiums. We've built a template project for this purpose and we are constantly looking for ways to reduce the friction involved in building and deploying our code.
###Size varies depending on the complexity of your business domain
Lines of code isn't a good way to measure the size of a microservice. Different programming languages are more or less expressive and even in the same programming language the number of lines of code it takes different developers to solve the same problem varies dramatically. It is more useful to focus on the functionality inside the microservice. If the microservice implementation is doing little more than exposing a basic CRUD style interface chances are you've gone too small and you will end up building an anaemic microservice. It is better to think in terms of buisness capabilities, think about the right bounded context that will give you a reusable business capability and take it from there.
###Size varies depending on how long your project has been running If you are in the early stages of a project it's best to start with a smaller number of services. Chances are you don't fully understand the problem domain and whatever you are building will invariably change as your understanding grows. If you are going to implement microservices you need to be prepared to refactor your services, combinining them and splitting them from time to time till you get the balance just right and you need to fully embrace an evolutionary design. Last year, one of our product teams started out with a single microservice and the guys are still happily working away on the same service. I'm pretty sure that the code will split in the future but it's not time yet and they are wary of premature optimizations.
So there you have it, in summary if you plan to adopt microservices remember that size isn't something that you should get hung up on. Its better to think in terms of where your team is at and how far along you are in your project.
Hope this helps !