Java Developer Prerequisites: PAAs Solution Inventory

PaaS (Platform-as-a-service) is a kind of cloud service, the service provider not only provides on-demand hardware and operating system services, but also provides the application platform and solution stack. For developers, PAAs greatly reduces the cost and pain of it deployments, providing resources for applications to scale more easily as needed.

The JVM, application server, and deployment packages (for example, war and Ear) provide a natural isolation for Java applications, allowing different developers to deploy applications in the same infrastructure, so the Java platform is ideal for PAAs. But over the past few years, most PAAs products have been built around platforms such as Ruby and Python, when Google App engine was the only PAAs service available to Java developers. Fortunately, the situation has improved considerably.

Almost from last year, a number of business operators entered the Java PAAs domain. The move is meaningful because Java developers are almost 10 million, perhaps one of the largest developers in the world. In this article, we will compare these service providers from the developer's perspective. In particular, the following 4 aspects are specifically compared:

In this article we will compare the following Java PAAs products (sorted alphabetically).

Amazon Elastic Beanstalk is a Java PAAs product built on the EC2 cloud by Amazon. It provides a managed tomcat instance running on EC2, with a load balancer and the ability to provide scalability on demand. Amazon Elastic Beanstalk integrates other services from Amazon Web Services to access managed relational databases (RDS), large data storage (SimpleDB), Message Queuing, e-mail, and other services.

Cloudbees, a VC venture company composed of JBoss and Sun's former employees, recently raised 14 million dollars in two rounds of fundraising. Cloudbees may be a new name, but its influence in this area is growing, bringing a number of unique features to the Java PAAs, especially continuous integration-a complete cloud development/deployment lifecycle management. In addition, like Heroku, it also contains a market for Third-party plug-ins and services.

Cloud Foundry is an Open-source product initiated by VMware. VMware software drives virtualized data centers, the foundation of most PAAs products. VMware is also the owner of the spring framework, which is a very popular platform stack in Enterprise Java. A unique feature of Cloud Foundry is that it does not need to be a managed PAAs, you can download its code and host the paas! so that it is both a managed platform and a managed PAAs service.

Google App Engine for Java may be the longest (and most mature) Java PAAs product in the market. Its goal is to provide linear scalability and not worry about making dramatic changes to the Java platform itself.

Heroku for Java is a product recently launched by the PAAs manufacturer Heroku, and Heroku is popular in the Ruby community.

Red Hat OpenShift is an experimental product of the Red Hat test-water PAAs. Red Hat's JBoss Creator server (AS) is one of the most popular Java application servers, and the OpenShift service provides full jboss as support.

Supported technology platforms and technology stacks

One of the most important attributes of a Java PAAs provider is the technology platform and Technology stack it supports. In summary, the technology platform is where Java PAAs differs from other PAAs offerings. In the long term evolution of the Java platform, many competitive technology stacks have emerged. For Java PAAs vendors, I believe it is important to support as many different technology stacks as possible.

OpenShift and Cloudbees support the broadest range of technologies, from simple servlet containers (typically Tomcat) to the full Java EE 6 Web profile (JBoss as 7). The Java PAAs pioneer, Google App Engine, has the biggest gap with the successor in standard support. Google APP engine does not support the full Java SE platform, so support for many popular frameworks is poor. It also requires users to use Google Apps to engine their own network and persistence APIs, rather than to support open standards, which makes it difficult for applications to migrate. Similarly, Heroku for Java requires applications to encapsulate their own jetty instances, breaking the deployment model of traditional Java EE applications.

The Cloud Foundry Project supports the Tomcat container, but its application development and deployment has done a lot of optimization for the spring framework, creating a half-external dependency. Because VMware has the spring Framework, Cloud Foundry is ideal for spring based applications. In addition, it supports the use of RABBITMQ Message Queuing, which is based on the AMQP standard. But its support for other Java frameworks, such as Java EE, is weak.

One of the key values of PAAs is to make life easier for application developers because it eliminates the overhead of application and resource management. So, being friendly to developers and having tool integration is an important consideration for us.

In this respect cloudbees is undoubtedly the winner. It is not only a PAAs runtime environment, but a complete build and test environment. Developers can use the Jenkins service to allow Cloudbees to automatically and continuously check out, build, test, and report code in the code base. This continuous integration process has been applied to several large teams as an important part of their software development process. However, building server management is a time-consuming and laborious task for QA teams. Cloudbees the QA team for the pain, making the process more transparent to developers. Recently, Red Hat OpenShift has slowly overtaken cloudbees in this field by supporting Maven and Jekins integration.

Amazon Beanstalk, OpenShift, and Google APP engine all offer development tools, SDK, and IDE plug-ins that are consistent with other java-based tools available on the market.

