How far have you got with learning about Cloud? Got your head around Platform as a Service? Understand what IaaS means? Can spell Docker? Working in a DevOps mode? It’s easy to focus on learning new technology but it’s time to take a step back and look at what the technical implications are when an application is heading to the cloud. In the world of the cloud the benefits are high but the economics (financial and technical) can be radically different. Learn more about these new realities and how they can change application design, deployment and support. The introduction of Cloud technologies and its rapid adoption creates new opportunities and challenges. Whether designer, developer or tester, this talk will help you to start thinking differently about Java and the Cloud. Presented at JAX DE, 2016

1. All Change!
https://www.flickr.com/photos/teegardin/
why the economics of Cloud will
make you think differently about Java

2. Important Disclaimers
THE INFORMATION CONTAINED IN THIS PRESENTATION IS PROVIDED FOR INFORMATIONALPURPOSES ONLY.
WHILST EFFORTS WERE MADETO VERIFYTHE COMPLETENESSANDACCURACYOF THE INFORMATION CONTAINED IN THIS PRESENTATION, IT IS PROVIDED “AS IS”, WITHOUT
WARRANTY OFANY KIND, EXPRESS OR IMPLIED.
ALLPERFORMANCE DATAINCLUDED IN THIS PRESENTATION HAVE BEEN GATHERED INACONTROLLED ENVIRONMENT. YOUR OWNTEST RESULTS MAYVARY BASED ON HARDWARE,
SOFTWARE OR INFRASTRUCTURE DIFFERENCES.
ALLDATAINCLUDED IN THIS PRESENTATIONARE MEANT TO BE USED ONLYASAGUIDE.
INADDITION, THE INFORMATION CONTAINED INTHIS PRESENTATION IS BASED ON IBM’S CURRENT PRODUCT PLANSAND STRATEGY, WHICHARE SUBJECT TO CHANGE BY IBM,
WITHOUT NOTICE.
IBMAND ITSAFFILIATED COMPANIES SHALLNOT BE RESPONSIBLE FORANY DAMAGESARISING OUT OFTHE USE OF, OR OTHERWISE RELATED TO, THIS PRESENTATION ORANY
OTHER DOCUMENTATION.
NOTHING CONTAINED IN THIS PRESENTATION IS INTENDED TO, OR SHALLHAVETHE EFFECT OF:

3. Steve Poole – IBM
Making Java Real Since
Version 0.9
DevOps Practitioner
@spoole167
Chris Bailey– IBM
Runtimes Technical Lead
Java, Node.js & Swift
@Chris__Bailey

4. This talk is about how this sort of measurement:
GB/hr
Is already changing your life & the direction of the Java
ecosystem
The ‘Cloud’ has a lot to answer for

5. Outline
• Part 1 – The economics of Cloud provisioning
• Part 2 – The API economy and Java
• Part 3 - How Java measures up
• Part 4 – What the future holds
• Wrap up & Q/A

6. Part 1 – The economics of Cloud provisioning

7. Why ‘Cloud’ ?
A local, hand-crafted, static environment which
requires in-house specialist support, doesn’t scale
well and requires long term investment and
commitment
tps://www.flickr.com/photos/sylvar/

8. 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 and 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

9. How quickly do you need to get good code into
production?
• Would you believe < 1hr?
• Case Study: A fashion retailer can show measureable
increase in sales if a item similar to that seen in the media can
be placed on their on-line store landing page within 1 hr of it
appearing in public.
• Each product placement is different so they need a fast, agile,
approach that does not jeopardize their on-line stores
availability and quality.
• We know how to do this..

10. Cloud computing is real.
Major vendors are providing
substantial capacity and it’s
growing all the time
Businesses see the opportunities
Improved value for money,
decreased time-to-market, shorter
time to value
“I can now get my ideas into
production in hours,days or weeks.
I can get immediate feedback AND
then I can improve the idea and
repeat”

11. 70% of IT Leaders are pursuing a hybrid cloud
strategy
http://www.fodey.com/generators/newspaper/snippet.asp
Hybrid Cloud is coming to a data centre near you

12. ps://www.flickr.com/photos/skohlmann/
The ability to have ‘cloud burst’
capacity is changing the way software
is being designed, developed and
supported

13. We’re moving to a more industrial scale
v1v1 v2v2 v3v3
time
compute
capacity

14. V1V1
V1.1V1.1
V1.2V1.2
V1.3V1.3
V1.4V1.4
V1.5V1.5
V1.6V1.6
V1.7V1.7
v1v1 v2v2
time
compute
capacity
We’re moving to a more industrial scale
v3v3

15. • Why buy one computer for a year when you
can hire 365 computers for a day..
(Or a hour or a minute or a millisecond)

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

17. Cloud Economics
We really are getting closer all the time to
‘Compute on Tap’
https://www.flickr.com/photos/leunix/

18. But with taps come meters…
https://www.flickr.com/photos/beigephotos/
Cloud Economics

19. Like all bills – it’s confusing
Offering RAM Cost (2015) CPUs
IBM Bluemix (CF) $24.15 GB/Month 4vCPUs per instance
IBM Bluemix (Containers) $ 9.94 GB/Month 4vCPUs per GB
run.pivotal.io $21.60 GB/Month 4vCPUs per instance
Heroku (Hobby) $14.00 GB/Month 1 "CPU share" per 512MB in an
instance
Heroku (Professional) $50.00 GB/Month 1 "CPU share" per 512MB in an
instance
Amazon EC2 (SLES) $16.56 GB/Month 1 vCPU per 4GB in an instance.

