Building Java applications for the Cloud is easy, right? Perhaps, but if you want to build effective and reliable applications 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 JVM-based monolithic applications deployed into a data center on a 'big bang' schedule, to a platform of loosely-coupled components, all being continuously deployed into the Cloud. Topics discussed will include API contracts and documentation, microservices, build and deployment pipelines, Cloud fabric properties, monitoring in a distributed environment, and fault-tolerant design patterns.

1. Building Java applications for the Cloud:
The DHARMA principles
Daniel Bryant
Principal Consultant, Open Credo
daniel.bryant@opencredo.com
@danielbryantuk
@OpenCredo

2. What to expect
• Problems when developing for the Cloud
– “Lift and shift”
– Smashing the monolith
– Greenfield (“Cloud native”)
• Some suggestions on where to focus efforts
– Not specific platform/framework reviews
• Tools and techniques
• Lots of information… (slides will be available)
15/10/2014 @danielbryantuk

3. Who Am I?
• Principal Consultant at OpenCredo
• LJC Associate
 Agile transformations
 DevOps
 Microservices and Cloud
• Adopt OpenJDK and JSR
15/10/2014 @danielbryantuk

4. The Current Industry Wish List…
• Service-Oriented Architecture
• Cloud-based deployments
• DevOps Culture
15/10/2014 @danielbryantuk

5. The Current Industry Wish List…
• Service-Oriented Architecture
– Twitter’s Story (bit.ly/1j1WbmI)
• Cloud-based deployments
– Today!
• DevOps Culture
– Devoxx UK talk (bit.ly/1BylnZb)
– Previous LJC Event (bit.ly/1elVPJz)
15/10/2014 @danielbryantuk

6. Common Cloud Problems
TL;DR…
15/10/2014 @danielbryantuk

7. Not respecting the underlying environment
15/10/2014 @danielbryantuk

8. Lack of application/platform monitoring…
15/10/2014 @danielbryantuk

9. Bizarre failure modes…
15/10/2014 @danielbryantuk

10. Difficulty in understanding
the new architecture
15/10/2014 @danielbryantuk

11. Confusion over environment provisioning and config
15/10/2014 @danielbryantuk

12. Not testing in the Cloud…
(hint: here be dragons!)
15/10/2014 @danielbryantuk

13. We’ve created the “Cloud DHARMA Principles”
to act as a checklist when building Cloud apps
15/10/2014 @danielbryantuk

14. 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)
15/10/2014 @danielbryantuk

15. Documented (just enough)
Highly cohesive/loosely coupled (all the way down)
Automated from commit to Cloud
Resource aware
Monitored thoroughly
Antifragile
15/10/2014 @danielbryantuk

16. Documented (just enough)
Highly cohesive/loosely coupled (all the way down)
Automated from commit to Cloud
Resource aware
Monitored thoroughly
Antifragile
15/10/2014 @danielbryantuk

17. 15/10/2014 @danielbryantuk

18. Documentation (just enough)
• Provide a map for developers
• Component purpose (and contract)
• Initialisation instructions (mocks/stubs)
• Highlights areas of operational risk
15/10/2014 @danielbryantuk

19. Simon Brown’s C4 Model
15/10/2014 @danielbryantuk
www.codingthearchitecture.com

20. 15/10/2014 @danielbryantuk

21. 1155//1100//22010414 @@ddaanniieellbbrryyaanntutukk

22. API Docs with Swagger
15/10/2014 @danielbryantuk
helloreverb.com/developers/swagger

23. Create a PACT
15/10/2014 @danielbryantuk
github.com/DiUS/pact-jvm

24. Documented (just enough)
Highly cohesive/loosely coupled (all the way down)
Automated from commit to Cloud
Resource aware
Monitored thoroughly
Antifragile
15/10/2014 @danielbryantuk

25. High Cohesion / Loose Coupling
(all the way down…)
• Code
• Architecture
– Components
– Services
• Public API
– PayPal (bit.ly/1hnZNly)
15/10/2014 @danielbryantuk

26. Smashing the Monolith…
• Business functionality -“Cart Service”
• Technology chunk - “Email Service”
• Vertical Slice
– “Registration” (Groupon: vimeo.com/105880150)
• Horizontal Slice
– “User Repo” (Microservices: oreil.ly/1pp6qmx)
15/10/2014 @danielbryantuk

27. Microservices
• Probably won’t catch on… ;-)
15/10/2014 @danielbryantuk

28. Twelve Factor Apps
15/10/2014 @danielbryantuk
http://12factor.net/

29. Documented (just enough)
Highly cohesive/loosely coupled (all the way down)
Automated from commit to Cloud
Resource aware
Monitored thoroughly
Antifragile
15/10/2014 @danielbryantuk

30. Automated from Commit to Cloud
• Continuous Integration
• Continuous Deployment
• Continuous Delivery
15/10/2014 @danielbryantuk

31. Our Build Pipeline
Jenkins, with plugins…
• Build Pipeline
– wiki.jenkins-ci.org/display/JENKINS/Build+Pipeline+Plugin
• Parameterized build
– wiki.jenkins-ci.org/display/JENKINS/Parameterized+Build
• Promoted Builds Plugin
– wiki.jenkins-ci.org/display/JENKINS/Promoted+Builds+Plugin
15/10/2014 @danielbryantuk

32. Our Build Pipeline
• Component Build
– Compile
– Unit Tests (surefire)
– Integration Tests (failsafe)
• Deployment onto QA Cloud
– Python Scripts + Chef to provision
– Verify success using Python
– Serverspec serverspec.org
15/10/2014 @danielbryantuk