Compared to Java developers, Cloud Foundry and Heroku for Java provide tools that are better suited to ruby developers. After experimenting with these tools, I suspect that many Java developers may take some time to adapt to their conventions and terminology. In addition, Cloud foundry currently lacks documentation, for example, many of its documents are in the form of video tutorials. While video tutorials are easy for developers to get started with, there is a clear lack of depth when deploying important applications or wanting to know what is outside the video scene. Although the Cloud foundry platform has undergone major changes in recent years, the official guide document dates back to 2007 years. There are already more documents-such as this one, but they shouldn't be so hard to find.

Another important issue, Cloud Foundry allows developers to configure their own cloud environment, and deploying micro Cloud can be a lot more cumbersome than just installing an SDK. This is also a barrier, so many developers to cloud foundry prohibitive.

Performance and Scalability

One of the most important features of PAAs is the ability of the platform to scale automatically to increase or decrease server capacity based on real-time traffic requirements. This requires the platform provider to load balance the requests among the numerous servers, monitor the load of each server, and start the new server in due course.

All PAAs providers support automatic scaling to some extent. But automatic scaling is far more difficult than it looks. For entry-level users, Java EE applications must be configured to access a centralized external database instead of accessing a database deployed on the same server. All PAAs provider programming paradigms and tools are mandatory for developers to follow this approach.

The bigger problem is the HTTP session. On the Java application Server, the session state of the HTTP session is managed by default in memory. To build an application that can load balance between different servers, the developer must use one of the following methods:

Configuring the Load Balancer to support sticky sessions (sticky session), the load Balancer examines all incoming request session IDs and always sends requests for the same session to the same server. This is the easiest way to do it, but it has its own problem: load balancers need to do more work, and over time load distribution becomes less balanced, and when the load drops, it's hard to pull down the extended infrastructure because each server has its own session. For these reasons, few PAAs providers support this approach.

Configures a shared cache for an in-memory HTTP session. As a result, all servers can have all HTTP sessions in memory at all times. However, replicating memory sessions in a cluster is a task that consumes both bandwidth and computational resources. It requires application developers to configure shared caching and replication policies.

You can also configure the application to persist all HTTP sessions to an external relational database.

Of all the PAAs platforms listed above, Google App engine is best at dealing with this problem. It abstracts the concept of a single server on the architecture, automatically creates data stores on different servers, and by default saves HTTP sessions to the data store, a process that is transparent to developers. But the problem with Google App engine is that native performance is so bad that a Web request takes 1-3 seconds to complete a database visit.

Each server instance of Heroku for Java encapsulates a custom jetty instance, so it also provides the ability to automatically share sessions across server instances. However, Heroku does not offer transparent automatic scaling, you need to watch the dashboard and add resources to the application at the appropriate time.

The remaining standard Java PAAs Products force developers to create data tables on specialized database servers, which is part of the deployment process. For HTTP sessions, Cloud Foundry uses sticky sessions in the load balancer. As discussed above, this approach facilitates developers and has some serious problems. Other PAAs products, while not straightforward, leave the work of session management to application developers.

Price and other business considerations

For developers, the price of PAAs products is very important. Most service providers have free services for developers to try out, and these free services are a good choice for smaller Java Web sites.

But as the recent price hike in Google App engine reflects, the cost of using PAAs for large Web applications is high.

Another important factor to consider is support. Google App engine and Amazon Web Services are doing poorly on support. Developers can only find answers on the forums themselves. Smaller, Java-focused providers offer better technical support, as well as public forums. In my opinion, Cloudbees offers the best support, combining the support of the billing questionnaire with the Java expertise of the support staff.

We discussed 6 well-known vendors in the Java PAAs field, and of course, there are some smaller or less well-known providers, such as:

Jelastic: It supports a combination of many application servers and databases, including multiple variants of MySQL databases and NoSQL databases.

WSO2 stratoslive: It is a PAAs product built on the WSO2 application server, WSO2 is an application server that complies with Java EE specifications.

Cumulogic: It provides the Java application services PAAs that can run on many private cloud and public cloud solutions, including Cloudstack, OpenStack, and eucalyptus.

We will keep an eye on these small vendors because they can easily grow up to challenge the market share and attention of big manufacturers.

The Java PAAs has gone through a lot over the last 12 months and a variety of products are still booming, which is great news for Java developers looking for Low-cost, scalable, and even free hosting solutions. For Java EE developers, I believe that Cloudbes and OpenShift are the best products available on the market, and that Cloudbees is the winner of the game, given that OpenShift is still in beta. If you're willing to try outside the Java specialist, Heroku for Java and Cloud Foundry (Beta) is a powerful competitor to the old Google App engine. View English Original: A Java Developer ' s Guide to PaaS