Microservices offer an approach to development where software can be broken into small, distinct components. In the context of an application, these components are abstracted by an API and offer a narrow subset of functionality. This allows each microservice to be designed, deployed and managed independently, while working together to perform the larger functions required by the application. ProgrammableWeb has previously looked at what microservices are and the value they provide in modern development. Recently Michael Churchman offered some advice on when microservices may not be the best choice for your application.
One of the great determinants when deciding whether microservices make sense is complexity. While the microservice approach offers a number of advantages over monolithic architectures, they don’t come for free. Some of the costs associated include automated deployment, monitoring, and use of system resources. If your application isn’t going to realize enough of the benefits, then microservices can end up requiring too much overhead.
Microservices are generally best applied towards relatively large and complex applications that have a team in place to support them. However, if you have a smaller development and operations team, the distributed nature of such a system can be a strain. Small design changes could result in updates to the microservice orchestration and management system for example. On the other hand, with a monolith, the team is likely to be familiar with the code and maintenance can end up being simpler for that reason. The interactions between services may be optimized for specific tasks and deployment, while sometimes awkward, may be manageable.
As mentioned above, microservices are best suited for larger application where the services can be broken down to the smallest reasonable scale. The key word here is reasonable. A medium-sized service may contain subordinate services, but given the scale at which it is operating it wouldn’t make sense to break it down further. At that point, decomposing the system any further is likely to introduce more complexity.
Churchman points out that microservices can play a major role when updating or replacing a legacy system. However, that process may take a while and unless there is a well thought out strategy in place, the attempt at conversion can turn into a disaster. Organizations should consider whether the legacy system serves a mission-critical function, what point it is in its lifecycle, and if it is likely that it will be replaced entirely in coming years. No matter how poorly designed, replacing such systems requires a long-term strategy.
Microservices are often a way of compensating for complexity in situations where there aren’t large constraints on system resources. There are some applications though where a tight coupling between services is not only required, but desired. Churchman offers an example of a self-driving vehicle where the system needs to respond quickly to real-time data streams and delays can mean the difference between getting into an accident or not. A microservice architecture may add layers of communication between the services leading to potential slow downs in the processing of the data streams.