In my last podcast I briefly mentioned the aspects of performance when moving to the public cloud. I said I was going to come back to it, and here I am. I’m doing it as a blog post as sometimes a picture is worth a 1000 words.
What platform do I choose?
When a company takes a workload to the cloud in general and the public cloud in particular, the choice of the T-shirt size is important for two reasons, a too large T-shirt costs too much, a too small one does not allow the workload to deliver a satisfactory customer experience in all cases. So, the question is really how to define the right T-shirt size. And that is where things are getting complicated.
In Public Cloud you get what you get.
When I buy a physical server, I know from its specifications exactly what performance I will get. Knowing which operating system I will use, I can define the available performance for the application the server will support. Things are straight forward.
When I use a virtual machine things are already a little more complex. But as I manage the different virtual machines that will run on the physical box, I can ensure I get for the application the performance I require.
If I use a private cloud, I can control the placement of the workloads by adapting the placement rules to my portfolio of applications. When I run in the public cloud I have no levers to optimize such performance. And actually it’s even more complex as public cloud performance is not constant.
Why is that the case?
Let’s assume I put a workload in the public cloud. Let’s assume it is number 2 in the picture. My application shares a CPU, memory and a local disk with three other applications belonging to other clients. I actually do not see those applications, for me they are nonexistent, but they influence the way my application runs as we all share the same component and use more or less of them. Bit that is not all. I also happen to share networking and persistent storage with applications located on other nearby servers. They will also influence my performance. So, if I test what performance level I have at different times of the day, I may end-up with a diagram as the one shown at the bottom right. So, my question is really, knowing my performance varies, what configuration I need to choose to ensure I always have an appropriate customer experience without spending too much money.
Can you really demonstrate what you say?
I understand you might be dubious about what I just described, but I can prove it to you. One of our partners, a company called Krystallize, has the CloudQoS technology measuring precisely this. Every month they release the CloudQoS® CPI index. They run the same application multiple times using several T-shirt sizes in different datacenters on AWS, Azure, Softlayer and Google.
Here are some of the results for June 2017. The tests shown cover both Linux and Windows. In the graph on the left you see the variability of the service, the middle graph shows the price and the right one covers a calculated price/performance.
In this example, Amazon has the best results but also the largest spread. So, you’ll have to ask yourself if it’s OK for your application to have such spread. When making a choice, do you need to look at the lowest value or at the average? Frankly, that really depends on the application and how it has been written. Can it coop with temporary lower performance? Now, this is great, but it is for a standard application, could this be done for one of your apps?
I want my results
The answer is yes. But it requires some work. First we need to understand the behavior of your application. This requires the application to be monitored for a period of time. A small agent is put on the server where your application is running. That agent will monitor the CPU, memory, disk and network requirements of your application and each of its components. The monitoring will take between 3 and 30 days, depending how the application is utilized. Once done, the data is transferred for analysis. The result serve to develop and configure a “synthetic application”, in other words, a mock-up of your application. Although it does not do the same thing, it consumes the same resources as your original application. That synthetic application can now be tested in multiple configurations of the target cloud(s) you have chosen and similar graphs can be developed. If for example one of the components of your application has a heavy database utilization, you can experiment with multiple storage options to find the most cost-effective one. Because indeed, as the synthetic application runs like yours, similar costs will be encountered to run it. This resolves the point I made in my last podcast, it will not only show you the performance you can expect, but also give you a good assumption of the cost you will pay.
Here is an example. A Hadoop workload is currently running in a private cloud and yearly costs around 500K$ to run. Can it be moved satisfactorily to the public cloud, providing roughly the same performance and be cheaper. The client decided the target cloud was AWS, so multiple AWS configurations have been choosen. You see the result in the table. Some configurations did not provide adequate performance and have been discarded. Ultimately, the use of an M2 server with EBS optimized storage provides twice the current performance at a fourth of the cost. This is the choice made by the client.
Once you have the synthetic application, you can re-run tests on a regular basis continue optimize your performance when the cloud providers introduce new offerings. Obviously if you choose Azure the first time and you decided to use Azure PaaS functionality, your future options are limited to Azure. But that is a decision you take. When Microsoft changes its pricing sheet, when they introduce new services, you can still decide to change what you use, and in doing so optimize your utilization of Azure.
So, yes, in public cloud you get what you get, but you have the opportunity to regularly review and optimize what you use. By testing options you have a powerful way to identify what makes sense for you, and that is what we are trying to offer, a smart way to decide.