Two of the biggest topics in QCon SF 2014 is reactive service and microservice architecture. Both reactive service and microservice goes hands in hand, you basically can’t build a good microservice systems without being reactive. I’ll start by looking into reactive service architecture and microservice architecture individually and then look into what reactive service architecture means in terms of microservice.
The goal is to build an application that user wants, in-sync data, real-time collaboration, instant feedback and not to wait. Nothing better to describe a reactive systems then the reactive manifesto itself.
Defined in the reactive manifesto, to build such a system, we will need to look into 4 traits: responsive, resilient, elastic and message driven.
So back to what a user wants, we’ll have to build a responsive system to user, and the way to get responsive is to be scalable and elastic. For everything to work, build on top of system that’s message driven.
BTW, hopefully by the end of the presentation, you’ll agree with the reactive manifesto and you can head over to the web site and sign it.
Microservice is to write programs that can be composed together. i.e. write program that do one thing and do it well and for those programs to work together.
Some of the interesting descriptions used over QCon are “Old wine in new bottle”, “Hipster of SOA”, “SOA on steroid”.
Microservice architecture can be thought of as a modern version of SOA, without all the bulky technology around SOA, like SOAP and WS-*, each service has a single responsibility (SRP – single responsibility principle.) Even though there’s no formal definition of microservice architecture style, but we can list out some of the common features.
- Each service should be simple and have a well-defined interface. It should only have one responsibility so development can be focused and addressed the need of that particular service verse in monolithic application, we often have to scarify part of the application (to use a sub-optimal database or framework) in the name of consistence.
- Services are modular and independent. Each can be developed on its own and can be deployed on its own thus providing the fullest expression of encapsulation and modularity.
- Relationships between services are more of a graph type than tiers.
- Polyglot and individual persistence, each service has its own persistence. It all depends on the use case of a services, it could be a NoSQL database, relational database or a graph database. And the persistence between the services should not be shared, each manage and own its own persistence.
- Technology changes rapidly, the best way to keep up with the changes is to build services that are “Strong opinionated, loosely held,” and as each service is small and independent, it would be easy to move on to another technology when required.
So the benefit of adopting microservice are:
- Each unit is simple
- Independent scaling and performance
- Independent testing and deployment
- Can optimally tune performance (caching, replication, etc)
Of course, it comes with a price:
- Many cooperating units
- Many small repos
- Requires more sophisticated tooling and dependency management
- Network latencies
We’ll try to address some of the drawbacks later in this document.
The most common choice of protocol between services is REST over HTTP and some choose Thrift but Java RPC doesn’t fit here because it’s difficult to maintain backward compatibility. By nature leads to Verb-centric APIs and Use case specific APIs, but we’d want to have APIs that’s more structural as use case specific API are very difficult to navigate the proliferation of APIs, difficult to know which API to use and in many cases, difficult to reuse the API and so we keep creating more and more APIs.
So, just by looking at the source code, we should be able to tell the team structure of the teams developed it. Thus our team structure should represent the microservice that we’re building. Google organized their team as “service” and 500px also organized corresponding to the services they are building. Here’s how a typical team should look like.
Small, focused teams
- Single service or set of related services
- Minimal, well-defined “interface”
- Layered on one another
- Self-sufficient and autonomous (freedom to choose technology, methodology and working environment, responsibility for the result of those choices)
- Give a team a goal, not a solution
- Let team own the service is the best way to achieve the goal