Microservices: 3 questions for your project
Posted on Friday Mar 06, 2015 at 12:00AM in Technology
Microservices has taken over the world in the last couple of years. The concept of loosely coupled, highly cohesive components is an attractive one, but it can have its disadvantages. If you're going down this route, then thinking about the following questions will make sure your project avoids the pitfalls.
What scale are you aiming for?
Software can be challenging to scale along two axes: volume of use, and complexity of behaviour. Small services can help with both, but only if done right. If you have low volume of use, and your application is simple, it may be hard to justify the overhead of microservices.
When performance testing identifies a particular service that is a bottleneck, it should be easy to scale it up, without needing to change the rest of the system. (This is the key advantage of microservices.) For this approach to work, you need to be able to get sufficiently fine-grained data from your performance testing tools. Get familiar with one early in the project; you should not leave this until the system is live.
Behavioural complexity is more difficult because you do not want to avoid a big ball of mud, only to find yourself with a distributed big ball of mud. Arguably, concentrating on the logical separation of microservices (rather than physical) will help to drive good design. For example, you may choose to have logically separate microservices that just happen to be deployed in the same container at runtime, using normal method calls between them rather than the more conventional REST/HTTP calls. This will probably make it easier to reason about the system at runtime.
Who owns the microservices
Software is written to solve the needs of whoever is paying for it ('the business'). In large organisations, different lines of reporting are frequently responsible for different applications. When these applications need to talk to each other, organisational politics can intervene. This was one of the motivations behind Service Oriented Architecture, before that term was co-opted by companies selling Enterprise Service Bus software.
If in your project, the microservices are all owned by the same business function, you are going to have an easier time making changes to them, since you will not have to negotiate with other parts of the organisation.
Conversely, the fun really begins when your microservice is a client or server of some other business function's services. You will need to spend more time thinking about versioning and support, and more time communicating. Good documentation, which is always important, becomes vital. Months and years down the line, you need to be able to look at a given service's logs and determine whether it is actually still being used; it won't be necessarily be sufficient to ask the team responsible for it.
How are you dividing your services - functional or technical?
Functional services that handle a specific part of the business domain (e.g. Address) are a natural fit for microservices because they can be easily understood even by non-technical people involved in the project.
It is also possible to split services in a more vertical fashion. For example, a microservice for database access, a microservice for authorization, etc. A user's request would pass through multiple such services while being processed. This is more in line with the traditional layered approach to application development.
There is a potential problem with adopting both on the same project, because that will result in an explosion in the number of services: N functional areas * M layers.
The functional approach fits more into an agile workflow where a single team is responsible for the delivery of a feature. Technical services, if they are stateless, can be refactored into common modules that are incorporated into each microservice.