As the saying goes, time flies when you’re having fun. And there probably isn’t a better phrase to sum up our experience since Cisco acquired CliQr and we became the Cisco CloudCenter team just one short year ago.
A Quick Look Back
Time has moved quickly—and so have we. While many acquisitions kick-off with a slow-pace transition period, we were aggressive and were added to the Cisco Price List in just four short weeks—what we’re told was in record time. We also launched two important new product releases, CloudCenter 4.7, with a deeper Cisco ACI integration and simplified networking; and earlier this month, CloudCenter 4.8, delivering support for brownfield workloads ingested into CloudCenter management – a really important add. Together, these releases deliver on our promise of being able to put the right workload in the right place at the right time.
It’s Not Just About Product
The former CliQr team and Cisco worked hard to enable the field force and global partners to be able to sell, deploy and support CloudCenter. Cisco CloudCenter has experienced more customer wins from around the globe and across every industry, from government and manufacturing to healthcare and insurance, demonstrating impressive business growth along with the satisfaction of seeing customers capitalizing on the real power of cloud computing.
While it hasn’t always been easy—especially in the early days of the cloud—we always held to our convictions of how the cloud delivers value and what is needed to manage what we knew would ultimately be hybrid cloud environments.
We couldn’t have done this without an amazing team and we’re proud that the industry has taken notice as well. Over the years, CliQr and its CloudCenter solution has been recognized by Gartner as Cool Vendor of the Year for Cloud Management, received Best of Show in the Cloud Platform category at Interop Tokyo, and won the Software and Information Industry Association CODiE Awards in the Best Cloud Management category.
Recognition like this means more to us than a trophy in our case. Rather, it is an indicator of our passion for making the cloud, in all of its forms, the new way for businesses to exploit and optimize the use of information technology to run their operations and compete.
It’s Only Going to Get Better
As you can see, it’s been an amazing 365 days and we can’t thank our customers, partners, and employees enough for making this a tremendous first year at Cisco. We’re proud of where we’ve been—and the fun is just getting started. The cloud is at an exciting inflection point where it is both relatively new and being broadly adopted by businesses—all at the same time. This combination proves that the pace will increase, while still incurring a lot of change. It’s in this environment that we can help businesses the most.
Time flies when you’re having fun and building great products! Those who have been following CloudCenter (formerly CliQr) know that it’s been about 6 months since we were acquired by Cisco. During that time, we’ve have been extremely busy. Not only was there a lot of normal day to day activities needed to integrate into Cisco’s processes and systems, but the team was also working to crank out another great feature-filled release. I happen to be especially proud of this release since I was it’s my first release in the product manager role for CloudCenter.
Image: CloudCenter combining both cloud and data center in one platform
With my new role comes some great perks like getting to play with the engineering builds right when a new feature is completed. I’m proud to report that not only is CloudCenter 4.6 now generally available, but it’s a great, big, first release under the Cisco banner. This release delivers an even deeper integration with Cisco ACI, a more simplified networking model across clouds, and an easier deployment experience.
Deeper ACI integration
CloudCenter first introduced Cisco ACI integration about a year and a half ago—right before CiscoLive 2015 in San Diego. Naturally, after the acquisition in April, one of the first things we set out to do was to deepen that ACI integration and provide more value to our customers. The 4.6 release’s vision centered around generally increasing networking flexibility. But also giving users the option to use either existing Cisco ACI objects (endpoint groups, bridge domains, and virtual machine managers) or dynamically create new ones.
The net/net of these new and enhanced ACI features is that CloudCenter with Cisco ACI blows away any other solution to give a seamless experience, no matter if you’re using vSphere, OpenStack, Azure Pack, or any other on-premise IaaS cloud API. Network administrators gain flexibility in configuration, automation during deployment, and control of what end users are able to do via self-service on demand offerings —all without ANY coding to the ACI API. On the flip side, end users get a more consistent and expedited deployment of their application profile from an easy to use, self-service experience.
Since the acquisition, people keep asking us, “are you going to stay cloud-agnostic?” Fortunately, the answer is “Yes” and there is no plan of that changing. We continue to refine the list of clouds, versions, and regions we support out of the box. And we continue to add enhancements that support a multi-cloud world. The new “Simplified Networking” configuration works by letting an administrator abstract cloud networks and assign a label based on the network’s technical features.
As an end user, all you have to do is provide your business requirement for the application you’re deploying. CloudCenter then maps all the technical stuff behind the scenes. Need a “Secure” network in Metapod? CloudCenter will map the application in the background to “Network X”. Instead, if the application is landing on AWS, Azure, vCenter, or any of the other clouds we support, the equivalent of the “Secure” network might be “Network Y”.
By abstracting each cloud’s networks into a business requirement defined label, it makes end users’ life SO MUCH EASIER. Gone are the days when they have to know about the underlying cloud’s network capabilities. At the same time, administrators get more control and guarantee that applications are being deployed appropriately through policy.
For those old school CliQr users and admins, you’ll notice some slick new user interfaces in this release. Sticking with our mantra of “make life easy for users and admins”, we added the ability for admins to pre-set and hide certain fields from users on the deployment form, let application tiers be deployed across availability zones within a cloud region, and streamlined the deployment screen flow.
Image: New deployment environment configuration screen
Above you can see the new deployment environment configuration screen. Note the visible and non-visible settings for each field. If I’m an admin, I love this feature because it means I can lock down and hide fields that my users don’t need to worry about. Less room for error, fewer questions from users, and more smooth sailing!
There’s a ton more that made it into the CloudCenter 4.6 release and you can find it all in the release notes. In the next 6 months, you can be sure to expect more announcements of our progress, both in feature releases and as we make waves as a new product within Cisco!
I love buffets. (Especially when they are all you can eat). But what I really like is the ability to choose what and how much I want. This is where I know that the use of cloud services will become useful. When we don’t have to make an ‘either/or’ decision.
How work gets done has completely changed in just the last few years.
Fact is: business moves fast. When application developers or business leaders can’t get what they need the official way… it has never BEEN SO EASY (to go around the IT department).
Public Clouds offer so much less friction… no PO required… so can you blame them?
Third party cloud providers are doing a great job providing attractive, easy to use services. They have earned that business.
Who cares how it splinters your own company…puts your data at risk…or makes it almost impossible to transition from development to production?
We offer a couple of options for you here at Cisco:
Get Tough. We have tools that can help you identify ‘shadow IT’, those rogue operations. Find them and put the hurt on ‘em. It’s against policy… you have the company rule book to back you up.
Address the Real Issue. Just give them what they want. They are following the path of least resistance… so make it easy.
We should all be thinking of ourselves as internal service providers. We have to compete and serve company interests viewing the world as it is, rather than as we wish it would be.
What is it my mom would always say?
“You can catch more flies with honey than with vinegar.”
So how would we go about doing that?
I suggest we look towards a few winners recently announced by The Software & Information Industry Association (SIIA):
Best Cloud Infrastructure: Cisco ONE Enterprise Cloud Suite
But also, for Best Cloud Management Solution: CliQr CloudCenter… now called ‘Cisco CloudCenter’ because that team is now part of Cisco and these two winners are now integrated.
In this episode we uncover why these applications are winning awards, and what kind of pain we can help get rid of.
Thank you to TechWiseTV alum Joann Stark for bringing this one to market… and for introducing me to the smart and energetic Zach Kielich.
We will be doing a live workshop on this topic around August 18. Please subscribe to our twitter feed (@techwisetv) and monitor that for updates on where to register.
With an increased focus on exploiting a wider variety of business applications on the cloud and a broader choice of available cloud providers, enterprises need to focus on moving applications to the right cloud—not just any cloud or multi-cloud. Such a decision is often driven by factors that include the underlying cloud infrastructure’s capabilities, metrics such as availability and API reliability on the cloud, and compliance conditions including geographic location and security standards.
While these are important, a key metric towards this decision-making is the application’s price and performance across different cloud providers and cloud instance types. While the driving motivator to adopt clouds is often increased performance, scalability and cost-savings, an application’s price and performance on different clouds are the only true measure for evaluating the cause and affect of selecting the right cloud. Benchmarking clouds cannot therefore be a simple mathematical spreadsheet exercise. Any cloud benchmarking must include key price, performance and other application-centric metrics actually derived from the application being deployed and managed to determine the “RIGHT” cloud for a given application.
Every cloud is built, sized and priced very differently, which means that application price and performance varies greatly on different clouds and different configurations within each cloud. Price-performance also varies by different application type, architecture, behavior and usage characteristics. The fact is, despite the market noise, until recently, the ability to easily and simultaneously benchmark price and performance of applications across disparate cloud environments did not exist.
Cloud infrastructures today do not provide application level SLAs. Any capabilities, performance and price data is purely limited to infrastructure components such as VMs, storage, and networking. These do not translate directly to application price and performance.
Different clouds have very different underlying physical infrastructure components such as CPU, network backbone, and storage types as well as different virtualization stacks. Moreover, clouds are themselves, variable environments with significant variance in load over time. Different virtualization management including variations in VM placement policies may mean added differences in performance, not just between clouds, but also over time, within the same cloud. In the absence of transparency around VM instance and policies, it is not possible to accurately determine the differences in application performance on different clouds without migrating an application and testing the application performance on each cloud option.
Moreover, cloud instances are “packaged” and priced very differently as well. Given the above lack of transparency about cloud instances and physical backbone, an apples-to-apples comparison based on infrastructure alone is not possible. For example, what is a “small” instance type on one cloud is rarely the same as a “small” instance type on another cloud— will the vCPU’s on both provide the same performance—or will an equivalently priced “medium” instance on yet another cloud provide a overall better price-performance trade-off? Or maybe it is network performance, not CPU that matters for a particular application. Also, rolling up all the different cloud costs to estimate application costs is not straightforward as cost, performance and instance definition and configuration are inextricably linked. Understanding this and these dependent variables is what is required to understand application performance, and because of the cloud’s utility-based pricing model, better application performance may mean fewer infrastructure resources needed and hence lower pay-per-use costs. It is this type of empirical benchmarking that is required to make informed decisions on where to deploy an application on the cloud.
Given all this, a plain infrastructure-to-infrastructure comparison is not an effective means to benchmark clouds for application price-performance. As an example, consider a multi-tier web application with a highly transactional database component and with high I/O requirements between the application server and the database tier. Additionally, the application tier may be elastically scalable. A useful performance metric for such an application may be the number of requests it can handle per second while a useful cost-metric would be the total costs of all tiers combined including storage, compute and network costs. Moreover, one may want to test these metrics for different load settings to see how they change as the application scales. A cloud with a high I/O network backbone, an SSD instance type for the database tier and low VM spin-up times may provide better performance for such an application but at a high cost while a different cloud with “standard” options but lower load might provide not too degraded a performance at lower costs for a better overall tradeoff.
As a different example, consider a highly compute-intensive gene-sequencing application where gene-sequencing jobs may be processed by an elastic cluster. A useful performance metric for such an application may be the time to complete a gene-sequencing job while a useful cost-metric would be the total pay-per-run job cost.
Accordingly, here are four examples of real-world applications—each of a different architecture type and infrastructure needs. While benchmarks can be done against any Public or Private clouds, for this study, these applications were benchmarked across following clouds with different configurations in terms of instance types and cluster size on each:
HP–HPCS standard.small and standard.2xlarge configuration.
Amazon–AWS m1.medium and m3.2xlarge configuration.
Google–GCE n1-standard-1 and n1-standard-8 configuration.
The findings of benchmark study are described below with each application type. The charts on the left show application price on the x-axis and performance on the y-axis. The performance criteria can be throughput (number of requests per second) or the total time to complete a workload. The charts on the right show a price-performance index, a single normalized metric to see which cloud and configuration option provides the best “bang for your buck”.
Chart #1: Benchmark for three-tier Java Web Application with each tier running on a separate VM.
Chart #2: Benchmark for compute-intensive application run in parallel on a cluster.
Chart #3: Benchmark results for Hadoop job running on four nodes.
Chart #4: Benchmark results for high performance cluster computing job.
To summarize, the benchmark results for four different applications had following results as recommended cloud based on app price-performance trade off. Clearly, there is no single cloud instance that performs best for all types of applications.
Extra Large Configuration
Java Web App
Cloud C Medium Config
Parallel Processing job
Cloud C Medium with More Nodes
Cloud A Extra Large
High Performance Cluster Computing Job
Cloud A/Cloud B
Cloud B Medium with More Nodes
As may be clear from such examples, real-world complex enterprise applications need more than a simple spreadsheet-based back-of-the-envelope cost-estimate and infrastructure based performance analysis.
No wonder that many enterprises today find themselves having migrated to a cloud environment only to discover significant variations in spending and performance than estimated.
Let’s get back to what matters—finding the right cloud, and yes, clouds do indeed matter. For many reasons, application price and performance in different cloud environments vary greatly. What’s needed is an efficient way to find the right cloud for the application and continue to ensure complete portability so that the application can continue to move to the right cloud, with no additional migration—based on latest performance and price changes across clouds.
Check out this contributed piece on WIRED from our CEO…
If I’ve heard it once, I’ve heard it a thousand times… a CIO’s main concern with the cloud has been all around security and the cost of running applications 24/7. Well, there is ONE case that makes complete sense to run in the cloud and that is development and test. Even though I could argue that security is better in the cloud than on-premise, I’ll save that for another blog article since security is not a real concern when doing development and test.