Running applications in the public cloud comes with a lot of benefits: significantly improved business agility, time savings, reduced management and maintenance of hardware/software, easier scaling and bursting, and more. One area where public cloud hasn’t always panned out is cost savings, but is that because public cloud is more expensive or is it something else?
Public cloud is priced such that it can be more affordable than on-premises data centers, even if you don’t include operating expenses (OpEx) in those calculations. The best way to realize these cost savings in the cloud, though, is through proper planning. This gives IT an accurate way to validate that their public cloud project budget will help cut IT costs, and help ensure the organization meets the goals set.
Quite often, though, this planning was prohibitively time consuming or complicated due to the need for extensive testing. This means that IT can’t perform the kind of live testing that would help ensure an ideal environment for both application performance and budget in the cloud. To help guide IT through their public cloud validation planning and testing, we’ve put together some testing tips that have helped successfully guide other organizations on their journey:
- Make sure you test a real clone of your app with its data. Ideally you want a copy that is near-identical to what you run in production so that you can be sure that your testing results are accurate. If you are running apps or workloads that are only ‘similar’ (by using a different version of the app, by using non-production data, by relying on testers instead of actual end users performing their day-to-day, etc.), then there is a chance your testing results won’t reflect what you need. Those differences can end up leading to over-provisioning (which is expensive) or under-provisioning (which impacts end users).
- Tests must be done quickly, even for stateful workloads. You need to get those apps in the cloud and ready to be tested in minutes—not days or weeks—so that there aren’t huge time delays throughout your testing cycle. Being able to seamlessly start testing in the cloud almost immediately helps prevent wasted IT cycles on setup time and wait time.
- Find the right instance sizes. Don’t be tempted to size cloud instances the exact same way as on-premises. VMware, for example, bills based on total physical CPUs, which means over-provisioning VMs doesn’t cost you any more or any less. In the cloud, however, over-provisioning will cost more because you pay per hour (or minute) for a certain instance type. As such, an instance with 16 CPUs will cost you more than an instance with 4 CPUs, regardless of what your CPU utilization is. That is why you should use a load generator to see how performance is with varying loads (to simulate different times of day, for example). With these results, you can shift the instance size up or down which helps make sure you aren’t over paying for unused computing resources in the cloud.
- Test other cloud regions. This is especially important if you have pockets of remote users in other areas of the world. This will help IT weigh the performance of each region against its cost. For example, even when there is a region that is closer (but more expensive), performance for end users might still be perfectly acceptable from a region that is a bit further away but less expensive.
- Finally, test other cloud platforms, Many IT departments lock themselves into one public cloud provider, even though most have unique benefits based on certain use cases. For this reason, it is often beneficial to run some apps in one public cloud, but other apps in another public cloud. When you evaluate other cloud options, you should consider their pricing schemes, billing periods, discounts, and performance as part of your rubric.
Performing these five groups of tests thoroughly gives IT the insight they need to get their apps into the public cloud with an optimal price/performance balance, and with an architecture which will ultimately reduce overall cloud costs.
The hurdle here is often time, as many public cloud platforms do not provide native functionality to easily perform all of these testing groups easily. This often meant IT had to setup instances manually across sizes, regions, and/or providers- all of which meant testing took up way too much time (and/or money). Testing ended up reduced, which meant cloud decisions may not have been ideal for performance or cost.
The key to thorough testing rests on having a platform that lets you quickly clone a production workload into the public cloud, using different instance sizes, within different regions and across different public cloud providers. When IT can quickly generate working, testable apps across this kind of variety (including the option to keep production data completely synchronized during the testing), it allows IT to do the necessary testing to optimize cloud cost and performance.
With Velostrata, in just a few minutes, we can get an exact replica of your app up and running in Amazon AWS or Microsoft Azure so you can really test performance and cost. For more information on how we can power your public or hybrid cloud journey, check out our 3-minute video or drop us a line at email@example.com.