Everyone is talking about building “cloud native” Java applications—and taking advantage of microservice architecture, containers, and orchestration/PaaS platforms—but there is surprisingly little discussion of migrating existing legacy (moneymaking) applications. This session aims to address this, and, using lessons learned from several real-world examples, it covers topics such when to rewrite applications (if at all), modeling/extracting business domains, applying the “application strangler” pattern, common misconceptions with “12-factor” application design, and the benefits/drawbacks of container technology.

1. Java, Microservices, Cloud and Containers:
Migrating without the Tiers (or Tears)
Daniel Bryant @danielbryantuk
Steve Poole @spoole167
22/09/2016 @danielbryantuk | @spoole167 1

2. The pitch
• Moving to the cloud requires a fundamental change in mindset
• Technology
• Skills (architectural, operational, QA)
• Organisational design
• DevOps, container technology and microservices are complementary
• Migrating in non-trivial
• Learn from some of our successes (and mistakes)…
22/09/2016 @danielbryantuk | @spoole167 2

3. Who are we?
22/09/2016 @danielbryantuk | @spoole167 3
Steve Poole
IBM
Developer
@spoole167
Daniel Bryant
Chief Scientist,
OpenCredo
CTO SpectoLabs
@danielbryantuk
Making Java Real Since Version 0.9
Open Source Advocate
DevOps Practitioner (whatever that means!)
Driving Change
“Biz-dev-QA-ops”
Leading change in organisations
Experience of Docker, k8s, Go, Java
InfoQ, DZone, Voxxed contributor

4. Introduction
22/09/2016 @danielbryantuk | @spoole167 4

5. What ‘Cloud’ promises
a virtual, dynamic environment which
maximizes use, is infinitely scalable, always
available and needs minimal upfront
investment or commitment
Take your code – host it on someone else's
machine pay only for the resource you use for the
time you use it AND be able to do that very quickly
and repeatedly in parallel

6. https://www.flickr.com/photos/skohlmann/
The ability to have ‘cloud burst’ capacity is
changing the way software is being designed,
developed and supported
We’re moving to a more industrial scale:
Why buy one computer for a year when you
can hire 365 computers for a day..

7. https://www.flickr.com/photos/vuhung/
“Compute on demand” – it’s what we always
wanted

8. Cloud computing:
compute == money
Money changes everything
With a measureable and direct relationship
between $£€¥ and CPU/RAM, disk etc the
financial success or failure of a project is
even easier to see
And that means…
Even more focus on value for money.

9. American Society of Civil Engineers
Someone
will be
looking at
your leaky
app

10. Loosing unnecessary baggage - (you have loads)
Java applications have to get lighter.
Java 9 modularity will help but you have to consider
footprint across the board.
Choose your dependencies wisely
Your choice of OS & distribution is important.
The aim is ‘carry on only’
Your application isn’t going on a long trip
https://www.flickr.com/photos/armydre2008/

11. Startup times
How long do you want to wait?
How long do you have to wait?
Do you need to preemptively start instances ‘just in case’ due
to start up time? To bad – that costs
If the unit of deployment and scaling is an instance of a service
it needs to start FAST
https://www.flickr.com/photos/91295117@N08/

12. https://www.flickr.com/photos/isherwoodchris/
• Q: How much RAM does
your application use?
• A: Too much

13. Runtime costs
Most cloud providers will charge you for your RAM usage over time:
$GB/hr. (Sometimes the charge is $0)
Increasing –Xmx directly effects cost. Something businesses can
understand
Net effect : you’ll be tuning your application to fit into specific RAM sizes.
Smaller than you use today.
You need to measure where the storage goes.
You’ll be picking some components based on memory usage
Note that increasing the amount of memory for 1 service increases the bill
by the number of concurrent instances
https://www.flickr.com/photos/erix/

14. Simply
Java applications are going to be running
in a remote, constrained and metered
environment
There will be precise limits on how much
disk, CPU, RAM, Bandwidth an application
can use and for how long
Whether your application is large or small,
granular or monolithic. Someone will be
paying for each unit used
That person will want to get the most out
of that investment
https://www.flickr.com/photos/rvoegtli/

15. Where you code runs day-to-day and moment-to-
moment will be driven by economics, legal
requirements and how much risk your business
wants to take.
Your code has to scale better, be more efficient,
resilient, secure and work in constrained
environments
You will have to design, code, deliver, support and
debug code in new ways
It’s going to be scary

16. How scary?
design, coding, deployment ,
startup, execution, scaling
debugging, security, resilience …
Almost everything
about your
application is
effected
https://www.flickr.com/photos/mjtmail/

