If you’re using microservices, you’re already ahead of the game. Your engineering team is clearly pushing towards the cutting edge and your company is likely experiencing a period of fast growth. Yay?

As you know, microservice architecture, as useful as it is, comes with its own set of challenges. If you’re not sure your organization can scale without slowing down, you may have run into some of them.

Why the Trend Toward Microservices Makes Sense

Monolithic architectures have made way for lean microservices. With microservices, code is broken into independent services that run as separate processes. Output from one service is used as an input to another. Because a microservice typically has a single responsibility, each service can use its own language and framework and still work with other services. This gives teams the freedom to use the best technology for the job at hand.

With microservices, teams are also free to deploy changes independent of one another. As a result, teams are now able to employ continuous delivery and sometimes even continuous deployment.

No Need to Reinvent the Wheel - You Can Use External Tools

Teams are also increasingly integrating external 3rd party services into their workflows. These tools equip teams with industry-standard capabilities and allow the teams to focus on delivering business value.

It’s not uncommon to see teams using more than five external services. Some examples include:

Tool Capability
Github, Gitlab, Bitbucket Repository
CircleCI, TravisCI CI/CD
New Relic, Datadog Monitoring
Splunk, ELK Logging
PagerDuty, VictorOps Alerting
Rollbar, Sentry, RayGun Error Reporting

Distributed Teams

Teams are also becoming more distributed. Not only do we have companies where teams are located across the globe, but we are also increasingly seeing teams where individuals work from remote locations. Providing a flexible working arrangement allows companies to attract talent and build a more diverse workforce.

So What’s the Problem?

Your microservices could quickly start looking like this!

As teams and microservices scale, it becomes very easy to forget how your team’s changes will impact other services.

Teams tend to focus on their individual services and develop myopia. But that’s not necessarily their fault.

Usually, it’s a combination of factors that makes real-time coordination difficult: When services have breaking changes or need maintenance, service owners need to be tracked down, large meetings need to be held and some companies even resort to hiring full-time project managers whose only job is to manage this.

Diagnosing problems is also incredibly difficult. Engineers have to look at a series of logs, figure out which service is misbehaving, then figure out which team is responsible for that service and ask for help. The time to troubleshoot is directly dependent on the number of services and on the number of teams.

While microservices are supposed to be a solution for faster, more agile solutions, they can also easily bog down progress.

How Successful Companies Handle Microservices

Companies that have adopted microservices successfully have spent significant resources to make the transition smooth. They typically have built internal tools or have processes in place that address most of the following

  1. Maintain a centralized directory of services

We are not talking about service discoverability. Service discoverability is used to determine how to send a request to a service. We are talking about maintaining a directory where engineers can see which services are available and what each one of them does.

2. Maintain up-to-date documentation, runbooks and instructions for service diagnosis

Engineers often need to run micro-services in their local development environments. Having this information available and easily accessible saves everyone a lot of time. If this documentation is centralized, dev, qa and ops teams have less friction to deal with and can communicate better.

3. Maintain contact information for a service

It is important that teams associate stakeholders (engineers, product owners) with each service. This allows other engineers to contact the right people directly when they’re looking for details without wasting time trying to find out who the right stakeholders are. This is invaluable when diagnosing problems and a service owner needs to be contacted  for support. Larger organizations even maintain weekly on-call schedules for each service, so troubleshooting is easy.

4. Identify dependencies (direct and indirect) between services

Having a full set of dependencies, and being able to quickly add and remove dependencies, is a game-changer when it comes to using microservices. Companies struggle when they don’t incorporate this soon after they start using microservices. It becomes extremely hard to identify and track down dependencies later after the number of services and dependencies between them have grown.

5. Track changes being deployed so that engineers can quickly see what changed

One of the great promises about using microservices is that they are resilient and can be made fault-tolerant. As tooling and libraries have evolved, this promise has now become a reality. The root-cause of most outages on teams that use microservices is a bad code deploy or a bad configuration change. Successful companies focus on how to identify the root cause quickly and have tools in place that show all deployments being made. Some even have a quick way to see code changes for each deployment.

Fluxroll Takes Those 5 Success Factors & Makes Them Easy

We have learned from companies that are successfully using service-based architectures at scale and have built fluxroll to provide the common tooling and the organizational capabilities that have helped these companies to scale. It is easy to use, and even easier to integrate with your infrastructure.

We help companies:

  1. Move fast without breaking anything
  2. See everything across increasingly distributed environments
  3. Focus their teams on what drives the business

You can start using fluxroll by simply making a one line change to your deployment scripts.

Get your feet wet by onboarding a few services onto fluxroll. Dependencies can be added organically as you discover them. Over time you will build a knowledge graph that will be invaluable to your company as it scales.

If your microservice architecture and processes are slowing you down, schedule a fluxroll demo here