Four Java Cloud computing evaluation

There seems to be a plot in a thriller that says, "It's easy ... It's so easy. "And then all things began to fall apart. When I started testing the top-tier Java cloud Computing in the market, I found that the episode was repeating itself.

Enterprise developers need to be more concerned about these possibilities than others. Ordinary computer users get excited when there are new scenarios in cloud computing that make life easier. They will use cloud-based emails and, if they are lost, they can only shrug their shoulders because e-mail is often lost and sometimes as often as prayers.

Enterprise developers should not be so optimistic. Every choice that allows us to make one-click Configuration will keep us locked in forever. If we adopt an overly easy cloud computing and let it do too much for us, then we are less likely to have any development.

The danger of "being stuck" seems to be hidden in every corner, which is not necessarily the worst part. What happens when we get rid of the features we need, and we're happy with cloud computing, which is something that cloud providers can't or don't want to offer? Cloud computing will be a world of constant change.

To our comfort, cloud developers are already feeling uneasy about the situation. They know that customers want a one-click solution and a high degree of automation to make life easier. But that means sending out interfaces that are non-standard or that won't allow users to adjust freely. Cloud developers have to figure out whether the market needs to do everything for cloud computing and whether customers want to be free enough to avoid "getting stuck".

For that, I tested the cloud Foundry of 4 major Java Cloud--cloudbees, Google app Engine, Red Hat OpenShift and VMware. They all have many solutions. Some clouds rely on standard tools to obtain standard war files and transmit information. Others also have their own many unique ways.

Cloud computing Experiment: Java version

Java Cloud Computing solutions are getting better and more complex, but they are far from being a complete set of products. Here are a few sets of tools that can be fully exhibited in a state where they are not completely mature. The registration form often prompts us that cloud computing is just a test application for research and development, not for production work. In fact, they are more accurate to call perhaps the cloud Postalpha beta or Prebeta beta.

Because it's all in the stones, even cloud computing, which has already been created, is often changed. Since no one really knows how the load and cost increase, the price will be adjusted, and sometimes the adjustment is very large. Cloud-Computing sellers also don't know how to determine their costs, so it's only a guess when they offer millions of of the processing price.

In the future, pricing can be a very difficult and challenging task for both buyers and sellers. People have been disappointed that Google has stopped subsidizing its app engine. Some users complain that each click makes their costs grow twice times, or even three times times. But who can blame Google? Although Google has excellent financial engineers, I am not sure whether they know the reasonable price for each round-trip to the big table Data Warehouse. They may fluctuate by heavy rains in the north-west. Because some of Google's newest data centers are built there, where hydroelectric power is the cheapest source of energy.

Maybe I think more. But there is always going to be a mistake and prices will fluctuate. Cloud computing has a greater degree of flexibility and automation, which saves us the cost of hiring people to manage these racks and ensure smooth data transmission. If Web 3.0 applications are hugely successful, and cloud computing is expensive, it can still generate enough revenue to pay for all of the program adaptations that apply to porting applications to a set of internal servers. If these web programs are not profitable enough to offset costs, the experience price will not fall. Cloud computing will eventually change: they will simplify the experiment and make adjustments.

Choosing cloud computing involves a lot of experimentation. The simplest is to find machines from Amazon or Rackspace cloud computing, but this is a much more complicated operation than a service provider promises. Yes, I press the button and I can start a computer in a few seconds, but then I spend a few hours online to install the JVM and the rest of the stack.

If you have the time and the will to create a machine image with your favorite software, the original cloud computing machine will meet most of your expectations for cloud computing, but it will also "hold You". Amazon and Rackspace make storage mirroring and replication easy. You need to select the software and determine how many machines you need. Theoretically, you can get more machines at any time. I've tried to generate new machines in everyday transactions, which is great and costs 1.5 cents per hour. When the work is done, they disappear.

Of course, you have to have a comprehensive understanding of yourself. Do you want 100 virtual machines or 102? This is a contradictory question. You have to control your costs, but you don't have the time to react, unless you have higher intelligence in this area.

Java Cloud: Google app Engine

In the process of using Google App Engine, we feel excited and comfortable. It is slowly maturing as an advanced tool and is more easily understood and used by users, perhaps because the user has accepted many of these ideas.

The underlying schema theme is the same. You upload core code with business logic, and APP engine will deploy enough examples to meet your needs. If you want to store or sync your work between sessions, you must use Google's proprietary data storage and caching, but everything feels pretty good. The first version of APP engine uses Python, but now you can add Java War files with JSPs, small service programs, and server-side logic. Managed through a separate web interface. The command line problem is almost no longer present.

