This is part of my live blogging from QCon 2015. See my QCon table of contents for other posts.

http://microservices.io – pattern language, best practices, etc

Gartner hype cycle

• Docker at peak of inflated expectations
• Node.js on it’s way down

How do we make decisions – elephant/rider analogy. The rider can try to direct the elephant, but it basically goes where want. The elephant is our emotions and the rider is our rational mind.

Pattern – reusable solution to a problem occuring in a particular context
Structure of a patern is a great framework for discussing and thinking about technology.

Structure:

• Name
• Context – the situation
• Problem
• Forces – issues need to address to solve problem; can conflict
• Solution
• Resulting context – consequences of using a pattern; includes drawbacks
• Related patterns – patterns that solve subproblems created by using pattern or related solutions to original problem

Pattern language – collection of related patterns – from Christopher Alexendar fom architecture

Core Patterns

• Monolithic architecture – traditional way of building an app, simple to develop/test/deploy/scale. Successful apps grow. Then have millions of line of code in one war file and beyond comprehension. No longer agile. Much fear. Infrequent deployments. Overloads IDE and container. Can’t scale. Too much coordination and communication required just to deploy. Fores into long term commitment to tech stack. Works really well on small apps because can move incredibly fast.
• Microservice architecture – apply functional decomposition – scale by splitting simiar things and/or different things and/or horizontal duplication. Amazon needs 100 microservices to render a page. Smaller/simpler apps. Lss jars/classpath hell. Easily and safely experiment with different techs. Opposite of release train. Low risk because small. Drawbacks: more complexity, inter-process communication, partial failure

Communication Patterns
What does client talk to when services distributed. API gateway is common to do request routing and API aggregation.
How do services with system communicate? Syncronous or messaging API?

Deployment Patterns

• Multiple Services per host – older approach. Like when servers were like pets and kept them alive forever efficient resource utilizatio, fast deployment, poor isolation, risk depenency version conflicts, can’t constrain resource use. Some benefits, but lots of downsides
• Single service per VM host – Netflix does this- great isolation/manageability, detailed metrics on resources using, resources constrained, less efficient resource utilization, slower deployment because creating new VM
• Service per container host – like Docker images, great isolation/manageability, container encapsulations implementation tech, efficient resource utilization because virtualizing OS. Fast deployment. Immature infrastructure for deploying containers

Discovery Patterns
For identifying microservices