This document discusses how the economics of cloud computing will change how Java applications are developed. Cloud providers charge for computing resources on an hourly basis (e.g. $ per GB per hour), which means applications need to use resources efficiently. Java applications generally use more memory and have longer startup times than other languages. To be cost effective in the cloud, Java applications will need to reduce their memory footprint, decrease startup times, and be designed to fail and recover gracefully. The rise of APIs and microservices also requires changes to make Java more modular and efficient in constrained environments.

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

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 (whatever that means!)
@spoole167

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 - How Java measures up
• Part 3 – The API economy and Java
• Part 4 – wrap up

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

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

21. Part 2 - How Java measures up

22. Compute == money Easier than ever
before
a business can buy a
CPU
Just for how long they
need it.
No long term capital
investment.
Just as much as they
need
$ == GB/hr
-Xmx: $100

23. So what do I get for the money?

24. Real costs – it’s confusing
Offering RAM Cost 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.

25. Example costs
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 10 containers in
parallel
2890.80 for 40
cpus
$1987.20 for 10 cpus
Reducing memory footprint
by 10% saves
289.80 $0

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

27. 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
BTW – think about this:
Everything that happens at startup – happens
every time, all the time.
https://www.flickr.com/photos/91295117@N08/

28. Java & fast startup time – It’s known for it!
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.
what about
“ Everything that happens at startup – happens
every time, all the time”

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

30. N-Body Memory Footprints (lower is better)

31. N-Body Completion Time (lower is
better):

32. N-Body Completion Time, normalized for
100MB of memory (lower is better):

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

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

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

36. Part 3 – The API economy
And what that means for Java

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

38. 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’s 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?

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

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

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

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

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

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

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

46. Part 4 – wrap-up

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

48. Multiple languages on the JVM.
What’s the benefit of running
them on the JVM vs having a
native service?
They can take more memory,
and take longer to execute.
Cloud applications are
increasingly heterogeneous.
Anyway they share data not
objects
Nashorn JavaScript engine delivered in
JDK8
Utilizes new JVM level features for
performance
Avatar.js provides Node.js support on
Nashorn
Results of “Octane” JavaScript
benchmark using Java 8 pre-u20
Node.js is 4.8x faster
Avatar.js is >10x larger
Feb 12th
, 2015: Avatar is “put on hold”
https://blogs.oracle.com/theaquarium/entry/project_avatar_update

49. More thoughts
• Do we need a JVM anymore? If your container has code that will ONLY run
on one OS/arch do we need hardware abstraction like class files and
bytecode?
• Modularity etc coming in Java 9 helps reduce footprint and some startup
time.
• We need more AOT to convert Java into executable code once only
• Individual service lifetimes are short so dynamic recompilation is not useful
unless the generated code is shared. How do we share compiled code
cheaper than it costs to generate the code?
• Remember – you’ll be paying for all the ‘wasted’ CPU / RAM etc.

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

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

52. GB/hr

53. https://www.flickr.com/photos/pasukaru76/
The story ends – you wake up and
Java is what’s it’s always been
The story ends – you wake up and
Java is what’s it’s always been
You stay in wonderland and see
how deep the Java goes

54. Thank you