While architecture and data storage are unchanged, the tools are more complex and rich, with many features and keys to adjust quotas and performance. I used the entire Eclipse plug-in to create the application, and the whole environment was similar to NetBeans and IntelliJ. The tool also integrates Google Web Toolkit with App Engine, and completes all of your programming in Java as much as possible. If you can't tolerate JavaScript or want to use the same code on servers and clients, Google's Web toolkit can translate your Java for browsers.

I think the biggest challenge for programmers is adapting to Google's relational database. When Google App Engine first appeared, there were not too many nosql projects. The idea of storing a collection of name/value pairs is a novelty. Any app engine user with a certain NoSQL experience will not be alarmed by this simple solution. But anyone who considers connecting and standardizing data needs to break old stereotypes and adapt to new ways.

The APP engine provides two levels of databases, so the architect must determine whether to pay for additional capabilities. The basic pattern is to make one data center the main datacenter and the other as the satellite data center. If your data center is down or you perform a scheduled maintenance task, your data will not be stored. You have to be prepared to face the "scheduled read-only period." Many new Web applications, such as Facebook, can easily overcome such glitches, but many applications that require financial-level availability and consistency need to consider a different approach.

Low-Rent master-from configuration is considered only the high-end version of the cost of One-third, and write costs only for high-end similar products five-eighths. However, at write speed, the lower-rent version may be twice times slower than high-end cloud computing, and there may be times when it is not writable. You have to focus on these numbers because the mechanism also includes a lot of hidden spending.

Java Cloud: Cloud Foundry

Spring is the cleanest schema in Java. This makes it meaningful to use it as a Java cloud base. SpringSource is now a part of VMware and a leader in cloud foundry. Therefore, it is not surprising that it was created at the top of the VMware virtual machine.

The earliest way to use cloud Foundry is to create a spring project from the SpringSource custom version of Eclipse using the template. The tool is called the SpringSource tool suite. I tried to install some springsource tools in my Eclipse version, but the correct collection of libraries is not easy to find. The SpringSource tool kit is very simple.

Cloud Foundry is not limited to spring, it also supports rails, Sinatra, Scala, Grails, and Node.js. Even if you don't write any Java, they can run on the JVM. Cloud Foundry recently announced support for PHP and Python/django.

VMware is still silent about its price. The product is still in beta, and VMware cannot fully price it. Cloud Foundry virtual machines are highly open, you can download portable virtual machine images from Micro Cloud Foundry--cloud environment and run them in an environment with VMware player. Its core code is open in the cloudfoundry.org and is largely controlled by Apache licenses.

Java Cloud: Cloudbees

Cloudbees not only provides a cloud for deploying applications, but also provides a tool to create them. Your account is not just a way of serving your data to the public. It also has a code base (git or Subversion) and a Jenkins server that listens for every code you enter.

I was able to enter the code and wait for Jenkins to create, test, and assemble the files and deploy them to the server. If I need more, there are a lot of other services, plug-ins, and switches.

The principle is that cloudbees has a lot of equal work in high-end boxes to create a lot of code. You no longer have to wait for your desktop machine to page into the appropriate library, instead letting Jenkins allocate your modules to cloudbees.

But I don't see any advantage. My Web application is just a JSP. The web interface that connects Jenkins always has a progress bar and a flashing blue orb, indicating that my local machine can create these files faster than the Cloudbees data center.

The essence of the Cloudbees cloud is tomcat and MySQL, but some tightly integrated third-party databases are also available. For example, Cloudant provides COUCHDB services, MONGOHQ provides MONGODB database services.

Cloudbees also offers a number of free services, but the restrictions are also very stringent. Only temporary developers like them. Any person who has long been engaged in research and development will quickly upgrade to a paid service.

Java Cloud: The OpenShift of Red Hat

Red Hat is not just about introducing a collection of Linux tools. They are also starting to move into cloud computing, their cloud computing platform called OpenShift, which can quickly deploy to machines waiting to receive Java, Python, PHP, or ruby applications. Red Hat cloud Computing provides a set of tools to deploy apps to Amazon EC2.

OpenShift is not centered on Java. Whether you create a Java application or any other type of application, it can help solve many of the deployment problems. Standard Java applications are the JBoss creator Server 7 stack created by Maven. This is a very new option and I have not found it in the latest HTML file. Instead, I stumbled upon the command line by tapping-H.

Of course, OpenShift is a good tool for those who like to use the command line. I typed a few command lines, and an JBoss application could be deployed, run, and customized, and the upgrade would be very simple.

When you provide account information, the Red Hat tool called Flex handles deployment issues. If you want to test openshift, you can try it for 30 days for free. However, these tools also deal with the testing phase and can only be used for research and development.

(Responsible editor: admin)