Monday Feb 03, 2014

PaaS for Java Developers

The concept of Platform as a Service promises a deployment and runtime option where operating systems and services are managed for you, where scalability concerns are handled more or less automatically and where late-night calls about unavailable systems are a thing of the past. But how close is this to reality? In the "Java PaaS" hands-on lab at the Jfokus conference today, developers learned about the current PaaS landscape.

HÃ¥kan Jonson and Patrik Fredriksson, both developers at Citerus, presented ideas based on their experiences delivering business applications in the cloud. They provided help with how to "navigate your way through the swamp of vendor logos." The PaaS industry has moved from infancy to consolation quickly, so it's great to get advice experienced users.

Here are the guidelines they provided on what to consider when looking at PaaS providers. You should consider:

  • The company's level of maturity (how far out of beta are they? can they point to success stories?where is the documentation?)
  • What are the deployment routines? (how hard is it to set up? how long does redeployment take? do they offer CI? )
  • What tooling is included? (admin, monitoring)
  • What is infrastructure and service stack technology? (on top of EC2? machines running in someone's a basement? what's the language and DB language support?)
  • SLA and legal considerations (where are the machines physically running? will your app be affected by network latency?) 
  • What is the pricing model? (fixed price or by consumption? how do you pay?)

and, most importantly,

  • What is Your ESCAPE ROUTE? How do you get your app and data out if things go wrong? 
To protect yourself, it is best to:

  • Use an established and mature tech stack (established/common technologies may not be the flashiest, but ubiquity makes it much easier to switch)
  • Keep the number of platform customizations to a minimum
  • Own your data (have your own import/export procedures)

Johson told a story of a having spun up an app very quickly and having "three exciting weeks with the app running. It had deployed very quickly. We had 99% uptime!" Then they started learning the limitations of their vendor. They needed more instances than originally planned (dev, test, production), therefore got a higher bill for infrastructure (the client was not happy to learn this). When they started to tweak the JVM, it took them outside the vendor's "standard config." Security issues came up when they learned that data going between nodes was unencrypted. The physical location of the cloud instances had an effect the application's responsiveness. All of this lead to the painful realization that the vendor's support staff was a different time zone, leaving only a two hour overlap of business hours.

The last straw was when the vendor accidentally deleted the entire application, including data. It took the vendor several hours to get the app back online. This lead them to the three most important considerations:

  • OWN YOUR DATA - they were able to switch to another provider in 3 hours
  • BE AWARE OF GEOGRAPHY - both for network latency and tech support hours
  • PRICING - expect to need mirrored environments (stage and test) or prices might be higher than you expect

With this much to consider, is PaaS really worth it? Why not just do IaaS? A good question, but as a developer, PaaS provides a quick way to spin up an application, automatic scaling, OS updates, and for you, the developer, it's one less thing to worry about.  A few PaaS vendors even provide a free tier to get started with. As with all technologies, PaaS has advantages and disadvantages. Nikoloas Roumpoutsos was at the lab and liked it because "it's always good to have another tool in your toolbox."

About

Insider News from the Java Team at Oracle!

duke
javeone logo
Links


Search

Archives
« February 2014 »
SunMonTueWedThuFriSat
      
1
2
4
6
8
9
11
15
16
17
19
20
21
22
23
24
27
28
 
       
Today