Data Expedition, Inc.
News
Articles, events, announcements, and blogs
Data Expedition, Inc.
News
Articles, events, announcements, and blogs
It is commonly understood that when dealing with a new or unfamiliar technology, you have to test before you deploy. But a key difference between cloud and traditional infrastructure is its variability. What you see in one test at one time may be radically different a few minutes later or after a seemingly trivial settings change. Planning a successful cloud deployment requires much more rigorous testing and an awareness of how cloud behavior can change when you scale up to production level workflows.
The most important thing to remember about cloud infrastructure is that all resources may be shared. This means that the results of any tests are going to depend as much on what other people are doing as they do on your own actions. Every aspect of CPU, storage, network performance, and resource provisioning times, may change from moment to moment. The infrastructure itself may also change over time, as new features and processes are implemented behind the scenes.
Sometimes, you can reduce the effects of other people's actions by paying for a larger share. Using a larger instance size will get you not just better performance but more steady performance as you claim more of the underlying hardware for yourself. However, this comes at a high cost. For example, an AWS EC2 c4.xlarge instance might give you 800 megabits per second every once in a while, and if you only test once you might think you can get away with paying just $0.199 per hour. But to get that level of performance every hour of every day, you will likely need to pay four times that for a c4.4xlarge. See this table for more EC2 performance estimates. The same principal applies to virtual machines from all vendors.
Not all variability can be controlled by paying more money. For example, S3 performance can hinge on how you name your objects or how often they are accessed, two factors which can easily change between testing and production. Just like in an on premise environment, you also have to look for common bottlenecks like centralized resources (Active Directory, DNS, etc). But in a cloud environment, such bottlenecks can be exacerbated by high latency and shifting bandwidth. Running across multiple regions and multi-tenant access permissions are other examples where what works in an isolated test may choke at scale.
When you can't control for all the variables in a test, the only thing you can do is test more. Whatever workflow you are trying out, make sure to test it at full scale across a long time period. When testing costs you by the hour, it can be tempting to take shortcuts. When a project is speculative and you've only been tasked with a quick proof-of-concept, it can be very tempting to assume that someone will conduct a more thorough review before full development begins.
All too often I've come across tests and proof-of-concepts that got written in stone and became the foundation for a design whose flaws then had to be fixed at the last minute or, worse, while customers were waiting. Always test like you're about to go into production before you make any assumptions about resources, timelines, or dollars.
To help you with that testing, we provide both public and extended free trials along with pre-sales technical support. If you need more time than our AWS Marketplace 7-day CloudDat trial or 5-day ExpeDat trial, then contact us for 21-day or longer trials.