Eat Your Microservices Elephant One Bite at a Time

© 2015 Akana., Inc All Rights Reserved. Powering the API Economy

MicroservicesWhat, Why, & How?


What are Microservices?

• Microservices are a new way to build applications by breaking them up into small, independent, individual services

• No specific language• No heavy middleware (Websphere, Tibco, Oracle are all scrambling)• Mostly open-source

Loosely coupled service oriented architecture with bounded contexts -‐ Adrian Cockcroft

Small autonomous services that work together -‐ Sam Newman


Pivotal/Netflix Microservices Architecture


What defines a Microservice?

SOA + DevOps + Containers


SOA vs SOA• Vendor-driven SOA gave us SOAP and ESBs• Microservices are a reaffirmation of SOA principles and a reaction to

vendor-driven SOA– dovetail in agile– dovetail in devops– dovetail in domain-driven design / BASE

• Microservices is unabashedly anti ESB


What is DevOps?• The developer interacts with the infrastructure directly• Need fewer Operations staff – saves money• Increases agility by removing roadblocks

Develop' Test' UAT' Operate'

IDE$ Build$Tools$ Test$Suite$

Dev$Cloud$

Blueprint*

Web$Servers$App$

Servers$

Database$Servers$

Load$Balancer4$

Firewall$

Master$ Slave$

QA$Cloud$

Blueprint*

Web$Servers$App$

Servers$

Database$Servers$

Load$Balancer4$

Firewall$

Master$ Slave$

Load$Balancer$

Release$Management$

Blueprint*Web$Servers$

App$Servers$

Database$Servers$

Load$Balancer$

Firewall$

Master$ Slave$

Ready$for$Produc;on$

Common$Applica;on$Pla?orm$IT'Opera1ons'


What is Containerization?

• Easier to use• More efficient• Smaller – hence

suited to Microservices


Microservices Architecture• Been in use for a few years - Netflix, Gilt, Pivotal - term shows up in linux

microkernel discussions (1992)• Principles+ documented by Fowler & Lewis 03/2014 :

http://martinfowler.com/articles/microservices.html• Architecture - tradeoffs and capabilities• SOA vs. SOA (vendor-driven vs. microservices)

– Drivers: Scalability, Conway’s Law, Composition of focused services, agility of development frameworks (spring, ror, node, etc.)


Microservices Principles1. Componentization via services [best technology for the job, common interface

(restish)]2. Organized around Business Capabilities3. Products not Projects [Conway’s law of organizational slippery slope]4. Smart endpoints dumb pipes [choreography vs. orchestration; choreographer

leads]5. Decentralized Governance [built into the service - share useful patterns via

libraries; less overhead; consumer-focused service contracts]6. Decentralized Data Management [domain driven design bounded context, etc.]7. Infrastructure Automation8. Design for Failure9. Evolutionary Design


Additional Guidance• Two-pizza teams • Microservices are highly focused on providing one capability - micro

means singly focused, not size• Microservices have their own lifecycle• Lightweight communication protocols• Right tool for the job• Microservices should have their own datastore separate from other

microservices• Design for failure• Microservice owners responsible for full lifecycle (incl deploy and

operations)


Why are Microservices so popular?

• Slow• Unscalable• Hard to manage

• Faster• Scalable• Easier to manage


How hard is it to adopt Microservices?• Requires 4 things:

– Maturity of ops (need DevOps, Containerization)– Willing to re-architect entire app (maybe)– Willing to invest in the App – must be strategic– App must need Internet scale


Incremental Adoption


Parallel Invocation


What are SOA, APIs and Microservices used for• SOA – is about reuse

– Building services that support multiple different application• APIs – are about supporting web and mobile applications – its about

integration– Geared towards easier and better consumption of services

• Microservices – are about agility and scale– Services enabling scalability and rapid feature cadence for a specific

application


Considerations• Impacts to Design• Impacts to Development• Impacts to Testing


Design• Traditional design oversight is out the window - everyone will use the best

tools available to create the microservice - Govern at the interface• Design request for other interfaces - design-time review of available

interfaces• Design for failure - services should provide health status• Design for robustness - services can self-proxy• Adopt convention - interface must provide for health/resiliency information• Distributed data design - domain-driven design patterns


Development• Development team must know about other available interfaces, etc. -

tooling• Development team must know what libraries, strategies, patterns will

provide for resiliency, health, bulkheads, alternatives• Development team will get to know a lot more about the SDLC before them

and after - full lifecycle responsibility• Development team - agile here with QA intimately involved• Distributed data management requires eventual consistency

accommodation


Testing• Testing at the unit level still exists -

development team’s responsibility• Testing at the integration level still exists -

development team’s responsibility• Testing tools will have to account for new

paradigms for microservices - registry, health dashboard - and build in these scenarios

• Testing inside the service - Delivery as testing

• martinfowler.com/articles/microservice-testing/


How to get there from here• Greenfield development is great, go do it!• Transitioning to microservices isn’t as easy

– Breaking up a monolith requires discipline– Hardest part will probably be separating the data – moving joins to the services

layer and out of the DB– Geographic distribution is still not easy – sharding at the application layer


The Akana Platform in Transition - Original


The Akana Platform in Transition – Phase 1


The Akana Platform in Transition – Phase 3


The Akana Platform in Transition - Final


Questionswww.akana.com

Technology

Eat Your Microservices Elephant One Bite at a Time