mucon 2014 "building java microservices for the cloud"

Building Java (micro)services for the CloudThe DHARMA principles

Daniel BryantPrincipal Consultant, Open Credo

[email protected]@danielbryantuk

Who Am I?

• London Java Community Associate

• Adopt OpenJDK and JSR

27/11/2014 @danielbryantuk

• Principal Consultant at OpenCredo

Agile transformations

DevOps methodologies

Microservices and Cloud

The Current Industry Wish List…

• Service-Oriented Architecture

• Cloud-based deployments

• DevOps Culture

@danielbryantuk27/11/2014

The Current Industry Wish List…

• Service-Oriented Architecture (microservices)

– Today!

• Cloud-based deployments

– Today!

• DevOps Culture

– “Moving to DevOps” @ DevoxxUK bit.ly/1BylnZb

@danielbryantuk27/11/2014

http://bit.ly/1BylnZb

The obligatory microservice definition…


Microservices…

• “SOA done right”

• “SRP” services– “Java, The Unix Way” (bit.ly/1cX8VsS)

• “Small” codebase services – 1000 LOC… 100… 10…?

• My personal opinion…


http://bit.ly/1cX8VsS

“Can I fit the service in my head?”


Common Cloud Problems

TL;DR…



Not respecting the underlying environment


Lack of application/platform monitoring…


Bizarre failure modes…

Three certainties in life: Taxes, death and failure in production…


Difficulty in understandingthe new architecture


Confusion over environment provisioning and config


Not testing in the Cloud…(hint: here be dragons!)

We’ve created the “Cloud DHARMA Principles” to act as a checklist when building Cloud apps


dharma/ˈdɑːmə,ˈdəːmə/

noun

1. Signifies behaviors that are considered to be in accord with order that makes life and universe possible (Hinduism)

2. "cosmic law and order”, but is also applied to the teachings of the Buddha (Buddhism)


Documented (just enough)

Highly cohesive/loosely coupled (all the way down)

Automated from commit to Cloud

Resource aware

Monitored thoroughly

Antifragile


Documentation (just enough)

• Provide a map for developers (and QA, Ops)

• Component purpose and interface/contract

• Initialisation instructions (mocks/stubs)

• Highlight areas of operational risk


27/11/2014 @danielbryantuk27/11/2014 @danielbryantuk

leanpub.com/software-architecture-for-developers

https://leanpub.com/software-architecture-for-developers

Simon Brown’s C4 Model


@simonbrownwww.codingthearchitecture.com

https://twitter.com/simonbrown

API Docs with Swagger


helloreverb.com/developers/swagger

https://helloreverb.com/developers/swagger

Create a PACT


github.com/DiUS/pact-jvm

martinfowler.com/articles/consumerDrivenContracts.html

https://github.com/DiUS/pact-jvm

http://martinfowler.com/articles/consumerDrivenContracts.html




Resource aware


Antifragile


High Cohesion / Loose Coupling(all the way down…)

“Fit for purpose architecture,

throughout the system”

1. Architect for encapsulation

2. Architect for scalability

3. Architect for comprehension


Encapsulation: High Cohesion/Loose Coupling

• Code

• Modules– Components (bit.ly/1n7D0vp)– Services (bounded contexts)

• Public APIs– PayPal (bit.ly/1hnZNly)

• Deployment– 12factor.net


http://bit.ly/1n7D0vp

http://bit.ly/1hnZNly

http://12factor.net/

Are Microservices a Silver Bullet?

• Single Responsibility Principle– Enforce service boundaries

– Bounded contexts (DDD)

• Separation of Concerns– Encapsulate what varies

– Easier to scale/tune independently

• Is this a free-lunch? (bit.ly/1gSw4L7)


http://bit.ly/1gSw4L7

No!! Keep searching…

It’s all too easy to push complexity into orchestration and communication


www.codingthearchitecture.com/2014/07/06/distributed_big_balls_of_mud.html

http://www.codingthearchitecture.com/2014/07/06/distributed_big_balls_of_mud.html

Scalability: The Three Ways


The Scaling Cube


The Scaling Cube


Cloning / ReplicationYou’re overly successful(and in trouble!)

Easy to implementCostly to run

Splitting aka ‘Microservices’Scaling requirements vary by ‘service’Rate of code change varies by ‘service’Uber-flexible distribution/scalingModeling & implementation non-trivial!

ShardingScaling requirements vary by data Current data store unit at capacityCan be non-invasiveThe decision of what to shard on?

Comprehension: Smashing the Monolith…

• Business functionality -“Cart Service”– Noun, verb, SRP (slidesha.re/1owdJhh)

• Technology chunk - “Email Service”

• Vertical Slice - “Service per page” – Groupon (vimeo.com/105880150)

• Horizontal Slice - “User Repo” – An anti-pattern?


http://slidesha.re/1owdJhh

https://vimeo.com/105880150

DZone’s Enterprise Integration Guide


