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
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
- It should be possible to trace a request through each microservice it hits
- All logging data should be viewable in 1 location
Monitoring – 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
Alerting – 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
5. Discoverable
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
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!