Schema registries and microservices - Takeaways from SpringOne Platform (part 2)

This is the second in a couple posts on my observations and takeaways from my first time at SpringOne Platform. The first one was here. 

Between Spring Boot and Spring Cloud Services, microservices are a big topic at Pivotal and here at SpringOne Platform. Another question that has occasionally come up for me is, “What are the implications for data in a microservices architecture?”. I know that that is a big question - daunting, in fact, to try to answer amidst a sea of opinions. But I was excited to catch Vincius Carvalho’s (@vccarvalho) talk at SpringOne to help illuminate this topic a bit more.

There are number of interesting implications for data in a continuously delivered microservices architecture:

1. If each microservice has it’s own datastore, there is potential for redundant data. How do we resolve that?
2. If we have multiple services sharing the same data model, how can each smaller, agile team iterate?
3. If you are running multiple versions of software, for blue-green deployments for example, there may be incompatible changes to the data model between those two versions. How do you solve for that?

Again, I can’t claim to have all the answers, but I found Vincius’ talk on schema registries useful. Just as CQRS separates the responsibilities for writing data and reading data, the schema registry separates the responsibility of storing schemas and storing data. The responsibilities of the schema registry are:

1. Storing schemas
2. Testing compatibility - adding fields, for example, is usually easily compatible; whereas removing or renaming fields can be a breaking change
3. Tracking utilization

I’m not sure how broadly known or adopted this concept is - the room at SpringOne was packed. I can find other discussions out there on the topic, including this one from Confluent. But I think what Vincius is working on is interesting in that it is part of the rich ecosystem of Spring.

Resources:

• Vincious’ slides from a similar presentation earlier this year
• Vincious recommends Martin Kleppman’s Designing Data Intensive Applications
• GitHub repo for schema evolution samples