17. Resilient
applications
Design for short term failure: something fails all the time. Expect data and service outages regularly
Fail and recover: don’t diagnose problems in running systems. Kill it and move on
Every IO operation you perform may fail – do as few as possible
Every IO operation may stall – costing you GB/hrs and resources– timeout everything quickly
Every piece of data you receive may be badly formed – check everything
Retry, compensation, backout strategies– these are your new friends
“Everything in the cloud
fails all the time” : Werner
Vogels

18. Debugging
Remote support for your family?
Fancy having to do that for your own apps?
You have to assume:
You will never be able to log into a remote server.
You will never be able to attach a remote debugger to
a failing app
Ever.
All problems must be resolved by local reproduction
or logs and dumps (discuss)
https://www.flickr.com/photos/carbonnyc/

19. Debugging
It gets more challenging.
Failures during deployment
or initial startup can be difficult or impossible to
diagnose.
If your service instance didn’t start there is is little
chance of logs being kept!
Learn to love logs, dumps and traces.
Remote log stores and tools are going to be your best
friend
BTW: they’ll cost too
https://www.flickr.com/photos/hinkelstone/

20. Security
When you deploy to public cloud your system will be
attacked in minutes.
Certainly in < 1hr
Your systems will always be under threat
https://www.flickr.com/photos/ahmadhammoudphotography/

21. It’s all change
How you design, code, deploy, debug,
support etc will be effected by the metrics
and limits imposed on you.
Financial metrics and limits always
change behavior. It also creates
opportunity
Java applications have to get leaner and
meaner
You have to learn new techniques and
tools
https://www.flickr.com/photos/beigephotos/

22. Case studies
22/09/2016 @danielbryantuk | @spoole167 22

23. “Just make it do what the old one does (but better)”
• Case studies
• ‘Teflon shouldered’ product owner
• Rebuilding a service three times
• Problem
• Performing migration without a
clear definition of ‘done’
• Accepting feature creep
22/09/2016 @danielbryantuk | @spoole167 23

24. “Just make it do what the old one does (but better)”
• Attempt to retrofit BDD/regression tests around application
• Serenity BDD, Cucumber, Jbehave
• Work incrementally with QA team
• Manually test everything
• Create tests for new functionality
• Compare input/output
• Traffic: Twitter’s Diffy
• Datastores: Reconsiliator pattern
22/09/2016 @danielbryantuk | @spoole167 24

25. Twitter’s Diffy and mysqldbcompare
22/09/2016 @danielbryantuk | @spoole167 25
blog.twitter.com/2015/diffy-testing-services-without-writing-tests dev.mysql.com/doc/mysql-utilities/1.5/en/mysqldbcompare.html

26. www.infoq.com/news/2015/04/raffi-krikorian-rearchitecting
My ‘re-architecting’ bible…
22/09/2016 @danielbryantuk | @spoole167 26

27. “Bounding the context”
• Case studies
• Large business software provider
thought they knew their domain
• Small CRM company had let
domain model entropy
• Problem
• Development team lost sight of
the application big picture
• Lack of architectural awareness
and ‘broken windows’
22/09/2016 @danielbryantuk | @spoole167 27

28. Context mapping (static) & event storming (dynamic)
22/09/2016 @danielbryantuk | @spoole167 28
www.infoq.com/articles/ddd-contextmapping
ziobrando.blogspot.co.uk/2013/11/introducing-event-storming.html

29. “Bounding the context”
• Create ‘seams’ within codebase
• Natural domain boundaries
• Single responsibility principle
• Look for points of ‘friction’
• Extreme ownership
• Seize (identify)
• Clear (refactor logic / data)
• Hold (metrics and rachets)
• Build (move code to service)
22/09/2016 @danielbryantuk | @spoole167 29

30. “How small is micro?”
• Case studies
• UK retailer looking to migrate to
cloud and microservices
• Keen to minimise risk
• Problem
• Previous attempts of gradual
migration had failed
• Integration issues - services either
too big or too small
• Spent a long time building a
‘microservice platform’
22/09/2016 @danielbryantuk | @spoole167 30

31. “How small is micro?”
• Understand microservice principles and Self-Contained Systems (SCS)
• Utilise the strangler pattern
• ‘Service Virtualisation’ is valuable for testing
• Don’t underestimate the value of PaaS
22/09/2016 @danielbryantuk | @spoole167 31

32. 22/09/2016 @danielbryantuk | @spoole167 32
zeroturnaround.com/rebellabs/microservices-for-the-enterprise/

