Ce diaporama a bien été signalé.
All Change – why the economics of
Cloud will make you think differently
THE INFORMATION CONTAINED IN THIS PRESENTATION IS PROVIDED FOR INFORMATIONAL PURPOSES ONLY.
WHILST EFFORTS WERE MADE TO VERIFY THE COMPLETENESS AND ACCURACY OF THE INFORMATION CONTAINED IN THIS PRESENTATION, IT IS PROVIDED “AS IS”, WITHOUT
WARRANTY OF ANY KIND, EXPRESS OR IMPLIED.
ALL PERFORMANCE DATA INCLUDED IN THIS PRESENTATION HAVE BEEN GATHERED IN A CONTROLLED ENVIRONMENT. YOUR OWN TEST RESULTS MAY VARY BASED ON
HARDWARE, SOFTWARE OR INFRASTRUCTURE DIFFERENCES.
ALL DATA INCLUDED IN THIS PRESENTATION ARE MEANT TO BE USED ONLY AS A GUIDE.
IN ADDITION, THE INFORMATION CONTAINED IN THIS PRESENTATION IS BASED ON IBM’S CURRENT PRODUCT PLANS AND STRATEGY, WHICH ARE SUBJECT TO CHANGE BY IBM,
IBM AND ITS AFFILIATED COMPANIES SHALL NOT BE RESPONSIBLE FOR ANY DAMAGES ARISING OUT OF THE USE OF, OR OTHERWISE RELATED TO, THIS PRESENTATION OR ANY
NOTHING CONTAINED IN THIS PRESENTATION IS INTENDED TO, OR SHALL HAVE THE EFFECT OF:
- CREATING ANY WARRANT OR REPRESENTATION FROM IBM, ITS AFFILIATED COMPANIES OR ITS OR THEIR SUPPLIERS AND/OR LICENSORS
Your Guides for Today’s Journey
Steve Poole – IBM
Making Java Real Since Version 0.9
DevOps Practitioner (whatever that means!)
Chris Bailey- IBM
technical architect for runtime
monitoring and diagnostics
This talk is intended to make you
• Think about how you use compute resource today
• Think about how that use may need to change tomorrow
• Starting measuring your application profile now
• Try out cloud technologies and gather real experience
• Wonder where Java is going next
This talk is about how this sort of measurement:
Is already changing your life & the direction of the
The ‘Cloud’ has a lot to answer for
• Part 1 – The economics of Cloud provisioning
• Part 2 - How Java measures up
• Part 3 – The API economy and what that
aaaaaaameans for Java
• Part 4 – Our thoughts
Part 1 – The economics of Cloud provisioning
Why ‘Cloud’ ?
A local, hand-crafted, static
environment which requires in-house
specialist support, doesn’t scale well
and requires long term investment and
a virtual, dynamic
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
AND be able to do that very quickly
and repeatedly in parallel
How quickly do you need to get good code into
• 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..
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
70% of IT Leaders are pursuing a hybrid cloud
Hybrid Cloud is coming to a data centre near you
The ability to have ‘cloud
burst’ capacity is changing
the way software is being
We’re moving to a more
Why buy one computer for
a year when you can hire
365 computers for a day..
“Compute on demand” – it’s what we always wanted
We really are getting closer all the time to
‘Compute on Tap’
But with taps come meters…
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
American Society of Civil Engineers
Part 2 - How Java measures up
Compute == money
Easier than ever
a business can buy a
Just for how long they
No long term capital
Just as much as they
$ == GB/hr
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
Bluemix (CF) Amazon (ECS)
Running a 512mb
container for a year
$289.80 for 4
198.72 for 1 cpu
footprint by 10% saves
Running 10 containers
2890.80 for 40
$1987.20 for 10
footprint by 10% saves
N-Body Memory Footprints (lower is better)
N-Body Completion Time (lower is
N-Body Completion Time, normalized for
100MB of memory (lower is better):
(you have loads)
Java applications have to get lighter.
Java 9 modularity will help but you
have to consider footprint across the
Choose your dependencies wisely
Your choice of OS & distribution is
The aim is ‘carry on only’
Your application isn’t going on a
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
BTW – think about this:
Everything that happens at startup –
happens every time, all the time.
Java & fast startup time – It’s known for it!
Application developers can reduce service
startup time by deferring optional costs to when
Maybe even create services with different
behaviors rather than one with optional
But it’s not enough
The JVM needs to revisit all the places where
startup time was traded for throughput and turn
“ Everything that happens at startup –
happens every time, all the time”
For container based services – all this
start up effort happens multiple times
during development and testing (let
along during 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
• Q: How much RAM does your
• A: Too much
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
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
Multiple languages on the JVM.
What’s the benefit of running
them on the JVM vs having a
They can take more memory,
and take longer to execute.
Cloud applications are
Anyway they share data not
delivered in JDK8
Utilizes new JVM level features
Avatar.js provides Node.js
support on Nashorn
benchmark using Java 8 pre-
Node.js is 4.8x faster
Avatar.js is >10x larger
, 2015: Avatar is “put on hold”
Java applications are going to be
running in a remote, constrained and
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
Part 3 – The API economy
And what that means for Java
The API economy
If your company has data it will
eventually be shared and monetised
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.
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?
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
You will have to design, code, deliver, support and
debug code in new ways
It’s going to be scary
design, coding, deployment ,
startup, execution, scaling
debugging, security, resilience …
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
Every IO operation you perform may fail – do as few as possible
Every IO operation may stall – costing you GB/hrs and resources– timeout
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
Remote support for your family?
Fancy having to do that for your own
You have to assume:
You will never be able to log into a
You will never be able to attach a
remote debugger to a failing app
All problems must be resolved by local
reproduction or logs and dumps
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
Learn to love logs, dumps and traces.
Remote log stores and tools are
going to be your best friend
BTW: they’ll cost too
• Q: Why can’t you just keep the failed
• A: You can – if you accept the £££
Hard metrics and
keeping a failed app around
or having apps on standby
can be costly in multiple ways
Runtime costs and taking up
vital resource allocation
Part 5 – our thoughts
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
The JVM and Java applications have
to get leaner and meaner
You have to learn new techniques and
• 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?
• Linker coming in Java 9 helps reduce footprint and some startup
• We need more AOT to convert Java into executable code once only
• Individual service lifetimes are short so dynamic recompliation 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.
Has this talk made you
Think about how you use compute resource today?
Think about how that use may need to change tomorrow?
Want to measure your application profile now?
Want to try out cloud technologies and gather real
Made you wonder where Java is going next?
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