Cloud Economics for Java at Java2Days
Download as PPTX, PDF1 like321 views
The document discusses how the economics of cloud computing will change how Java applications are developed and deployed. Specifically: 1. In cloud computing, customers pay for computing resources like CPU and RAM on an hourly basis, creating a direct link between cost and resource usage. This will drive Java applications to use fewer resources to reduce costs. 2. Java applications will need to have faster startup times, smaller footprints, and be designed to fail and recover quickly to work well in cloud environments. 3. The growth of APIs and sharing data/services means Java developers will need to focus on building reliable, performant, and well-documented APIs to monetize data and services. 4. Significant changes
Cloud Economics for Java at Java2Days
- 1. All Change! https://www.flickr.com/photos/teegardin/ why the economics of Cloud will make you think differently about Java
- 2. Steve Poole – IBM Making Java Real Since Version 0.9 DevOps Practitioner (whatever that means!) @spoole167
- 3. 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
- 4. 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
- 5. Part 1 – The economics of Cloud provisioning
- 6. Why ‘Cloud’ ? Your business wants needs to get ideas into production faster, cheaper and with less risk A big challenge is its traditional infrastructure A local, hand-crafted, static environment which requires in-house specialist support, doesn’t scale well and requires long term investment and commitment s://www.flickr.com/photos/sylvar/
- 7. 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
- 8. 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..
- 9. 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”
- 10. http://www.fodey.com/generators/newspaper/snippet.asp Hybrid Cloud is coming to a data centre near you
- 11. s://www.flickr.com/photos/skohlmann/ The ability to have ‘cloud burst’ capacity is changing the way software is being designed, developed and supported
- 12. We’re moving to a more industrial scale v1 v2 v3 time compute capacity
- 13. V1 We’re moving to a more industrial scale v1 v2 v3 time compute capacity
- 14. V1 V1.1 V1.2 V1.3 V1.4 V1.5 V1.6 V1.7 v1 v2 time compute capacity We’re moving to a more industrial scale v3
- 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
- 21. Interlude
- 22. You run a tram company • How do you most profitably get people from A to B? A B
- 23. If there are more passengers waiting than the tram can hold you will lose business (no one waits a hour for the next tram) 1 tram an hour?
- 24. If there are few or no passengers waiting you lose money 1 tram an hour?
- 25. Less likely to lose customers. More likely to have empty seats 1 tram every 10 minutes?
- 26. Bigger trams in the rush hours? Better: but you’ve got to predict demand accurately or you could be worse off than before (more idle or empty trams)
- 27. Lots of really small trams? Helps with maximizing usage but don’t go too far. You need to maintain and support each tram
- 28. There is no simple answer you need to be able to react to demand More passengers = more trams or larger trams Few passengers = less trams or smaller trams No passengers = no trams?
- 29. The economics are simple • react to demand as quickly as you can – Rush hour vs slack times – The faster a service starts the less likely you are to lose customers • Have the smallest unit of supply you can afford – Don’t buy really big carriages – Single purpose services are more flexible to scale than large monoliths – Don’t buy really small carriages – Too small and your infrastructure and support costs escalate • deliver the unit supply as cheaply as you can – Don’t buy expensive trams if cheaper ones can do the same job – Smaller memory footprint for the same response time wins
- 30. Part 2 - How Java measures up
- 31. 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
- 32. 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/
- 33. 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/
- 34. 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”
- 35. 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/
- 36. https://www.flickr.com/photos/isherwoodchris/ • Q: How much RAM does your application use? • A: Too much
- 37. 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/
- 38. 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/
- 39. Part 3 – The API economy And what that means for Java
- 40. 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.
- 41. 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?
- 42. 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
- 43. How scary? design, coding, deployment , startup, execution, scaling debugging, security, resilience … Almost everything about your application is effected https://www.flickr.com/photos/mjtmail/
- 44. 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
- 45. 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/
- 46. 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 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/
- 47. Debugging • Q: Why can’t you just keep the failed instance around? • A: You can – if you accept the $$$ consequences…
- 48. 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
- 49. Part 4 – wrap-up
- 50. 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/
- 51. 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_avat ar_update
- 52. 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.
- 53. 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
- 54. Your world is changing dramatically and all because of …
- 55. GB/hr
- 56. Thank you