Approaching Microservices for Organizations and Enterprises

DZone 's Guide to

Approaching Microservices for Organizations and Enterprises

You'll want to keep these key issues, like ROI and changes to deployments, in mind when planning to implement microservices architecture.

· Microservices Zone ·
Free Resource


Proper groundwork is required prior to deciding on an approach for microservices. Taking time and understanding certain issues that your organization is currently facing helps you to build robust service-oriented architecture with microservices.

Think About Issues With Your Monolith

Take time to list issues you have been facing with your existing monolithic solution. Issues like longer deployment times, manual deployments (can't be done with continuous integration), longer regression testing, and more unexpected issues in production due to changes made in particular case impact some other functionality that is completely unrelated.

Think About Business Growth

Think about your business growth at least for the next ten years and list more frequently changed functionalities to least changing functionalities. This really helps an organization to prioritize the development of microservices for very frequently changed functionalities, so that you can see a return on investment that will encourage you to move forward with rest of the microservices development.

Think About Your Existing Assets

It is worth thinking about existing monolithic applications, data models, and tools to see what percentage of it can be reused in some fashion. It is ideal to have separate a data repository for each service, but it may not look feasible sometimes. Start listing the challenges to help define what direction you want to go.

Think About ROI - Return on Investments

This aspect really helps define how you achieve ROI, in terms of

  • Can these APIs be cross-sellable for similar businesses and make more money?

  • Can these be reused across all units of organization and cut/retire legacy applications?

  • Does it really help with time to market and optimizing the business model?

  • And more!

API-First vs. Code-First Approach

There are several advantages to going with an API-first approach. Basically, it helps to visualize how your API is going to look so that you can review and make changes well before developing code.

More info on API-first approach advantages can be found here.

API Development and Management

This is a very important step in considering how you want to build all microservices with a consistent and standard approach, with respect to the following:

  • Interface model

  • Technologies and common tech stack across all services

  • Testability

  • Code coverage/automation of integration testing

Think about an API gateway approach; do not expose your microservice directly- it is going to be miserable.

Also, it is worth considering API management tools like Apigee or something similar.

The Twelve-Factor App Standard

I strongly believe in "don't reinvent the wheel" for common stuff. The SalesForce.com team put together twelve factors on how modern applications should be developed and managed, from the codebase and dependencies to admin processes. You can read more about it here.

Deployment Model - Cloud, On-Prem, or Not Sure

It is worth considering this aspect so that you can leverage some of cloud-provided services. For example, if you consider AWS, you have plenty options for how their services can be leveraged.

If you are not sure at this time, it is appropriate to consider microservices that won't depend on cloud-provided/third-party provided services. Basically, they should work both on-prem and on any cloud. As an example: containerize and deploy anywhere. Consider leveraging Netflix OSS toolkits like Eureka, ZUUL, Ribbon, etc.


This is another important aspect as robust security needs to be implemented for microservices so that they are never compromised by hacks. Consider using the OAuth2 model using JWT - JSON Web Tokens.

microservices ,integration ,architecture ,enterprise

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}