Engineering

Redox Microservices Journey Part Two, Principles

Posted December 5, 2017
By TC

Before designing a single service or writing a single line of code for microservices, it’s important to be clear on the problems you’re trying to solve, and the end state for which you’re shooting. At Redox, this end state took the form of a list of principles that we want to adhere to as we create our microservice environment.

At Redox, the main problem we’re trying to solve is developer productivity. We’re excited about all the other benefits of microservices, but to be honest, if it weren’t for the gains we’re expecting to get with developer productivity, we may not have started the transition at all.

With that in mind, we went about developing a set of principles for microservices, keeping in mind that the way we develop microservices should match the way we want to work as a set of small teams, while continuing to meet the needs of our product.

Developing a set of principles is not necessarily something you just sit down and write out. Before even starting the conversation, individuals at Redox had done the following:

No one did all of those things, but as a team, we did our research as best we could.

With a decent amount of research done, we started the process of documenting our principles. I took a first pass at writing down the outcomes I felt like we were looking for. Once I had a draft, I grabbed a group of about 5 engineers, spanning the different small teams we have, and we discussed, edited, added and removed things from the list, until we decided on what we have below.

This list of principles is not set in stone. Rather, it is a direction that we can start moving in. As we learn more, we can adjust as necessary.

We have 3 major next steps in progress now that we have our principles.

  1. We’re developing a scaffolding project that engineers can use to quickly start coding new services.
  2. We’re building a communication and authentication framework that will hopefully make it very easy for services to communicate while still being secure
  3. We’re making some decisions around how we want to organize our code for all our services. Specifically, we’re looking at whether to use a monorepo or separate repositories per service.

We’ll publish blog posts on each of those as we make some decisions and have some learnings.

With all that said, here are the five current Principles of Microservices at Redox.

1. Full Ownership

2. Strongly Cohesive / Loosely Coupled

Things that change together stay together; microservices should be autonomous.

3. API Driven

The internal implementation of a microservice should be hidden behind a developer friendly API.

4. Observable

With many services working together, observability is key. There must be standard ways to assess / monitor the health of the system and a given service.

Logging – Each microservice should follow a standard for logging data

Monitoring – Each microservice should follow a standard for monitoring

Alerting – Each microservice should follow a standard for alerting

5. Discoverable

With many services, it’s important that other developers can find the services they need, and quickly understand how to use them.

So, these are the principles we’ve landed on to help guide us through this process. Over the course of the next few weeks, we’ll see how they play into how we work, how we make decisions, and how we move faster as a team to get more awesome stuff done.

Oh, and if you’d like to help us in our microservices journey, we’re hiring!