dzone.com/research/guide-to-enterprise-integration

http://dzone.com/research/guide-to-enterprise-integration




Resource aware


Antifragile


Automated from Commit to Cloud


• Continuous Integration

• Continuous Deployment

• Continuous Delivery

Build Pipeline

• Component Build

– Compile

– Unit Tests e.g. Maven Surefire

– Integration Tests (in-process) e.g. Maven Failsafe

• Deployment onto QA Cloud

– Probe health check endpoints

– Serverspec serverspec.org


http://serverspec.org/

Build Pipeline

• Acceptance Tests– Cucumber (and Webdrivers)

– Use a Cloud environment!

• Performance Tests– Jmeter + Jenkins performance plugin

– Make sure environment and data is realistic!!

• Live Deployment?


Microservice Pipeline

If you can’t deploy a service individually,

you’re probably aren’t creating ‘microservices’

Beware of the distributed monolith

“If you can't build a monolith, what makes you think microservices are the answer?”

@simonbrown bit.ly/1n7D0vp


http://bit.ly/1n7D0vp

Infrastructure: Say No To Snowflakes!

• Automate all provisioning (store in SCM)

• Link infrastructure code to service

– Take care with versioning service/infra code

• Approaches…

– Separate infra repo (tagged with service version)

– Include in service repo (e.g. DockerFile)



• Fry...

– Chef, Puppet, SaltStack, Ansible

– Bash, Python (Fabric)

– Vendor APIs

• …or bake?

– Packer.io

– Netflix Aminator



• Doing “Proper Development”

– Gareth Rushgrove at Craft Conf (bit.ly/1njuc49)

– Chef Conf (www.youtube.com/user/getchef)

• Local tooling/testing

– Vagrant (www.vagrantup.com)

– Docker (www.docker.io)

– Fig (www.fig.sh)


http://bit.ly/1njuc49

http://www.youtube.com/user/getchef

http://www.vagrantup.com

http://www.docker.io

Configuring Apps in the Cloud

• Bundle config with app artifact

– Re-deploy entire app on change (easier with Docker?)

• Inject to app container on demand

– Deploy new local config file with each change

• Store externally

– Zookeeper & Curator curator.apache.org

– etcd github.com/coreos/etcd


http://curator.apache.org/

https://github.com/coreos/etcd

Automating QA

• Intra-component integration testing– Utilise embedded datastore/middleware

– Cucumber (typically via API/Webdriver & Serenity)

– Consider test UI for exploratory testing?

• Fault-tolerance– Chris Batey’s Skillscast (bit.ly/1tU6wZj)

– WireMock + Saboteur (wiremock.org)

– “Scassandra” (github.com/scassandra)


http://bit.ly/1tU6wZj

http://wiremock.org/

https://github.com/scassandra

Automating QA

• Inter-component integration testing

– The hardest part of SOA…

– Consider ‘synthetic txns’ (active monitoring)

– Consumer-driven Contracts github.com/DiUS/pact-jvm

• Service virtualisation

– VCR and Betamax (github.com/vcr/vcr)

– Mountebank (www.mbtest.org)

– Mock external services (e.g. Spring profiles)


https://github.com/DiUS/pact-jvm

https://github.com/vcr/vcr

http://www.mbtest.org

QA: Further Inspiration


Toby Clemson @ martinfowler.com/articles/microservice-testing

http://martinfowler.com/articles/microservice-testing/

Security: The Forgotten Part of QA

• Test credentials during automated acceptance– Target third-party integration points

• OWASP top ten– Zed Attack Proxy (bit.ly/1fjloVy, bit.ly/11Og39A)– Exploratory (penetration testing)

• Stand on the shoulders of giants– Creating your own crypto is not ‘cool’– Neither is inventing a ‘new’ security algorithm


http://bit.ly/1fjloVy

http://bit.ly/11Og39A




Resource aware


Antifragile


Deployment Platform: What you’ve got…


What you think you want…


What you actually get…


Fact: 9 out of 10 cheetahs prefer thetaste of an Ops team over tinned food

Thou Shalt Know they Cloud…

“Everything fails all the time [in the cloud]”

Werner Vogels, CTO, Amazon.com

• Everything is ephemeral

• Volatility

• Noisy (virtual) neighbours– bit.ly/1w1HQy7


http://bit.ly/1w1HQy7

Thou Shalt Know thy Cloud…

• AWS “Magnetic” EBS 100 IOPS

– New SSD EBS 3K IOPS (burst, PIOPS available)

– My Mac SSD does 49K IOPS

• 1000Mbps network max transfer ~125MB/s

– My Mac does 400+ MB/s Sequential Write to SSD

Reference for Mac statistics: bit.ly/1ftJZH8


http://bit.ly/1ftJZH8

Cultivating “Mechanical Sympathy”

• Understand the underlying Cloud fabric

• Virtualisation

– Tech Target (bit.ly/1kDVqyG)

• Networking

– ‘Unix and Linux System Administration Handbook’

