Thinking about Migrating to Microservices? Here’s Where to Start

You’ve heard the hype about microservices and you believe it may be the logical next step, but there are layers upon layers of questions rolling around. (Yes, this is a pun.) Where do I begin? When should I migrate over? Is it worth it? Migrating to microservices is not an easy decision, and one that shouldn’t be taken lightly.

To get a head start, here are the two main questions that should be answered before migrating to microservices.

Is your organization ready to migrate to microservices?

Most organizations, while technically able to deploy microservices, often struggle with the changes it brings to development team practices and operational responsibilities. Velocity increases alongside decoupled release cycles, but so does uncertainty about change. Adopting microservices can provide competitive advantage by getting features to customers faster but your entire organization needs to be ready for a DevOps / SRE mindset change. For a more in-depth understanding of how stress is added to developers and managers by migrating to microservices, check out How Deep Systems Broke ObservabilityHow Deep Systems Broke Observability.

Do microservices provide value to your team?

At a minimum there should be a clear benefit in one of the following areas for each opportunity to move to microservices:

• Deployability - make your application easier to deploy

• Functionality - make it easier and faster to get features out the door

• Reliability - make it easier to support the application and get back up and running if something goes wrong

• Portability - make your application easier to move from clouds and regions, and support the next way of modern infrastructures and practices

It may not make sense to be migrating your application. The above list should be applied to each opportunity as soon as you understand clearly where the service boundaries lie. This alone could be a challenge, depending on the age of your code, and how well the original framework was created.

Managing microservice deployments

After migrating to microservices, your number of deployments and service dependencies will naturally increase. How will this affect your day-to-day? In order to effectively scale deployments and manage dependencies without failures, services need to be deployed independently of each other. An increase in deployments and dependency failures may result in higher stress levels throughout the team.

There are tools, such as Service Health for DeploymentsService Health for Deployments, that enable you to automatically surface changes, pinpoint performance regressions, and provide the root cause of each regression. This provides direct visibility into any changes in latency, error rates, or throughput after your deployment. From here, you’re able to go directly to the specific, relevant traces or logs to help you fix issues quickly. If you’re interested in seeing how this works check our Interactive SandboxInteractive Sandbox.

Migrating to microservices: final thoughts

So let’s assume for example that you are already a SaaS-based application, which has very good object-oriented code (just one possible boundary identifier). Your service boundaries are clear and you already have a strong internal API for communicating across services. It is very likely that your application would be re-architected into being 90% microservices-based, with the remaining 10% being your backend, because application backends are not commonly containerized or turned into microservices.

You should seek to have as much of your application as microservices when there is a clear benefit. That is such an obvious statement. But, if for example, you see a benefit to converting to microservices and choose not to, the reason behind that decision is usually an indicator that there are some other challenges in your application architecture and infrastructure that should be addressed first. You should know very clearly why you have taken a pass on microservices for parts of your application; this could help guide some refactoring, or at the very least put a clear label on the decision for the future.

Interested in joining our team? See our open positions herehere.