How to Make Microservices Sing – Part 1

In the lead up to Nearshore Americas’s special webinar presentation on April 3rd at 2pm EDT, Mike Hahn, one of the webinar panel members, explores what you need to know about microservices and getting it right for your organisation in this series. Registration for the webinar is now open.

Getting the deployment of microservices right takes planning. Once you know that microservices is the right fit for your organization and your application, you need to focus first on decoupling the monolithic. Doing this means following a process that helps you complete that decoupling as quickly as possible while making sure the application stays up and running for customers and/or internal end users.

In this first of a two-part focus on making microservices sing in your organization, we focus on decoupling and identifying pain points within the environment.

It is best to prioritize the decoupling of the application’s modules based on three factors:

• Business value: how much does each module impact day-to-day operations?
• How frequently does each module change?
• What is the workload on each module?

In a nutshell, the modules with the greatest business value that change frequently and which are usually under a heavy workload, should be decoupled first. It’s also best that these decisions be made by a combination of the company’s executives and the software team to make sure that both business and the technical factors are considered.

By prioritizing modules for decoupling, the software development team can work on the services that mean the most to the business. You may discover, for example, that an application bogs down when managers run a specific report to generate KPIs that help run the company. The development team can then prioritize decoupling the module that contains that particular service.

It’s vital to take the perspective of decoupling capabilities, as opposed to decoupling code. You can rewrite the capabilities by extracting only the code that is actually in use. This will allow you to get the features that need to be improved, up-and-running faster.

A thorough review of the current environment is the first step to decoupling a monolithic application. This should include looking at which technologies are in use and the libraries and frameworks that the technologies tap into, then running basic monitoring tools to determine the current status of the application:

• How many queries and requests are made to specific compute resources?
• How long do queries take?
• What are the capacity and utilization of the CPUs and the memory?

If the application problems you are experiencing are caused by insufficient CPUs or memory, you may want to start by moving your monolithic application to a server with additional compute resources. If, after adding those resources, the application problems persist, then conduct in-depth log analysis and error tracing.

This allows you to collect additional metrics that provide details on the exceptions received from the application and to identify application bugs. By determining the application’s pain points, you will have a better idea of where to decouple first.

You may discover that you can re-use some of the existing code base. But more than likely, you will need to extract functionality from some of the services and move them to a new code base. The good news is that a microservices architecture gives you the flexibility to build each service using the programming code that works best.

If the coupling is really tight, you may not be able to decouple the entire monolith. In this case, you can decouple some of the services and leave the rest within the monolithic architecture. An application can use a combination of a monolithic and a microservices architecture by utilizing an API gateway to direct end users to the decoupled portion or the monolith depending on the services they request. You can also insert an API layer that allows the monolith and the decoupled services to exchange information.

We will look at the best practices for decoupling and how to develop a plan for deployment of microservices in the second part of this feature on how to make microservices sing.

Don’t forget to sign up for the webinar on microservices on April 3 at 2pm EDT.