Amazon cloud threatens entire IT ecosystem – report The moneymen have finally looked up from beneath their golden canopies and noticed, hovering above them, a cloud named Amazon that is putting traditional IT companies in the shade. Amazon's cloud poses a major threat to most of the traditional IT ecosystem, a team of 25 Morgan Stanley analysts write in a report, Amazon Web …
Pay for what you use in many cases does not apply in Amazon:
- EC2
- EBS
- RDS
- Perhaps others I can't think of as I try to forget my 2 years of history on amazon.
Amazon services above, like most other cloud players are pay for what you PROVISION.
This is far far different than pay for what you use.
Fixed instance sizes compound the problem even further.
Amazon does have some services that are pay for what you use, S3 is one example, I think probably the dynamo db and stuff mentioned are probably others.
I hope el reg reads this and understands it as I have said it time and time again. This
information needs to be understood.
I remember a conference call with amazon tech about a year ago with regards to pitiful RDS performance on a ~20GB mysql database. Their suggestion was to increase the DB provisioned size to 400GB so it is striped over more resources. Again pay for provision not for what you use.
I could go on and on again, but I won't. Drives me mad the marketing that is behind this cloud bullshit.
I agree on how stupid the marketing is about 'the cloud' but as far as use vs provisioning, aren't you laying claim to those provisioned resources whether or not you choose to utilize them? Doesn't Amazon have to assume those resources might be utilized and had to upgrade to ensure QOS? Just curious & trying to understand.
Yes. That's why a resource may be "reserved". If I "reserve" the CPU, I expect it to be available when I need it (although when I don't need it, it may be opportunistically be used by something else), but if I want to pay "by use" it may not be actually there when I need it.
Seriously, what's the problem with people nowadays?
This post has been deleted by its author
[revised my comment a bit]
You can say you are laying claim - as in I expect to have those resources available to me at any given time.
The critical failing is the assumption that the resources will be in use (on a larger scale) for long periods of time (certainly some applications work this way and in that case Amazon may be fine).
In a typical VMware infrastructure (or Hyper-V or anything hosted locally) you have say 100 VMs, and X amount of CPU resources. The assumption is made that the VMs can use X amount of CPU or I/O but they won't all request it simultaneously.
Thus you can significantly "oversubscribe" or over provision the system with that in mind.
Amazon lacks the technology in their hypervisors to be able to do this properly. One key aspect in allowing this capability in an environment where workloads are not predictable is the ability to migrate workloads between physical servers to re-balance the environment. VMware does this of course with DRS, other hypervisors have similar(though perhaps less sophisticated) capabilities.
Though if your workloads are predictable, as mine are (and have been for many years across multiple companies and dozens of applications) you don't even need something like DRS (though it's nice to have). I look at my VMware servers today and the *physical hardware* sits at under 20% CPU utilization(peaks to maybe 45%). That is with a dozen or two dozen VMs/server (and north of 150 gigabytes of memory/server). The only vMotions in my environment in the past 6 months have been manual load balancing (memory utilization hovering around 85%)
But even if you throw all of that out .. Amazon's VM infrastructure does not handle competing workloads effectively(maybe this is significantly changed in the past year but I doubt it). On Linux at least (other OSs may have similar properties) there is a CPU metric called "% Steal". Which basically means the % of CPU resources the underlying hypervisor has stolen from the VM. On Amazon under many circumstances involving high CPU load I have seen this number spike to as high as *30%*. which means your paying for your CPU but your only able to get 70% of the effective capacity out of it(at that point in time).
Since we moved out of amazon, the % Steal CPU time has been 0 - never once has it gone above 0 since we moved out. Well one exception might be last year with the leap second linux kernel bug which caused every VM in my infrastructure to jump to 100% CPU simultaneously (fortunately things held together fine).
Memory utilization is different though -- at least least for production workloads. Applications whether they are active or idle generally have a fairly stable memory usage profile. Hence the bottleneck on most VM infrastructures is memory rather than CPU or disk I/O. Non production workloads some people may lean towards allowing VMs to swap more to free up memory -- for me I don't like swap in any environment unless is for emergencies. I'd rather have a VM die because it runs out of memory then swap till the cows come home because swapping will not only essentially render the VM useless by slowing it to a grinding halt but may impact several other VMs in the process. -- from what I have seen Amazon VMs by default come with 0 swap configured (likely for the same reason).
When operating a public cloud you may not be able to make that sort of assumption as to the resource utilizations of individual servers. So in that circumstance you either need something like DRS, or you need the ability to be able to give the customer perhaps physical servers(not directly, but give them essentially dedicated hardware to provision what they wish within that hardware) and allow them to manage the work load distribution between them.
You can also control things in VMware (perhaps other hypervisors as well but not Amazon) with resource pools, limiting aggregate CPU/memory utilization for a particular group of systems. In my environment for example which runs a dozen test environments along side production (test envs run in different subnets of course), production gets priority. So if something like that leap second bug comes back the test environments may go nuts but they are only allowed X % of CPU time (I think in my case maybe 30% of cluster capacity). So production can keep going (during that incident our web site slowed down but did not go offline - other larger sites had significant downtime).
Moving out of Amazon has an ROI of less than 1 year in all of the analysis I have done at my companies, actual cost savings easily half a million to several million in the first year alone.
Hope this helps.
I am happy to talk more about it ...if you have further questions I have a blog where I have covered many of these topics in the past but I don't link to it here since el reg doesn't like that.
You can reach me via email at nate (@t) nateamsden (d0t) com if you have further questions and/or wish the link to my site.
as far as use vs provisioning, aren't you laying claim to those provisioned resources whether or not you choose to utilize them? Doesn't Amazon have to assume those resources might be utilized and had to upgrade to ensure QOS?
Not necessarily, if the supplier (Amazon, in this case) can still meet QOS guarantees while oversubscribing. For example, their QOS guarantees (or some of their QOS guarantees, if they offer tiered contracts) might not be absolute - you will have these resources - but merely a penalty: if X% of resources aren't available when you ask for them, you get a partial refund. Then they can happily oversubscribe, knowing that the probability of a QOS default is low, and has a predictable cost even if it happens.
Or they can oversubscribe by borrowing capacity to run non-guaranteed loads, including their own elastic loads. So, for example, they might let their customers provision all of a block of capacity, but when those customers aren't using all of it (which will almost always be the case), they could run lower-priority jobs like the recommendation system on the idle systems. So that provisioned capacity isn't "reserved" - they can extract value from it on top of what they charge the customer who provisioned it.
In other words, there are three factors at work here: it's very unlikely all the provisioned capacity will ever be in use; the cost of not delivering some provisioned resource might be less than the return on oversubscribing; and it may be possible to opportunistically oversubscribe without running the risk of not being able to meet obligations.
Oh, and of course there's always the fourth possibility, which is oversubscribe and if you run out of capacity, rent some from another supplier. That's unlikely in Amazon's case but can work very well for smaller providers.
U r very right .. Sadly the market will only realize the gravity of the situation and problems once they have to put up with pitiful performance from many of the cloud service providers and then many will want to instead have their own server or hardware but by then most vendors would've changed their lines of business or would've gone the way of the dinosaur ..
Today's mentality is cost over quality in most sectors and the real price will be paid in a few years time as it all starts to take its toll on quality ..
Bring it on and don't forget the popcorn.
I am currently renting a few servers at EC2 to run BOINC applications just for fun. At spot pricing (where your server may disappear at any moment) as opposed to "reserved instance" pricing, it costs me a tenner a day (plus VAT). I will throttle that soonish but this price level sure is interesting for some applications. The virtualized Xeons are not particularly oomphy though, time to rent some pricey GPUs?
Now if you want to have a "reserved" machine, the price level corresponds to what one would expect when renting a rack full of newly bought gear in a data centre, less the maintenance contracts and the screwdriver dude's wages. For example, a "heavy utilization quadruple extra large" instance on a 3 year contract costs $4792 upfront and 142$ per month. In case you want Windows with SQL Standard, you are looking at $12720 upfront and $696 per month....
This post has been deleted by its author
[accidentally retracted this one]
A common misconception on Amazon cloud is that you need less IT staff to manage it. For the most part, as an experienced IT professional you actually need more IT staff (or at least more IT knowledge than you otherwise would with traditional infrastructure). Primarily due to the built to fail model. Most developers don't think like that (having worked at two different companies who build apps from the ground up in EC2 and still didn't think that way I think is good experience - and other organizations as well I have worked with/for have tons of places where they have single points of failure and do not handle built to fail even remotely good enough), for good reason - the cost benefit is not there for the early stage stuff. It's really not until you get to "hyper scale" that moving core infrastructure failure modes higher up in the stack (biggest exception would be stateless web servers behind a load balancer that is simple enough to manage)
Now if your one of the few who has built their app to that model then good for you. For the vast, vast, vast majority of the rest of the world though they aren't there, and probably won't be there for some time to come. There is far better return on investment by investing in shiny things that the customer sees than fault tolerance under the hood -- at least that is the trend I have seen at every company I've been to for the past 15 years.
If they can do fault tolerance at the same time -- then great they sometimes do that, but if it is a significant inconvenience then they do not.
It's a rude awakening when for the first time you see your server has vanished and Amazon say no they won't repair it, your SOL. Restore from backup. Or they say Oh we must reboot your instance within the next week, you have no choice but to accept this downtime (maybe you can postpone it a day or two but you can't stop it from happening).
That's really not how most businesses are used to operating. Something breaks, and you(or someone) fix it. You don't toss it out and move on (unless it has melted or something).
One friend of mine told me a brief story about their amazon experience. Their developers honestly came to them and asked "Can't you just turn on the auto scaling feature?"(as if it was a switch) I won't explain that further if it doesn't make sense, and doesn't make you want to pound your head into the wall) . A CxO I can understand possibly saying that - but a developer?
El reg had a great article on the topic several years ago I like to point to
http://www.theregister.co.uk/2008/08/25/cloud_dziuba/
>Their developers honestly came to them and asked "Can't you just turn on the auto scaling feature?"(as if it was a switch) ... A CxO I can understand possibly saying that - but a developer?
No surprise to me. I've found over the years that many developers to be ignorant of the fact that the default single dev user/desktop install of a product they do to permit standalone dev and test doesn't always include the enterprise functionality and libraries that will be used when the product is deployed in operations, hence there is a high probability their code will break...
This knowledge/understanding has enabled me to very early in a project to ask the software dev team relevant questions so that they can avoid getting egg-on-the-face later on... [Aside: this doesn't mean that the dev's were/are wrong to install the dev product, only that they need to be aware of it's limitations and use their knowledge and skills to work accordingly.]
I've never seen a model costed out in Amazon(or other cloud players, since they are similar) vs traditional infrastructure where it costs less in the cloud at pretty much any level than it does to do it in house. It's always been woefully lopsided against the cloud (even giving the cloud every benefit of the doubt - if it worked PERFECTLY which of course it does not).
The one exception I can think of is for workloads that are very bursty, or perhaps very light workloads that need to be at geo-diverse data centers. Those are two excellent use cases for Amazon. Though the % of customers that have that kind of thing I believe are rounding errors in the grand scheme of things.
Other use cases for amazon perhaps are the services they provide that are purely pay for what you use. S3 is not a terrible service, it could be better but it is OK. I can't speak to the more developer centric services, some of them may be ok as well though there is the aspect of lock in.
I have seen, conversely people wanting to use Amazon because they buy into the hype, they don't care about the numbers they just want to be in the (that) cloud. I have seen(and heard) THAT on many occasions. Usually comes from folks that have absolutely no idea how far IT infrastructure has come in the past decade, and how the Amazon model really sets everything back to where we were in the 90s from a provisioning perspective(minus the APIs).
Amazon's hypervisor-agnostic, Xen-based infrastructure.
Oh it's agnostic, you just have to use Xen. ?
Perhaps you meant server agnostic.
And that's one tweaked version of Xen, have they been spanked by the Open Source crowd lately for being timely on their contributions back to the Xen tree ?
Or does no one care, and they've all moved to vSphere or KVM ?
Awsome.. we are an ISP and we've offloaded all but a couple of servers to AWS (and some with Linode).. these providers are the next evolution in IT... I for one think its now a full fledged revolution as it upends the status quo. AWS allows me to save on electricity, real estate (from a 30sqm data center to a couple of racks), server purchases, manpower and bandwidth. Allowing me to focus on the software side of our business instead of having to think and spend for hardware and stuff.
...make for interesting reading.
This, surely, is a situation where the market will decide - if AWS service is as cost-inefficient as Nate is claiming, then EMC and so on will be OK, but might be forced to adjust some of their business practices (pricing seems to the be the big one) in response.
If, however, it's as good as json is claiming, AWS will win - and it's interesting to note the other cost factors json alludes to that are missing from Nate's posts.
"If adoption is mostly among SMBs, on the other hand, Morgan Stanley says NetApp, VMware, Brocade, QLogic and EMC are most at risk."
From my experience many (smaller) SMB's without their own formal IT organisation, won't go near any cloud service provider, at least directly, because they don't have the experience or skills in-house and the budgets to maintain such skills. Hence they will use cloud via a third-party - who in the first instance is likely to be their PC support provider - who as we know are most likely to be MS biased. Whilst I'm not up to speed on the propositions MS are putting into the reseller channel, it would seem natural to assume that this channel would encourage the use of Azure rather than Amazon ...
For those slightly larger SMB's running CRM, ERP etc. I suspect that these will tend to go with niche 'local' (ie. same state/country) providers who specialise in supporting these applications.
A good use case for cloud, is for 'enhanced' remote access to services. Currently business ADSL is very cheap, change to remote working and you'll find it is no longer performing due to the increased traffic up the line to the Internet. Cost out a leased line and hosting the relevant services in the cloud can look very attractive.
"Why these companies in particular? NetApp and EMC depend on data existing onsite and living in expensive hardware with pricey management tools."
Traditionally, enterprises have processed and held data on-site with backups being held off-site. With cloud, particularly for those with existing datacentres, perhaps a new compute model is: processing off-site (ie. cloud) and backup held on-site. This enabling the company to retain a current copy of it's data independently of the cloud provider(s) and maybe also perform data mining and analytic tasks that either don't sit well in the cloud or are too costly.
Hence perhaps what we'll see are attempts by these companies to redefine the role for their products.
"data mining and analytic tasks that either don't sit well in the cloud or are too costly"
Uh - I seem to recall the keynote speaker at the AWS Summit in San Francisco describing how Bristol Myers-Squibb had reduced the time and cost of their analytics by something like 70%.
EMR and Redshift are just two ways you can leverage the AWS Cloud for exactly these types of use cases and do so really cheaply.
If you look at hte history of computing the architecture of choice is a (simple) function of the cost of use and utility of :- CPU, Storage, Bandwidth ( Bus, LAN, WAN) and a I/O, skill base plus the curved ball of applicable laws and taxes..
Mainframe - Mini- Micro - LAN mini - LAN Micrtos - Distributef WAN mini - Distributed WAN micro - Cloud...
Historically the price of moving the data has been the biggest factor. Putting all data into one place and just moving the I/O is currently best.
Note that if this is the case, then the BIG DATA farms where everyone can access the "global data flows" will win.
I.e. Google will win as they collect the most
Amazon's only defence is to put in a DATA sharing collective into their model. Though Google doesn't have the "privicy" problem as they "own" most of the data in their cloud, so don't fall foul of privicy laws
BTW. This doesn't just apply to computing, physical sales have followed the same function. with corner shops - super markets- hypermarkets- On-line - off-shore...
Exercise, do the line for virtual sales such as games and predict the future for yourself!
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