– AWS docs aws.amazon.com/documentation


http://bit.ly/1kDVqyG

http://aws.amazon.com/documentation/

Mechanical Sympathy by the Numbers


www.eecs.berkeley.edu/~rcs/research/interactive_latency.html

http://www.eecs.berkeley.edu/~rcs/research/interactive_latency.html

Thinking/Acting Operationally

• You write it, you run it… (“dev on call”)

• Learn Linux fundamentals

• Diagnostic skills

– top, netstat, vmstat, tcpdump

– Java utils: jps, jstat, jmap, jhat

– “DevOps Troubleshooting” by K. Rankin





Resource aware


Antifragile


Monitor All The Things!

• Infrastructure monitoring– Nagios / Zabbix

– New Relic / AppDynamics

• Distributed Tracing – twitter.github.io/zipkin

• Centralised Logging– logstash.net


http://twitter.github.io/zipkin/architecture.html

http://logstash.net/

The ‘ELK’ Stack


blog.comperiosearch.com/blog/2014/08/14/elk-one-vagrant-box

http://blog.comperiosearch.com/blog/2014/08/14/elk-one-vagrant-box/

Component Metrics


• Dropwizard’s Metrics– metrics.codahale.com

– Spring Boot (bit.ly/1rGo76V)

• Netflix’s Servo– github.com/Netflix/servo

• Etsy’s StatsD– github.com/etsy/statsd/wiki

http://metrics.codahale.com

http://bit.ly/1rGo76V

http://github.com/Netflix/servo

https://github.com/etsy/statsd/wiki

Health Checks


Gauges, Counters, Meters, Timers…


Graph It!


dashing.io

http://dashing.io/


Phrase borrowed from Etsy!




Resource aware


Antifragile


Antifragile

• The opposite of fragile?

– Robust…

– Antifragile…

• Netflix are best-in-class

– bit.ly/1gs5n3q

• System must be robust first!


http://bit.ly/1gs5n3q

Design for Failure

• Distributed Computing Principles

– Jeff Hodges ‘Distributed Systems’ (bit.ly/1FeaVtt)

– Scalable Web Architecture (bit.ly/1tt703O)

– ‘For young bloods’ (bit.ly/1pKVepz)

• Design patterns

– Timeouts / retries

– Bulkheads / circuit-breakers


http://bit.ly/1FeaVtt

http://bit.ly/1tt703O

http://bit.ly/1pKVepz

Timeouts


docs.guava-libraries.googlecode.com/…/concurrent/SimpleTimeLimiter.html

http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/util/concurrent/SimpleTimeLimiter.html

Retries


github.com/rholder/guava-retrying

https://github.com/rholder/guava-retrying


github.com/Netflix/Hystrixprojects.spring.io/spring-cloud/

Circuit-breaker/bulkhead

https://github.com/Netflix/Hystrix

http://projects.spring.io/spring-cloud/

Antifragile Patterns: Elastic Scaling

• Scalability Rules

– Design for scaling: D 30x, I 3x, D 1.5x

– Strive for statelessness

– Cache appropriately (and on own tier)

– Expose load metrics

– Separate deploy and release

– Favour async communication

– Avoid coordination and ACID


Antifragile Patterns: Elastic Scaling

Stateless components

Distributed data stores / caches


• Asynchronous Communication

– Message queue www.rabbitmq.com

– Pub/sub redis.io

• Take it to the next level

– Reactive github.com/ReactiveX/RxJava

– CQRS/ES martinfowler.com/bliki/CQRS.html

Antifragile Patterns: Async FTW


http://www.rabbitmq.com/

http://redis.io/

https://github.com/ReactiveX/RxJava

http://martinfowler.com/bliki/CQRS.html

Antifragile Patterns: Respect the CAP

Eventual consistency (ACID vs BASE)


en.wikipedia.org/wiki/CAP_theoremcloudshankar.blogspot.co.uk/2013/05/eventual-consistency.htmlwww.dataversity.net/acid-vs-base-the-shifting-ph-of-database-transaction-processing/

http://en.wikipedia.org/wiki/CAP_theorem

http://cloudshankar.blogspot.co.uk/2013/05/eventual-consistency.html

http://www.dataversity.net/acid-vs-base-the-shifting-ph-of-database-transaction-processing/




Resource aware


Antifragile


So, Cloud services are ‘done’ when…

Thanks For Listening!

• Massive thanks

– OpenCredo (@OpenCredo)

– www.notonthehighstreet.com

• Questions / comments?

– [email protected]

– @danielbryantuk


https://twitter.com/OpenCredo

http://www.notonthehighstreet.com

mailto:[email protected]

https://twitter.com/danielbryantuk

mucon 2014 "building java microservices for the cloud"

Technology

danielbryantuk encapsulation

danielbryantuk confusion

danielbryantuk difficulty

danielbryantuk documentation

danielbryantuk api docs

way downautomated

cloud apps

purpose architecture