The Redox Microservices Journey Part 2: Principles
For the first part in this series, see part one.
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:
- Read Building Microservices by Sam Newman (a great read by the way)
- Read every article on microservices.io
- Read a significant portion of Martin Fowler’s thoughts on microservices on his blog
- Attended multiple talks on microservices at conferences and universities
- Watched various videos from conferences on youtube
- And more
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.
- We’re developing a scaffolding project that engineers can use to quickly start coding new services.
- We’re building a communication and authentication framework that will hopefully make it very easy for services to communicate while still being secure
- 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
- Each microservice should be owned by a team
- Each microservice should define and own the infrastructure it needs to work
2. Strongly Cohesive / Loosely Coupled
Things that change together stay together; microservices should be autonomous.
- Each microservice should be independently deployable / changeable
- Each microservice should be independently scalable
- A failure in one microservice should not cascade to other services
- Each microservice owns its own data
3. API Driven
The internal implementation of a microservice should be hidden behind a developer friendly API.
- Any external communication with a microservice is exposed via a platform agnostic API
- Each API should be versioned
- Each API should conform to a set of standards to minimize variation between microservices
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.
Each microservice should follow a standard for logging data
- It should be possible to trace a request through each microservice it hits
- All logging data should be viewable in 1 location
Each microservice should follow a standard for monitoring
- Each microservice should expose a standard route for performing health checks
- There should exist an overall view of the system, including the health of each microservice
Each microservice should follow a standard for alerting
- Each microservice should generate alerts in the same way
- There should be 1 location where all alerts can be viewed
With many services, it's important that other developers can find the services they need, and quickly understand how to use them.
- Each microservice should have a standard place and format for documenting it's API
- Each microservice should have a name / description that is descriptive of what it is and why you might want to use it
- Each microservice should have a standard way for other microservices to locate it in our cluster
Oh, and if you’d like to help us in our microservices journey, we’re hiring!
The first employee to join Redox and join the cause for effortlessly sharing data with EMRs, TC has been shaping and building our modern API since the company's inception. He has always been passionate about solving “an incredibly difficult and urgent problem facing a very important industry”. When not enabling digital health solutions to easily achieve EHR integration, TC can be found playing basketball and spending as much time as possible outside. He enjoys hiking in the mountains with his wife, Allison, outside their home in Fort Collins, Colorado.