20. 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.

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

22. Part 2 – The API economy
And what that means for Java

23. The API economy
If your company has data it will eventually
be shared and monetized
Really.
Cloud APIs are one of the fastest growing areas in our industry.
Sharing data and services though APIs is enabling new
opportunities and solutions
Everyone is getting into the game.

24. What makes a good cloud api ?
roughly in selection order.
vailability 100% of course with performance SLAs
elievability – Are those published 100% metrics true?
ost – how much and what is the unit of measure?
iagnosability – can users debug problems without you?
xcitement – is there a vibrant community using the API?
unctionality – what else can the API do?

25. 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

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

27. 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
“Everything in the cloud fails
all the time” : Werner Vogels

28. 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
https://www.flickr.com/photos/carbonnyc/

29. 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/

30. Debugging
• Q: Why can’t you just keep the failed
instance around?
• A: You can – if you accept the $$$
consequences…

31. Hard metrics and limits keeping a failed app around
or having apps on standby
can be costly in multiple ways
Runtime costs and taking up
vital resource allocation

32. Part 3 - How Java measures up

33. Compute == money Easier than ever before
a business can rent a
machine
Just for how long they
need it.
No long term capital
investment.
Now an operational
expense
$ == GB/hr
-Xmx: $100

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

35. 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
increasing the amount of memory for 1 service
increases the bill by the number of concurrent
instances
https://www.flickr.com/photos/erix/

36. 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/

37. Analysing Your Memory Usage
A large percentage of the heap is used for collections and caches
Eclipse Memory Analyzer will help you analyze:
Easy to reduce memory usage without reducing cache sizes
https://www.flickr.com/photos/armydre2008/

38. Example costs (2015)
Bluemix (CF) Amazon (ECS)
Running a 512mb container
for a year
$289.80 for 4 cpus 198.72 for 1 cpu
Reducing memory footprint
by 10% saves
$28.98 $0
Running 100 containers in
parallel
$28,980.00 for 400
cpus
$19,872.00 for 100 cpus
Reducing memory footprint
by 10% saves
$2,898.00 $0

39. N-Body Memory Footprints (lower is better)
Modern Native Scripting JVMC

40. N-Body Completion Time (lower is
better):
Modern Native Scripting JVMC

41. N-Body Completion Time, normalized for
100MB of memory (lower is better):
Modern Native Scripting JVMC

42. Example costs (2015)
Bluemix (CF)
Running a 512mb container
for a year
$289.80 for 4 cpus
Reducing memory footprint
by using Swift saves 75%
$216.75
Running 100 containers in
parallel
$28,980.00 for 400
cpus
Reducing memory footprint
by using Swift saves
$21,675.00

43. Static Load Profile

44. Auto-Scaled Load Profile

45. Example costs (2015)
Bluemix (CF)
Running a 512mb container
for a year
$289.80 for 4 cpus
Using auto-Scaling reduces
container usage by 30%
Running 100 containers in
parallel
$28,980.00 for 400
cpus
Using auto-scaling saves $6,085.8

46. Java & fast startup time
Application developers can reduce service
startup time by deferring optional costs to
when its needed.
Maybe even create services with different
behaviors rather than one with optional
behavior
But it’s not enough
The JVM needs to revisit all the places
where startup time was traded for
throughput and turn them around.

47. Startup times
How long do you have to wait?
Limits ability to react to changes in workload
Will you need to preemptively start instances ‘just
in case’ due to start up time?
To bad – that costs
Also think about this:
Everything that happens at startup – happens
every time, all the time.
- Duplication is wasted effort
https://www.flickr.com/photos/91295117@N08/

48. Consequences
For container based services start up effort
happens multiple times during development
and production
And it’s always the same result.
AND you will pay $ for it every time
We don’t have a good way to capture all this
effort or formalise starting a JVM from a
precanned image. (Shared classes doesn’t hack
it)
Other languages have better / faster startup!
https://www.flickr.com/photos/dno1967b/https://www.flickr.com/photos/quinnanya/
https://www.flickr.com/photos/76657755@N04/

49. Part 4 – What the future
holds

50. Thoughts about the future
Applications are going to be increasingly micro-service and multi-language
Java frameworks are becoming smaller and more modular
Java itself is becoming modular
Ahead of Time (AOT) Compilation and “jimage” capabilities will become more important
Java needs to optimize for micro-services rather than monoliths

51. Wrap up

52. 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
You will have to learn new techniques
and tools
The JVM and Java applications have
to get leaner and meaner
https://www.flickr.com/photos/beigephotos/

53. Simply
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
Your application is going on a radical diet
The runtime layer needs to change
https://www.flickr.com/photos/rvoegtli/

54. Summary
1. Your business will need to adapt to ‘cloud’
2. Your developers will need to adapt to ‘cloud’
3. Your application will need to adapt to ‘cloud’
4. Your competitors are already adapting
We don’t know all the answers (or even the questions) yet.
We do know the next and largest ever pain point for Java is ‘cloud’
Big changes are needed to keep Java successful and competitive

55. Your world is changing dramatically and all
because of …

56. GB/hr

57. Any Questions?