DevOxx 2015 Notes

7 sins of microservices

* Twin definitions of µServices.  adrianco's and James Lewis's
* Monoliths might be faster to develop and deploy.  Get business model verified, then worry about the architecture.

## Lust
* Suggesting that lust is about developers wanting one of every new tech, and therefore going to microservices because it's new and shiney.  Referencing the Mckinley blog post about choosing boring technology.
* Turn up to organisations and ask why are you using tech X, dont know is often the asnwer
* 

## Gluttony
* Lots of different protocols, message queues etc.
* Don't gold plate, chose one synchronous protocol, e.g. Json over HTTP
* Choose one async protocol e.g. RabbitMQ maybe
* Know your options, do you need Thrift, RPC, etc?  Maybe, but pick one and use it everywhere

## Greed
* How amny microservices, and what areas are you looking at?
* Conways law
* Often siloisation, lack of joint accountability
* Fundementally all working to the same goal, the furtherance of the company
* There's often silos inside the silos as well, maybe frontend developers and backend developers.
* Toxic environments in which people are afraid to speak up out of their silo.
* Cross functional teams can help deal with this.  See Spotify, Amazing and Gilt.
* Conway was telling the truth.  Connected Company by Dave Gray.  The modern firm, On change management

## Sloth
* DEploying independantly
* Seperate deploy and release if possible
* Schema designs.  
* Contracts between services.  
  * APIDoc from Gilt.
  * Consumer driven contracts
  * PACT
  * Downsides, contracts can be fragile.  If things change, all kinds of stuff might break.
* Architecture is not a dirty word.
  * It's not about ivory tower
  * But about leadership and communication
  * Just enough up front design

## Wrath
* Blowing up when bad things happen
* they fundementally a dsitributed system
* A lot of organisations don't realise that
  * Now you are subject to the 8 fallacies of distributed computing
* Bring in Nygard for the team and bring in simian army/monkeys to test your resiliance
  * Release It talks about the patterns
  * You have to code more defensively in a distirbuted environemnt
  * Operaitonally you need to test it as well
  * Hence the simian army.
* Continuous delivery as a prequisite for microservices
  * Rapid provisioning and monitoring
  * Be agile about your infrastructure
* Failure happens all the time, so expect it
  * Get used to it
  * Do game days, recovery testing
  * Failure injection
  * Who gets paged and called, what happens?
* Share the pain
  * Airbags can cause worse driving because people feel safer
  * Maybe we can replace it with a spike, people would drive more carefully
  * Developers on call is like having spikes.  Sharing the pain with the development team
  * Shared responsibility and shared communication
  * You write it, you run it

## Envy
* The shared single domain fallacy
* Clients spent years perfecting their single domain
* e.g. How do I generate reports?
* Aggregated reorting patterns, data pumps like event sourcing.
* Do I have to do joins over HTTP to do reports over multiple microservices?

## Pride
* Testing strategies in microservices
* Is there enough information on how you test your microservices?
* there are no exact rules to follow yet
* Testing is difficult
* Invest in your build pipeline testing
  * Serenity BDD - wrapper around selenium
  * Wiremock
  * Saboteur for testing failure conditions
  * Jenkins perf plugin, say jmeter or gatling results being graphed
* Testing in production
  * Netflix and Gilt are doing this stuff
  * This is an advanced pattern