Evolution of Java PaaS toward standards and developer control
Evolution of Java PaaS toward standards and developer control
Join the DZone community and get the full member experience.Join For Free
See why over 50,000 companies trust Jira Software to plan, track, release, and report great software faster than ever before. Try the #1 software development tool used by agile teams.
You’ve created the next amazing blockbuster Java application and now need to find a server to run it, looking for a service which would be cost-effective, elastic, compatible with your application and tools, and not trying to lock you in.
Historically, hosting services have been very inflexible. A customer looking to change out servers rented from a hosted service provider would have to wait for several days, sometimes resulting in a significant blow to credibility and other losses. Amazon, with its infrastructure-as-a-service (IaaS) solution, was able to reduce that operation to minutes, yet still left most of the server administration tasks to users. Later, first generation platform-as-a-service (PaaS) offerings, like Google AppEngine and Heroku, allowed developers to upload their application code to a preconfigured environment, but with a trade-off. Developers often had to rewrite code to run on the vendor's platform and give up control of the execution environment.
PaaS for the cloud needs to evolve to address the shortcomings of earlier platforms. This next generation platform - PaaS 2.0 - should combine the global availability of the hosting ecosystem (hosters, their customers and application developers), the standardization and flexibility of IaaS, and ease of provisioning and scaling.
Proprietary Engines to Standard Execution Environments
The first Java platforms as a service, like Google App Engine, implemented proprietary execution environments. Developers had to learn the new environment and its limitations, and change their code to work in that environment. Some platforms, like Heroku, tried to mitigate this problem by taking an existing open source server and customizing it. While this made the learning curve smaller, the limitations imposed on developers, such as the absence of multi-threading and limited server choice, meant that most existing applications could not be deployed "as is" in PaaS. This kind of worked in limited languages like PHP and Ruby, but is totally incompatible with Java.
Java, a popular and established programming language, is supported by numerous application servers that suit various deployment scenarios. The Wikipedia page on Java Platform Enterprise Edition lists a variety of server options, including Tomcat, GlassFish and Jetty - each with its share of devoted users and advantages in particular scenarios. Developers are not eager to switch between servers and want the exact environment required by their applications.
The same situation is true for database servers. Older platforms offer either proprietary solutions or support only one type of database server, such as MySQL, so the environment topology for the applications can't be set up. Use of proprietary storage platforms, such as Google's Big Table or Amazon SimpleDB, lock developers into a specific service and hold them hostage to changes in the service provider's policies. Recent price increases by Google AppEngine illustrate the problem.
PaaS 2.0 should offer a wide range of application and database servers. This is the only way that developers can achieve 100 percent compatibility with existing open standards, use a wide range of libraries and frameworks, and establish environment topologies according to their tastes, needs and knowledge, without vendor lock-in.
Separation of Platform and Service
Early PaaS offerings lack a separation between platform and service. Google, for example, is the only service provider offering Google App Engine. Amazon is the only one offering Amazon Elastic Beanstalk. Salesforce.com (the owner of Heroku) is the only one offering Heroku, and so on. If you like the platform, but don't like the service - too bad. If the price goes up (as in Google's case) or if you need the service outside the U.S. with a different set of service level agreements (SLA) or certifications - again, too bad. This marriage between platform and service limits consumer choice and stifles innovation.
PaaS needs to evolve to an ecosystem model where platforms are developed by software companies, and the service is available in multiple geographies, across a variety of industries, at attractive price points, and with value-add options from an ecosystem of hosted service providers.
Scalability for first-generation PaaS offerings came at a price. Platforms were not able to automatically add resources, such as RAM and CPU, when apps needed them. Instead, developers had to change their apps to use multiple parallel machines, and add machines each time more resources were needed.
While horizontal scaling creates highly scalable and available Internet applications, it imposes huge additional requirements on application developers, making code redesign necessary just to ensure the application has the resources it needs.
The next-generation PaaS needs to be more flexible in adapting to applications. If a developer chooses to run a single instance of an application (or the application is just not designed to run on multiple machines), the platform needs to automatically give the application the resources it needs when usage goes up. The same is true when usage goes down. If no one is using the system at 1 a.m. and it only needs 128 MB of memory, PaaS needs to automatically recycle the rest of the resources to reduce the bill.
PaaS 2.0 shouldn't force developers to change their applications and behaviors, but should support both scaling scenarios without imposing limitations.
Control over the Environment
Like the limitations that early PaaS imposed on the application server, developers were also very limited in how they could work with the execution environment to extend and control it. If an extra library was needed for an application, the developer could only use frameworks made available by the vendor. If the developer needed to fine-tune server configuration files or add new ones, he was out of luck if the application did not fit within the platform's limits. PaaS 2.0 needs to allow developers to use all of the libraries and configurations currently available.
Graphical User Interface
Usability is another key requirement for PaaS technology to go mainstream. First-generation PaaS platforms often required using obscure command-line utilities to get anything done, making the learning curve even bigger and limiting its use among enthusiasts. PaaS 2.0 needs to easily integrate into the tools that developers know and use already with a highly intuitive graphical user interface of its own.
You are obviously welcome to try the free beta of Jelastic at http://jelastic.com and see how it stacks up against the principles of PaaS 2.0 listed above.
Opinions expressed by DZone contributors are their own.