Anticipating the fallacies of distributed computing with the Netflix OSS


As presented @ Computer Futures Talks

Session Content

Code

  • The code used to demo: Examples of Hystrix and Archaius can be found in the unit tests. See it on Github
  • A working example of microservices using Spring Cloud. See it on Github

Session Q&A

(IN MICROSERVICES) HOW DO YOU DO VERSIONING? HOW DO YOU MAKE SURE AN UPGRADE DOESN’T BREAK CONSUMERS?

This is a complicated questions which deserves a conferences session in itself.

For our API Definitions, we use Swagger. This gives a clear view of what capabilities an API offers. It also contains a version number (semantic versioning) but that is where the real question pops up. “When is something a breaking change?” It is a good idea to make the rules very explicit. Some examples:

  • Adding a new field?: Not a breaking change. We expect our consumers to have tolerant readers (ignore extra fields). (Minor version)
  • Field changes name?: Breaking change. (Major version)
  • Field changes type?: Breaking change. (Major version)
  • Description changed?: Not a breaking change. (Patch version) Unfortunatly, it is very hard to automatically enforce these rules. It also generates a lot of other questions:

It generates a lot of versions in the early stages of the API You do not know exactly which consumers you are going to break with a change. There is not detailed contract being discussed between 2 parties To avoid these issues, the industry has started to embrace Consumer Driven Contracts. It’s a big mental change for most companies, but it does seem to pay off. Allow consumers to create contracts which can be validates at build time by the producers of an API. We use Pact for this. It has a good ecosystem around it so it goes beyond just the contracts.

HOW DO YOU RUN PERFORMANCE TESTS?

We usually use Gatling at our projects. It is easy to setup and you can write your performance tests in code.

Pictures