Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

muCon 2014 "Building Java Microservices for the Cloud"

2,882 views

Published on

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

Published in: Technology
  • Be the first to comment

muCon 2014 "Building Java Microservices for the Cloud"

  1. 1. Building Java (micro)services for the Cloud The DHARMA principles Daniel Bryant Principal Consultant, Open Credo daniel.bryant@opencredo.com @danielbryantuk
  2. 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. 3. The Current Industry Wish List… • Service-Oriented Architecture • Cloud-based deployments • DevOps Culture 27/11/2014 @danielbryantuk
  4. 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
  5. 5. The obligatory microservice definition… 27/11/2014 @danielbryantuk
  6. 6. Microservices… • “SOA done right” • “SRP” services – “Java, The Unix Way” (bit.ly/1cX8VsS) • “Small” codebase services – 1000 LOC… 100… 10…? • My personal opinion… 27/11/2014 @danielbryantuk
  7. 7. “Can I fit the service in my head?” 27/11/2014 @danielbryantuk
  8. 8. Common Cloud Problems TL;DR… 27/11/2014 @danielbryantuk
  9. 9. Not respecting the underlying environment 27/11/2014 @danielbryantuk
  10. 10. Lack of application/platform monitoring… 27/11/2014 @danielbryantuk
  11. 11. Bizarre failure modes… Three certainties in life: Taxes, death and failure in production… 27/11/2014 @danielbryantuk
  12. 12. Difficulty in understanding the new architecture 27/11/2014 @danielbryantuk
  13. 13. Confusion over environment provisioning and config 27/11/2014 @danielbryantuk
  14. 14. Not testing in the Cloud… (hint: here be dragons!) 27/11/2014 @danielbryantuk
  15. 15. We’ve created the “Cloud DHARMA Principles” to act as a checklist when building Cloud apps 27/11/2014 @danielbryantuk
  16. 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. 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. 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
  19. 19. 27/11/2014 @danielbryantuk
  20. 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
  21. 21. leanpub.com/software-architecture-for-developers 2277//1111//22010414 @@ddaanniieellbbrryyaanntutukk
  22. 22. Simon Brown’s C4 Model @simonbrown www.codingthearchitecture.com 27/11/2014 @danielbryantuk
  23. 23. 27/11/2014 @danielbryantuk
  24. 24. API Docs with Swagger 27/11/2014 @danielbryantuk helloreverb.com/developers/swagger
  25. 25. API Docs with Swagger 27/11/2014 @danielbryantuk helloreverb.com/developers/swagger
  26. 26. Create a PACT 27/11/2014 @danielbryantuk github.com/DiUS/pact-jvm martinfowler.com/articles/consumerDrivenContracts.html
  27. 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. 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
  29. 29. Encapsulation: High Cohesion/Loose Coupling • Code • Modules – Components (bit.ly/1n7D0vp) – Services (bounded contexts) • Public APIs – PayPal (bit.ly/1hnZNly) • Deployment – 12factor.net 27/11/2014 @danielbryantuk
  30. 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. 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
  32. 32. Scalability: The Three Ways 27/11/2014 @danielbryantuk
  33. 33. The Scaling Cube 27/11/2014 @danielbryantuk
  34. 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?
  35. 35. 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? 27/11/2014 @danielbryantuk
  36. 36. DZone’s Enterprise Integration Guide dzone.com/research/guide-to-enterprise-integration 27/11/2014 @danielbryantuk
  37. 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. 38. Automated from Commit to Cloud • Continuous Integration • Continuous Deployment • Continuous Delivery 27/11/2014 @danielbryantuk
  39. 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. 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. 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. 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. 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. 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. 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
  46. 46. 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) 27/11/2014 @danielbryantuk
  47. 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. 48. QA: Further Inspiration Toby Clemson @ martinfowler.com/articles/microservice-testing 27/11/2014 @danielbryantuk
  49. 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. 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
  51. 51. Deployment Platform: What you’ve got… 27/11/2014 @danielbryantuk
  52. 52. What you think you want… 27/11/2014 @danielbryantuk
  53. 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. 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. 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. 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. 57. Mechanical Sympathy by the Numbers www.eecs.berkeley.edu/~rcs/research/interactive_latency.html 27/11/2014 @danielbryantuk
  58. 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. 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. 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. 61. The ‘ELK’ Stack blog.comperiosearch.com/blog/2014/08/14/elk-one-vagrant-box 27/11/2014 @danielbryantuk
  62. 62. 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 27/11/2014 @danielbryantuk
  63. 63. Health Checks 27/11/2014 @danielbryantuk
  64. 64. Gauges, Counters, Meters, Timers… 27/11/2014 @danielbryantuk
  65. 65. Graph It! 27/11/2014 @danielbryantuk dashing.io
  66. 66. 27/11/2014 @danielbryantuk Phrase borrowed from Etsy!
  67. 67. 27/11/2014 @danielbryantuk
  68. 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. 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. 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
  71. 71. Timeouts docs.guava-libraries.googlecode.com/…/concurrent/SimpleTimeLimiter.html 27/11/2014 @danielbryantuk
  72. 72. Retries 27/11/2014 @danielbryantuk github.com/rholder/guava-retrying
  73. 73. Circuit-breaker/bulkhead 27/11/2014 @danielbryantuk github.com/Netflix/Hystrix projects.spring.io/spring-cloud/
  74. 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
  75. 75. Antifragile Patterns: Elastic Scaling Stateless components Distributed data stores / caches 27/11/2014 @danielbryantuk
  76. 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. 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. 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
  79. 79. 27/11/2014 @danielbryantuk
  80. 80. Thanks For Listening! • Massive thanks – OpenCredo (@OpenCredo) – www.notonthehighstreet.com • Questions / comments? – daniel.bryant@opencredo.com – @danielbryantuk 27/11/2014 @danielbryantuk

×