33. Self-contained systems (SCS)
22/09/2016 @danielbryantuk | @spoole167 33
http://scs-architecture.org/
UI / Biz / Repo
Monolith
Domains
Modules, components,
frameworks, libraries

34. Self-contained systems (SCS)
22/09/2016 @danielbryantuk | @spoole167 34
SCS
Microservices

35. Strangling your software (not your manager!)
22/09/2016 @danielbryantuk | @spoole167 35
paulhammant.com/2013/07/14/legacy-application-strangulation-case-studies/
www.nginx.com/blog/refactoring-a-monolith-into-microservices/

36. Service Virtualisation (for Dev and Test)
• Existing tooling
• Hoverfly
• Wiremock
• VCR/Betamax
• Mountebank
• mirage
22/09/2016 @danielbryantuk | @spoole167 36

37. Hoverfly
• Lightweight Service virtualisation
• Open source (Apache 2.0)
• Go-based / single binary
• Written by @Spectolabs
• Flexible API simulation
• HTTP / HTTPS
• More Protocols to follow?
22/09/2016 @danielbryantuk | @spoole167 37

38. 22/09/2016 @danielbryantuk | @spoole167 38
• Middleware
• Remove PII
• Rate limit
• Add headers
• Middleware
• Fault injection
• Chaos monkey

39. The value of PaaS…
22/09/2016 @danielbryantuk | @spoole167 39

40. The value of PaaS…
22/09/2016 @danielbryantuk | @spoole167 40

41. “Cloud native or ‘lift and shift’”
• Case studies
• Price comparison website
performance dipped upon a
migration to the cloud
• Problems
• Not coding for distributed or
ephemeral nature of cloud
• No reliable creation of cloud
environment
• Not testing in the cloud
22/09/2016 @danielbryantuk | @spoole167 41

42. “Cloud native or ‘lift and shift’”
• Push apps through to production as early as possible (CI/CD)
• Build POCs appropriately
• Include building infrastructure in the pipeline
• Include NFR testing in the build pipeline
• Dev, QA and Ops must cultivate ‘mechanical sympathy’
• Everything in the cloud is networked
• Configure local development environments as appropriate
22/09/2016 @danielbryantuk | @spoole167 42

43. NFR testing in the (cloud) pipeline
22/09/2016 @danielbryantuk | @spoole167 43

44. NFRs testing in the (container) pipeline
22/09/2016 @danielbryantuk | @spoole167 44

45. NFR testing resources
• Performance
• JMeter
• Gatling
• Fault-tolerance
• Hoverfly
• Wiremock/Saboteur
• Security
• bdd-security (OWASP ZAP)
• OWASP Dependency-Check
• Docker Bench for Security
22/09/2016 @danielbryantuk | @spoole167 45

46. Security is vital (but often ignored)
22/09/2016 @danielbryantuk | @spoole167 46
www.youtube.com/watch?v=c9uvV4ChIXw
www.infoq.com/news/2016/08/secure-docker-microservices

47. Shameless plugs…
22/09/2016 @danielbryantuk | @spoole167 47
www.youtube.com/watch?v=A1982GdXXSA

48. “Containerise all the things”
• Problem
• JVM respecting resource limits
• OOM: Unable to create thread
• Random application stalling
• Case studies
• www.notonthehighstreet.com
22/09/2016 @danielbryantuk | @spoole167 48

49. “Containerise all the things”
• Set container memory appropriately
• docker - - memory=”Xg”
• JVM requirements = Heap size (Xmx) + Metaspace + JVM overhead
• Account for native thread requirements e.g. thread stack size (Xss)
• Watch out for ulimits
• Entropy
• Host entropy can soon be exhausted by crypto operations
• –Djava.security.egd=file:/dev/urandom
• Be aware of security ramifications
22/09/2016 @danielbryantuk | @spoole167 49

50. Containerising our knowledge
22/09/2016 @danielbryantuk | @spoole167 50

51. Key lessons learned
22/09/2016 @danielbryantuk | @spoole167 51

52. Lessons learned from the trenches
• Specify goals and targets of migration (and retrospect)
• Undertake just enough up front design (contexts, APIs, integration)
• Understand distributed systems (12 factors etc)
• Start pushing to production ASAP
• There is nothing wrong with PaaS
• Programmable infrastructure is a key enabler
• Don’t forget the NFRs
• Containers and microservices are complementary to cloud
22/09/2016 @danielbryantuk | @spoole167 52

53. Recommended reading
22/09/2016 @danielbryantuk | @spoole167 53

54. Thanks for listening
• Any questions?
• Daniel Bryant (@danielbryantuk )
• Steve Pool (@spoole167)
22/09/2016 @danielbryantuk | @spoole167 54