Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Microservice architecture: What app managers should know

Microservice architecture is gaining popularity among app managers, but what are the pros and cons of this approach? Brad Irby explains in this tip.

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.

Next Steps

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

This was last published in September 2015

PRO+

Content

Find more PRO+ content and other member only offers, here.

Essential Guide

The world of microservices and container technologies

Join the conversation

3 comments

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

What are your plans regarding the use of microservice architecture?
Cancel
We’re currently doing our due diligence investigations and analysis on microservices. We have several legacy systems that we are preparing to replace, and the fast update/release cycle that can come with microservices is very appealing.
Cancel
While the putting complicated logic inside microservices can create issues, it really goes against the whole idea of a microservice, so I don’t really see that as a strong argument against microservices. If anything, it’s more of an argument that not everything should be implemented as a microservice.
Cancel

-ADS BY GOOGLE

SearchSoftwareQuality

SearchCloudApplications

SearchAWS

TheServerSide.com

SearchWinDevelopment

DevOpsAgenda

Close