33. Our Build Pipeline
• Acceptance Tests
– Cucumber (and Selenium)
• Performance Tests
– Jmeter + Jenkins performance plugin
– Make sure environment is realistic!!
• Live Deployment?
15/10/2014 @danielbryantuk

34. Automating QA
• Intra-component integration testing
– Utilise embedded datastore/middleware
– “Scassandra” (github.com/scassandra)
– Service virtualisation (www.mbtest.org)
• Inter-component integration testing
– The hardest part of SOA…
– Consider ‘synthetic txns’ (active monitoring)
15/10/2014 @danielbryantuk

35. Infrastructure: Say No To Snowflakes!
• Automate all provisioning (store in SCM)
• Fry...
– Chef, Puppet, SaltStack, Ansible
– Bash, Python (Fabric)
– Vendor APIs
• …or bake?
– Packer.io
– Netflix Aminator
15/10/2014 @danielbryantuk

36. 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)
15/10/2014 @danielbryantuk

37. Configuring the Cloud
• Bundle config with app
– Upload new config file
– Re-deploy entire app (easier with Docker?)
• Store externally
– Zookeeper & Curator curator.apache.org
– Netflix Archaius github.com/Netflix/archaius
– etcd github.com/coreos/etcd
– Consul.io www.consul.io
15/10/2014 @danielbryantuk

38. Documented (just enough)
Highly cohesive/loosely coupled (all the way down)
Automated from commit to Cloud
Resource aware
Monitored thoroughly
Antifragile
15/10/2014 @danielbryantuk

39. Deployment Platform: What you’ve got…
15/10/2014 @danielbryantuk

40. What you think you want…
15/10/2014 @danielbryantuk

41. What you actually get…
Fact: 9 out of 10 cheetahs prefer the
taste of an Ops team over tinned food
15/10/2014 @danielbryantuk

42. 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
15/10/2014 @danielbryantuk

43. 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
15/10/2014 @danielbryantuk

44. Thinking/Acting Operationally
• Cultivate “Mechanical Sympathy”
• Virtualisation
– Tech Target (bit.ly/1kDVqyG)
• Networking
– ‘Unix and Linux System Administration Handbook’
– aws.amazon.com/documentation
15/10/2014 @danielbryantuk

45. Thinking/Acting Operationally
• Learn Linux fundamentals
• Diagnostic skills
– top, netstat, vmstat, tcpdump
– Java utils: jps, jstat, jmap, jhat
– “DevOps Troubleshooting” by K. Rankin
15/10/2014 @danielbryantuk

46. Documented (just enough)
Highly cohesive/loosely coupled (all the way down)
Automated from commit to Cloud
Resource aware
Monitored thoroughly
Antifragile
15/10/2014 @danielbryantuk

47. Monitor All The Things!
• Infrastructure monitoring
– Nagios / Zabbix
– AppDynamics
• Distributed Tracing
– twitter.github.io/zipkin
• Centralised Logging
– logstash.net
15/10/2014 @danielbryantuk

48. 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
15/10/2014 @danielbryantuk

49. Health Checks
15/10/2014 @danielbryantuk

50. Gauges, Counters, Meters, Timers…
15/10/2014 @danielbryantuk

51. Graph It!
15/10/2014 @danielbryantuk
dashing.io

52. 15/10/2014 @danielbryantuk
Phrase borrowed from Etsy!

53. 15/10/2014 @danielbryantuk

54. Documented (just enough)
Highly cohesive/loosely coupled (all the way down)
Automated from commit to Cloud
Resource aware
Monitored thoroughly
Antifragile
15/10/2014 @danielbryantuk

55. Antifragile
• The opposite of fragile?
– Robust…
– Antifragile…
• Netflix are best-in-class
– bit.ly/1gs5n3q
• System must be robust first!
15/10/2014 @danielbryantuk

56. Design for Failure
• Distributed Computing Principles
– ‘For young bloods’ (bit.ly/1pKVepz)
– Netflix (bit.ly/1h5GMid)
• Design patterns
– Timeouts / retries
– Bulkheads / circuit-breakers
15/10/2014 @danielbryantuk

57. Retries
15/10/2014 @danielbryantuk
github.com/rholder/guava-retrying

58. Circuit-breaker
15/10/2014 @danielbryantuk
github.com/Netflix/Hystrix
github.com/Netflix/Hystrix/tree/master/hystrix-contrib/hystrix-javanica
java.dzone.com/articles/hystrix-and-spring-boot
projects.spring.io/spring-cloud/

59. Antifragile Patterns: Async FTW
Asynchronous Communication - queues, pub/sub
Command Query Responsibility Segregation (CQRS)
Event Sourcing (ES)
martinfowler.com/bliki/CQRS.html
15/10/2014 @danielbryantuk

60. Antifragile Patterns: Respect the CAP
Eventual consistency (ACID vs BASE)
Clever caching (soft-state)
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/
15/10/2014 @danielbryantuk

61. Antifragile Patterns: Elastic Scaling
Stateless components
Distributed data stores / caches
15/10/2014 @danielbryantuk

62. So, Cloud Apps are ‘done’ when…
Documented (just enough)
Highly cohesive/loosely coupled (all the way down)
Automated from commit to Cloud
Resource aware
Monitored thoroughly
Antifragile
15/10/2014 @danielbryantuk

63. Thanks For Listening
• Massive thanks to all the OpenCredo team!
• Questions / comments?
– daniel.bryant@opencredo.com
– @danielbryantuk
15/10/2014 @danielbryantuk