peshkova - Fotolia


Make sure your microservice design supports reuse and avoids redundancy

Microservices are supposed to make life easier. But when improperly managed, it can do just the opposite. Tom Nolle explains what it means to design microservices properly.

Microservices are small functional bundles of code designed to facilitate reuse and improve QoE and availability...

with proper use. But when improperly used, they can be a nightmare for application lifecycle management and resource efficiency.

To get things right, you have to get beyond combing through directories and registries. Instead, think of your microservices as a virtual application; focus microservice design on reuse; catalog microservices in such a way as to ensure that new services and instances are accommodated; and, finally, use application architects and ALM teams to catch situations where unnecessary services are created.

What should a microservice be?

The great irony of microservices is that they are supposed to facilitate reuse but are usually created without much regard for that goal. A microservice should be a company resource, something created in such a way as to guarantee it can be reused as broadly as possible. A corollary to this is that no project should create a microservice without a review to determine whether such a service or a similar service already exists and without reviewing all the prospective applications for those services that are determined to be new.

The easiest way to do this is to consider a microservice to be a broad application whose ongoing changes are driven by a combination of new microservices, microservices changed to accommodate broader usage or withdrawn microservices. This virtual application should be subject to normal development reviews, coordinated with other development teams to ensure microservices are actually used and used properly and coordinated with an ALM activity to ensure that microservice changes don't break existing applications.

No microservice strategy can succeed unless application architects are conditioned to look for microservice opportunities in application design and to create the most generally useful microservices possible where new ones are needed. This means the most effective control process for microservice use is based on an ad-hoc application architect group responsible for microservice review. This team would then be the coordinators of this microservice virtual application.

The great irony of microservices is that they are supposed to facilitate reuse but are usually created without much regard for that goal.

Early in application design, the goal should be to use microservices to implement application features where such services are available and where they can meet application performance and security requirements. Doing this at the application architecture point in development ensures that microservice design is directed to reuse.

What if a microservice isn't cutting it?

If a requirement can't be met using a current microservice, then the options are to use embedded traditional logic, augment a current microservice to fit the need or develop a new one. Embedded logic is the option to pick where the feature being considered doesn't have broad value, or where its workflow is such that having an external microservice to support it would impact quality of experience, or QoE. Augmenting a current microservice is the best solution where the requirement could be met with a minimal and logical extension of an existing microservice (avoid awkward feature combinations).  If neither of these answers work, then a new microservice should be explored.

It's important to review each new microservice design to ensure that it's broadly reusable. Generally, this starts by using a simple RESTful interface and implementing the service to be stateless in operation. These simplify multiple concurrent uses of the service and also horizontal scaling of the service instances under load changes. From there, try to design the service to support its function in any application context.

One way to do this is to review current applications for places where the new microservice could or should be used. This is an important step in preventing having microservices that unknowingly duplicate embedded logic. Where that happens, it should only be for the reason of performance or security/compliance, and steps to include common code in both the embedded logic and the microservice should be considered to avoid developer confusion later on.

The next step is to consider the way in which microservices would be discovered. The common approach is to use a form of registry, but the precise mechanism will depend on the programming language used and the dynamism expected for the microservice. If microservice calls are explicitly introduced into application code at development time, then the registry can be considered a developer tool, almost like a class library. If microservice calls are expected to be more dynamic then a runtime discovery process will be needed, more like the directory of a SOA application.

In either case, best practices call for microservices to scale under load, which means that the registry/discovery mechanism must be updated when the number of instances of a microservice changes, and must direct requests to an instance in a way that balances load. The mechanism to be used for load balancing and instance management has to be included in the registry, and this is true whether the microservice is invoked in a static or dynamic way.

The final step in microservice management is the "deduplication" step. Despite efforts to control the deployment of microservices and eliminate overlap or complete duplication, some problems are likely to sneak through. Some can be caught in the regular software-architect review mentioned above, but another place to catch them is in ALM.

If you apply the recommendation of treating your microservice repertoire as a virtual application, then you'll have ALM steps designed to validate microservice changes. These will necessarily expose any microservice issues that have arisen in existing microservices. ALM at the "normal" application level will also require testing the microservices associated with each application, and this will expose any new microservices that have slipped through the review process. When that happens, review these "maverick" microservices and either remove them through consolidation or add them to the formal registry and the virtual application process.

Always think ahead

Retrospective reviews of service catalogs won't help you manage microservices; it will just detect your failures. To succeed, apply controls from the microservice design phase, and tune your whole application development and deployment cycle to sustain them. This guarantees your microservices will live up to their potential.

Next Steps

Learn about microservices bringing development in SOA

Using IT resources to master microservices management

Efficiently upgrade applications using microservices

Dig Deeper on Distributed application architecture