Review: CliQr clicks for cloud management

Deploying applications on IaaS clouds such as Amazon can be accomplished much more quickly than buying and configuring physical servers and networking equipment, but it’s still a lot of work. Many products help ease cloud deployment and operations, including platforms as a service such as Bluemix, container systems such as Docker, and scripting engines such as Chef and Puppet. Even so, if you need to move your application to a different cloud platform for better geographical coverage or lower costs, you may see looks of sheer panic from the staff tasked with doing the migration, because their scripts and application configurations will all need to be revamped.

Unfortunately, every IaaS has its own user interface and its own scripting APIs. There is enough in common that an abstraction layer is possible, however, and that’s essentially what CliQr CloudCenter has implemented in its Cloud Smart Orchestrators (CSOs). By working through CSOs from a centralized user interface, CloudCenter gives you a single place from which to deploy applications to many different public and private clouds, with support for cloud migration, governance, management, and benchmarking.

For this review, I used CliQr’s SaaS edition of CloudCenter, starting with a copy of the classic Java PetClinic application along with a JMeter JMX script. Apache JMeter is supported internally for load testing and benchmarking by CloudCenter. You simply provide the test definition, which you’d typically develop using a copy of JMeter on your own computer.

The first step in using CloudCenter is to define a new app (Figure 1). For this exercise, I used the Java Web App profile and uploaded the PetClinic.war source file, a SQL script for loading the database, a PNG image for the app, and the JMeter configuration.

Defining the topology was a matter of simplifying the default Java Web App profile to include a Nginx load balancer, a multinode Tomcat app cluster using the uploaded WAR file, and a single MySQL node using the uploaded initialization script (Figure 2). I didn’t have to copy any GUIDs or IP addresses from node to node; CloudCenter conveniently does that for you based on your diagram.

Tomcat was one of 13 Web servers available from CloudCenter, Nginx was one of four load balancers, and MySQL was one of seven SQL databases. I ran all of the app components on Ubuntu 12, but they were also available preconfigured on CentOS 6. RHEL, SLES, and Windows Server 2008 base images were available as well, but not with these components preconfigured.

I deployed this app initially on m1.small (one CPU, 1.7GB of RAM) Amazon EC2 instances, basically to make sure it worked. It worked, but the performance left something to be desired, even with only one user (me). This was apparent from the response time as well as the KPI charts (CPU, memory, and disk utilization) available during the run, which saturated for simple requests. I canceled this run after about an hour; it used a total of 3.5 node-hours and cost a mere 18 cents -- yes, 18 cents.

Benchmarking your cloud app

For benchmarking, I chose an assortment of fairly small Amazon EC2 and Google Cloud instances. I had to copy the source files from Amazon to Google before using any Google instances. That was a little annoying, but CliQr will remove the necessity for this in the near future, by allowing the code to live in its own cloud storage and be updated from your repository.

As you can see at the left of Figure 3, running the first set of benchmarks using two nodes for the AppCluster (CliQr’s term for the application tier) yielded a scatter graph of requests per second versus cost per hour for various Amazon and Google cloud instance sizes. On the right is a bar chart of the price performance index. Note that the best performance in this set of runs delivered 28 requests per second for $1.41 per hour. The benchmark costs ranged from 35 cents to $1.48.

For a real deployment you’d probably set your minimum and maximum number of nodes to be different, and you'd enable automatic scaling with a rule about CPU utilization or number of users. For benchmarking purposes I set the minimum and maximum number of nodes the same.

Suppose you needed more than 28 requests per second? My guess was that you’d need more CPUs and more nodes, so I ran a second set of benchmarks using four nodes for the AppCluster, which is the part of the Web application that typically needs to scale horizontally. The database and load balancer typically need to scale vertically.

Why did I have to guess? CloudCenter doesn’t currently show you KPIs for a benchmark. You can get around this limitation by running JMeter or another load testing package manually from another cloud instance and watching the KPIs of a deployment. I didn’t need that level of accuracy, as my previous experience helped me guess decently.

Figure 4 shows another scatter graph on the left of requests per second versus cost per hour for various Amazon and Google cloud instance sizes, using four nodes for the AppCluster, which showed a big improvement in performance over the two-node topology. On the right is a bar chart of the price performance index. Note that the best performance in this set of runs, on a Google n1-highcpu-8 instance for the AppCluster and n1-highcpu-4 instances for the load balancer and database, delivered 106 requests per second for $1.76 per hour. Also note that four of the instance types are clearly suboptimal for this particular application, apparently because the application was not using all the (expensive) memory in the instance.

That whole benchmarking process took a couple of hours, including setup and teardown. In the past, load tests of Web applications on VMs with a hardware load-balancing switch have taken me multiple days to set up and a full day to run.

Unfortunately, the results of these benchmarks tell you very little about the “best” cloud and configuration for your own application. Within databases, for example, you’ll see very different requirements for MySQL, SAP Hana, and Cassandra. Each of the Web and application servers has its own profile. For example, in my experience Apache uses relatively little CPU compared to the Java application servers. Ultimately, your app will have distinctive requirements, having as much to do with the coding as the underlying servers and components.

Management, governance, and migration

When I was CEO of a startup (since shut down) that had a largish application running on Amazon, I kept facing resistance from the developers when potential customers wanted to run on private clouds in their data centers. For an enterprise with many cloud applications, this sort of consideration comes up a lot.

Ideally, developers and testers should be able to spin up public cloud instances as needed for, well, development and testing. You would typically not use real customer data for that, and the cost won't likely be very high. The purpose for this kind of devops is to facilitate the development process. Once you get to production, however, you can quickly encounter significant loads, lots of data, and high costs if you run in a public cloud. In the long term, you might find it’s far cheaper to deploy heavily used production applications in your own data center.

On the other hand, something like a school registration application might be used heavily for only a few weeks before each semester, when it would be cheapest to run in your own data center. The rest of the year, it could live in relatively small public cloud instances that were set to scale out on demand, freeing up memory in the data center for other processes.

The ability to migrate apps easily makes CliQr’s CloudCenter valuable for this use case. The abilities to define governance rules and centrally manage all applications complement the migration facility.

CloudCenter is already useful, even though it has a few unpolished areas. It has the potential to control cloud computing costs as well as enabling efficient deployments by making benchmarking easy to perform. For companies working with multiple clouds, CloudCenter can make that usage both more intelligent and more manageable.

This story, "Review: CliQr clicks for cloud management" was originally published by InfoWorld.