Building microservices for the Cloud is easy, right?... Perhaps, but if you want to build effective and reliable services that not only work correctly within the Cloud, but also take advantage of running within this unique environment, then you might be in for a surprise. This talk will introduce lessons learnt over the past several years of designing and implementing successful Cloud-based Java applications which we have codified into our Cloud development ‘DHARMA' principles; Documented (just enough); Highly cohesive / lowly coupled (all the way down); Automated from commit to cloud; Resource aware; Monitored thoroughly; and Antifragile.
We will look at these lessons from both a theoretic and practical perspective using several real-world case studies involving a move from monolithic applications deployed into a data center on a 'big bang' schedule, to a platform of JVM-based loosely-coupled components, all being continuously deployed into the Cloud. Topics discussed will include API contracts and documentation, architecture, build and deployment pipelines, Cloud fabric properties, monitoring in a distributed environment, and fault-tolerant design patterns.
This presentation was delivered at muCon 2015 on 27/11/14, the microservice conference. The video can be seen here: https://skillsmatter.com/skillscasts/5938-developing-java-services-for-the-cloud
Streamlining Python Development: A Guide to a Modern Project Setup
Building Java Microservices Cloud
1. Building Java (micro)services for the Cloud
The DHARMA principles
Daniel Bryant
Principal Consultant, Open Credo
daniel.bryant@opencredo.com
@danielbryantuk
2. Who Am I?
• Principal Consultant at OpenCredo
Agile transformations
DevOps methodologies
Microservices and Cloud
• London Java Community Associate
• Adopt OpenJDK and JSR
27/11/2014 @danielbryantuk
3. The Current Industry Wish List…
• Service-Oriented Architecture
• Cloud-based deployments
• DevOps Culture
27/11/2014 @danielbryantuk
4. The Current Industry Wish List…
• Service-Oriented Architecture (microservices)
– Today!
• Cloud-based deployments
– Today!
• DevOps Culture
– “Moving to DevOps” @ DevoxxUK bit.ly/1BylnZb
27/11/2014 @danielbryantuk
14. Not testing in the Cloud…
(hint: here be dragons!)
27/11/2014 @danielbryantuk
15. We’ve created the “Cloud DHARMA Principles”
to act as a checklist when building Cloud apps
27/11/2014 @danielbryantuk
16. 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)
27/11/2014 @danielbryantuk
17. Documented (just enough)
Highly cohesive/loosely coupled (all the way down)
Automated from commit to Cloud
Resource aware
Monitored thoroughly
Antifragile
27/11/2014 @danielbryantuk
18. Documented (just enough)
Highly cohesive/loosely coupled (all the way down)
Automated from commit to Cloud
Resource aware
Monitored thoroughly
Antifragile
27/11/2014 @danielbryantuk
20. 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 @danielbryantuk
24. API Docs with Swagger
27/11/2014 @danielbryantuk
helloreverb.com/developers/swagger
25. API Docs with Swagger
27/11/2014 @danielbryantuk
helloreverb.com/developers/swagger
26. Create a PACT
27/11/2014 @danielbryantuk
github.com/DiUS/pact-jvm
martinfowler.com/articles/consumerDrivenContracts.html
27. Documented (just enough)
Highly cohesive/loosely coupled (all the way down)
Automated from commit to Cloud
Resource aware
Monitored thoroughly
Antifragile
27/11/2014 @danielbryantuk
28. 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
27/11/2014 @danielbryantuk
30. 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)
27/11/2014 @danielbryantuk
31. 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
27/11/2014 @danielbryantuk
34. The Scaling Cube
Splitting aka ‘Microservices’
Scaling requirements vary by ‘service’
Rate of code change varies by ‘service’
Uber-flexible distribution/scaling
Modeling & implementation non-trivial!
Cloning / Replication
You’re overly successful
(and in trouble!)
Easy to implement
Costly to run
27/11/2014 @danielbryantuk
Sharding
Scaling requirements vary by data
Current data store unit at capacity
Can be non-invasive
The decision of what to shard on?
37. Documented (just enough)
Highly cohesive/loosely coupled (all the way down)
Automated from commit to Cloud
Resource aware
Monitored thoroughly
Antifragile
27/11/2014 @danielbryantuk
38. Automated from Commit to Cloud
• Continuous Integration
• Continuous Deployment
• Continuous Delivery
27/11/2014 @danielbryantuk
39. 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
27/11/2014 @danielbryantuk
40. 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?
27/11/2014 @danielbryantuk
41. 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
27/11/2014 @danielbryantuk
42. 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)
27/11/2014 @danielbryantuk
43. Infrastructure: Say No To Snowflakes!
• Fry...
– Chef, Puppet, SaltStack, Ansible
– Bash, Python (Fabric)
– Vendor APIs
• …or bake?
– Packer.io
– Netflix Aminator
27/11/2014 @danielbryantuk
44. Infrastructure: Say No To Snowflakes!
• 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)
27/11/2014 @danielbryantuk
45. 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
27/11/2014 @danielbryantuk
47. 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)
27/11/2014 @danielbryantuk
48. QA: Further Inspiration
Toby Clemson @ martinfowler.com/articles/microservice-testing
27/11/2014 @danielbryantuk
49. 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
27/11/2014 @danielbryantuk
50. Documented (just enough)
Highly cohesive/loosely coupled (all the way down)
Automated from commit to Cloud
Resource aware
Monitored thoroughly
Antifragile
27/11/2014 @danielbryantuk
53. What you actually get…
Fact: 9 out of 10 cheetahs prefer the
taste of an Ops team over tinned food
27/11/2014 @danielbryantuk
54. 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
27/11/2014 @danielbryantuk
55. 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
27/11/2014 @danielbryantuk
56. 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
27/11/2014 @danielbryantuk
57. Mechanical Sympathy by the Numbers
www.eecs.berkeley.edu/~rcs/research/interactive_latency.html
27/11/2014 @danielbryantuk
58. 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
27/11/2014 @danielbryantuk
59. Documented (just enough)
Highly cohesive/loosely coupled (all the way down)
Automated from commit to Cloud
Resource aware
Monitored thoroughly
Antifragile
27/11/2014 @danielbryantuk
60. Monitor All The Things!
• Infrastructure monitoring
– Nagios / Zabbix
– New Relic / AppDynamics
• Distributed Tracing
– twitter.github.io/zipkin
• Centralised Logging
– logstash.net
27/11/2014 @danielbryantuk
61. The ‘ELK’ Stack
blog.comperiosearch.com/blog/2014/08/14/elk-one-vagrant-box
27/11/2014 @danielbryantuk
68. Documented (just enough)
Highly cohesive/loosely coupled (all the way down)
Automated from commit to Cloud
Resource aware
Monitored thoroughly
Antifragile
27/11/2014 @danielbryantuk
69. Antifragile
• The opposite of fragile?
– Robust…
– Antifragile…
• Netflix are best-in-class
– bit.ly/1gs5n3q
• System must be robust first!
27/11/2014 @danielbryantuk
70. 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
27/11/2014 @danielbryantuk
74. 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
27/11/2014 @danielbryantuk
76. Antifragile Patterns: Async FTW
• 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
27/11/2014 @danielbryantuk
77. Antifragile Patterns: Respect the CAP
Eventual consistency (ACID vs BASE)
en.wikipedia.org/wiki/CAP_theorem
cloudshankar.blogspot.co.uk/2013/05/eventual-consistency.html
www.dataversity.net/acid-vs-base-the-shifting-ph-of-database-transaction-processing/
27/11/2014 @danielbryantuk
78. So, Cloud services are ‘done’ when…
Documented (just enough)
Highly cohesive/loosely coupled (all the way down)
Automated from commit to Cloud
Resource aware
Monitored thoroughly
Antifragile
27/11/2014 @danielbryantuk