Leveraging microservice architecture for app development may be trendy, but it is not a free ride. In this tip, I explore the pros and cons of leveraging this approach and the considerations app managers need to keep in mind.
Microservice architecture (MSA) is becoming more popular for enterprise and Web startup development projects as a way of making applications more flexible. But before building a new application with this architecture, every technology manager must know the pros and cons of this approach.
What are microservices?
First let's discuss what microservices are and how they differ from other development approaches. In enterprise software, applications are usually built as one large system with all the necessary business logic built in. Although the logic inside may be implemented as standalone modules that provide services to other modules, everything is still inside the same code set. In other words, the services made available internally are not accessible from outside the application, so reusing services from other applications is difficult.
MSA breaks an application into many small pieces where each piece performs a very specific and focused piece of logic. The individual microservices are small enough that they can be managed entirely by a small team or even a single person. Furthermore, these microservices are available for use by outside applications.
A key difference between the two is how they scale. With one large system, scaling must be done for the entire system because the individual pieces cannot be separated. If a single area in the application becomes a bottleneck, the entire application must be duplicated to an additional server to scale. MSA, on the other hand, can scale by creating only another instance of the service under pressure.
Arguments for microservice architecture
When software is as small and focused as microservice architecture recommends, it enables a very fast update/release cycle for those services. Because there is typically very little going on inside these services, they can be easily updated, tested and pushed out to production without affecting other running systems. With the proper interface versioning practices, new functionality can be released alongside older versions enabling new features as needed while still continuing to support the old logic.
MSA is also a good answer to enhancing legacy technology. The basics of a microservice-based call entail a simple HTTP request to a given API. Support for this is common among legacy technologies, thus enabling an extension point for these technologies.
Arguments against MSA
Microservices are "micro" because there is a minimum of logic happening inside. This is well suited for Web software or mobile apps, but for enterprise line-of-business applications it can be restrictive. Attempting to code a long or complicated set of logic inside microservice architecture could make the code even more difficult to understand and manage.
Microservices can also introduce a new problem -- maintaining the API signatures. With the strength of flexibility and easy rollout comes the responsibility of ensuring that other software using older versions of the services will continue to function. You cannot expect all users of the service to upgrade their code each time an enhancement is made, so extra attention must be given to versioning the releases.
Should we use them?
I believe the best approach for enterprise applications is a combination of microservices and large applications. Common, small operations can be moved to a microservice while the main logic flow stays in the larger, more complicated code blocks.
Automated email generation and mail-merge is a good example of something that works well with microservice architecture. The main logic tree calls the service and passes in any data that is required for the merge function, then goes about its business confident that the email will be generated and go out.
Learn how to rethink modular programming interfaces for microservices
Learn the four pillars of microservices truth
How are microservices bringing agility to SOA?
The challenges of testing RESTful APIs and microservices in the cloud