Lightstep from ServiceNow Logo

Products

Solutions

Documentation

Resources

Lightstep from ServiceNow Logo
< all blogs

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.

March 24, 2020
4 min read
Microservices

Share this article

About the author

Talia Moyal
Microservices

Monoliths to Microservices: The Journey to Cloud Native

Jason Bloomberg | Sep 14, 2022

The path from earlier-generation monolithic architectures to today’s cloud native computing was a bumpy one. From REST-based SOA to microservices architectures to today’s hybrid cloud native architectures, we’ve learned many lessons along the way.

Learn moreLearn more
Microservices

Migrating to Microservices: Worst Practices

James Burns | Apr 28, 2020

The reality is that most migrations bog down quickly. This worst practices guide will tell you how you too can end up with a distributed monolith at the end of a multi-year long slog.

Learn moreLearn more
Microservices

Navigating microservices with OpenTelemetry

Austin Parker | Mar 17, 2020

This article discusses how microservices present a unique challenge. As a distributed system, they put up fences and boundaries around your services and teams that stymie traditional monitoring systems.

Learn moreLearn more
THE CLOUD-NATIVE RELIABILITY PLATFORM

Lightstep sounds like a lovely idea

Monitoring and observability for the world’s most reliable systems