What's this 'pay as you go' cloud crap? Dunno about you, but my apps don't work that way Anyone who says public cloud computing is "pay for what you use" is trying to rip you off. The public cloud is pay for what you provision, and that is a completely different thing. In order to move away from the model that pretty much every existing application uses – one where you provision the peak amount of resources …
@Vociferous
I wouldn't call the concept a ripoff as a flat statement. Certainly many PAYG services work out to be more expensive but simply being more expensive doesn't mean it's a ripoff.
Many, many companies prefer the ability to deploy stuff without the huge upfront costs. For some companies, PAYG can mean the difference between updating all your staff (say to the new version of Office) in one hit and upgrading in a tick-tock fashion. I know plenty of clients who have done this in the past, with the result being that they have Vista, 7 and 8 PCs running Office 2007, 2010 and 2013. It all works but they would certainly prefer standardisation.
Of course, that's just one, specific, scenario but my point is that the concept itself is not, ipso facto, a ripoff. For one thing, it can free up capital, which for some businesses can be far more important than TCO.
This can be especially true of new businesses who need a full IT environment but have far better ways to spend those piles of cash than servers and licenses. If they couldn't use a PAYG system then they may simply not have the money to deploy the same features in house and thus may end up with a system that doesn't meet their needs as well.
From the other direction, utilising PAYG services may enable a (generally small) company to benefit from functionality that they could not deploy themselves and this may result in greater efficiency or profitability.
Yes, PAYG/subscription is usually more expensive in the long (or even medium) term but this fact does not automatically make all such services 'ripoffs'.
If you see my history of comments I am not fan of "because cloud" (perfectly stated, Trevor) but I am a fan of deploying the best solution for a given client and a solution you can afford to deploy pretty much always beats a solution you cannot afford to deploy.
@dan
I agree and then there is the short-term part of the equation. If I have a short term project and need extra licences etc. for a few weeks or a few months, I don't need to layout a huge wad of capital for licences that will "sit in a draw" after a couple of months.
As an example, the Adobe CC subscription, if I need 5 licences for 3 months, that is around 922€, as opposed to around 10,000€ - 15,000€ for CS6 licences. I can get around 50 months CC for the price we paid for our CS6 Master Suite licence. For companies that only need it on an ad-hoc basis, that means substatial savings.
The same is true for cloud servers and services in general. If they can be spun up and down on an ad-hoc basis and you only pay for what you use, it works out a lot cheaper than buying licences and hardware for a local server.
On the other hand, the equation becomes a less clear for services that need to run 24/7.
I sitll don't understand why company often don't externalize non core tasks like accounting, HR management, marketing, etc. etc. but they want to externalize what really became core like IT because *all of your important assets are often now stored and managed electronically, and production is managed bu it as well*.
IT is now the nervous system of any company. Yet you have to get rid of its personnel internally as much as you can. I understand marketing guys and gals are usually nicer than IT ones... but I would think twice before putting all my true assets elsewhere...
You presume a lot when you say that IT personnel - rather than the systems they maintain - are the true assets of a company. In some cases, yes, they are. In others, they're a liability. In still other cases one good accountant might be worth an entire IT department,
Company morale and unit cohesion are important. To put it bluntly, many - if not most - IT folks have trouble with that. It's been that way for ages. The difference is now you can replace them not with some folks with bad accents...but with subscription services provided with SLAs and guarantees.
That's pretty attractive to a lot of people.
The IT systems are nothing without the personnel who manage them.
I've done both internal and external support. There is no way a part time external support team will ever know your business as well as a full time internal support team will. Even with a full time external support team, I seriously doubt it is more profitable for the company to pay someone else to run their support. You may find individual applications where you can't match an outside vendor's cost (GMail for instance), but I'd bet there are things it just doesn't do well (GMail for instance).
If you've got a morale problem in IT, it probably has something to do with the way you treat your IT team and not the other way around.
with a straight face you can reccomend someone develop something on top of amazon while at the same time saying "pay for what you provision" is bad. Amazon practically created that whole thing, and it's been a disaster from the start. Their model is so incredibly broken it's sickening. There are some services they offer that are pay for what you use (S3 and a few others that I can't name off the top of my head). But their EC2/RDS/etc type services are all not only functionally terrible, but the pay for provision model is just bad bad bad.
I can't speak to google/azure services I have never used them.
There was a video presentation I saw of a guy at a conference a few months ago:
http://vimeo.com/95066828
He talked about all sorts of concepts whether it was cloud, nosql, security etc. On the clould front he said there were two types of people:
1) people that have actually implemented cloud services
and
2) other
It is quite funny and he manages to nail so many good points while keeping the audience entertained, it's hard to get me to laugh out loud but he did it on all of the times I have re-watched that video.
Well, it's pretty simple, Nate. Built from scratch I can idle some base items - usually automation trigger systems with some message queueing and a basic copy of whatever app I am presenting, as well as the "core" DB instance - and burst as I need. So long as the periods of lowest demand cover the cost of idling those base VMs, and the revenue scales with cost of bursting, I make money. Simple economics.
From an architectural standpoint, I can design more efficient on premises. So can you. We can both design better systems on Azure or on Openstack. I can't speak to Google Compute, as I haven't played with it much yet.
But here's the ticket: if I design something from scratch for anything but Amazon then I don't have this massive ecosystem of applets, services, devices and so forth already built for me. Designing something from scratch for Amazon is basically like putting together some lego. Development is cheap and easy and you don't have to worry much about the infrastructure.
You do have to actually care about backups and so forth, but you don't have to pay as many pesky, needy, human nerds. You order a service, you get results...and there are entire empires being built on the tools and technologies to ensure you can walk away from Big Daddy Amazon whenever you want.
If you want ideological purity, or some statistical perfection of design, efficiency, or performance per $, Amazon isn't it. What Amazon is, sir, is a "fire and forget" missile for infrastructure. Some people - most people - in business don't want to deal with infrastructure. They don't want to pay nerds, listen to nerds, have meetings with nerds, worry about the morale and psychological health of nerds...they want - insomuch as it is possible - to have a company that makes as much money as is practicable with the fewest people involved as possible.
That is what Amazon is about.
Need a backup service? There are dozens to take you Amazon workloads and send them elsewhere. Need auditing? Monitoring? Optimization? $deity knows what else? You can order that easier than a pizza.
Amazon is a horrible, horrible thing filled with inefficiency and badness for anyone who gives a bent damn about technology, how it works and how best to implement it. But it's a wonderful thing if your goal in life is running a business with the lowest possible amount of stress and grief.
You pays your bills and you makes your choices...and I suspect that lots of people are willing to pay over the odds to Amazon in order to get one step closer to a nerd-free nirvana. How much is it? 5% more than running and staffing your own teams? 10%? 25%? Where's the cutoff where most won't pay the price?
I think, Mr Amsden, you'd be quite shocked how high that number can be and still get billions of dollars a year worth of people more than willing to pay the price.
I did not recommend anyone move "idle-heavy" workloads to Amazon. I said I'd build new workloads there. Ones that burst. That are designed from the ground up to lower that "% more than running and staffing your own teams" to the lowest number possible.
And I absolutely do recommend you build new workloads on public clouds. I'll tell you why:
When a cloud service is properly designed, if your public cloud provider goes down, that's their fault, their insurance provider pays. All you need is a backup that mirrors to another public cloud provider, and those are cheap. You get compensated for the downtime - which should amount to the amount of time you were "lit up" on the other provider - and all is well.
You don't have to worry about retaining talent. You don't have to worry about hiring talent. You don't have to worry about insider threats, sabotage, grumpy people, raises, any of it. You consume a service and some other schmuck copes with the politics. If they suck at that service, you get a nearly identical service elsewhere.
Liability. Risk management. They become technical exercises in the public cloud, not human exercises. Your risks are technical. Then can be solved with technology. When you hire staff to run your own stuff, those risks are far more complex, involved...and costly to insure against.
That's my logic, sir. And so far as I can tell, the numbers only work in instances wher eyou design from the ground up. Try to run traditional "idle-heavy" workloads on Amazon, and it becomes cheaper to run and staff your own infrastructure.
That's the cutting line, and maybe - just maybe - that will shift soon too.
@Trevor _Pott
'I did not recommend anyone move "idle-heavy" workloads to Amazon. I said I'd build new workloads there. Ones that burst. That are designed from the ground up to lower that "% more than running and staffing your own teams" to the lowest number possible.'
Not only that but building burstable applications may well open up additional functionality or opportunities.
I remember reading about a company that decided to do an ad for the Super Bowl (or something like that) and what they did was re-engineer their website so that it could run using the scalability of a CDN. Thus, when the website traffic increased by several orders of magnitude, that investment paid off as the site was able to handle all the extra traffic.
It wasn't about lowering cost so much as opening up new opportunities for increasing revenue.
We didn't replace mainframes with what we now call "standard" or "legacy" x86 applications. We won't be replacing standard x86 applications with public cloud computing.
Public cloud computing is an and technology. Not an or. But it is as significant an "and" as x86 was to mainframes. Very soon now, most new development will be on public clouds. But 40 years from now, we'll still be dragging these x86 applications along, too. Because we jsut have too much invested in them to throw them away.
That's business. And it has little to do with technology, no matter how much technology it uses to accomplish it's goals.
"The amount of money required to ditch applications, recode them, and then retrain all our staff is prohibitive." - which is exactly how the whole IT industry operates - continual introduction of new releases whose failure to maintain backwards compatibility triggers a chain reaction of additional updates of other products shoes failure to maintain backwards compatibility triggers a chain reaction ...
Not to mention impacts on productivity and training.
@AC
I love backwards compatibility. But there is a dark side.
Backwards compatibility means extra code, in the form of legacy and/or new code. The more code there is, the more potential bugs and security holes there are. You may also find that the requirements for maintaining backwards compatibility means that some new features may be more difficult to implement and thus are delayed or dropped.
Interesting article. And I actually agree with many of your points, i.e., your comments on the mainframe, and the rising use of OpenStack as a viable option. But I find it interesting that articles like this are like prognosticating the long term affects of global warming on our planet. They're anecdotal at best, and at worst they serve only to unnecessarily panic the masses. PAY/G cloud (or any cloud based offering whether private, public, hybrid, etc.) are like any new technology (some would call it IT services philosophy) with the potential for producing a major paradigm shift. It has it's pluses and minuses compared to traditional application hosting paradigms. And as with any new technology that's introduced (like x86, optical, SSD, etc.), it sees an initially high price per unit, which tends to shrink with time, end-user experience, and market demands. No one in their right mind is recommending a "rip and replace" (or "rip and move") approach when it comes to cloud. At least no one in the circles I deal with. And that goes for OpenStack in particular. But then again, I work for one of those "large corporations" you mention that has a very practical view of application hosting, and also owns the mainframe you so aptly espouse. In fact, we take the approach that "fit-for-purpose" (F4P) is just as important (if not more?) than cost per unit of computing. Some apps work just fine on x86. Some on Unix. Some on the Mainframe. And some, (as you point out) are great candidates for cloud (hybrid, private, or public). But I don't believe OUR EXPERTS are telling anyone to replace their entire application portfolio with cloud.
1) Paragraphs, for the love of $deity, paragraphs.
2) There are tens of thousands of "experts" telling companies to move "everything" into the cloud. Youer personal experts may or may not be telling people to do that, but Amazon, Microsoft and hundreds of startups absolutely are.
3) Prices may come down. Services don't obey moore's law.
4) I am reporting the cumulative opinions and experience of well over 2000 people I've talked to about this subject in the past two years.
5) You are attempting to counter what you perceive to be anecdotal experience by holding up your own anecdotal experience to be superior.
> Anyone who says public cloud computing is "pay for what you use"
> is trying to rip you off. The public cloud is pay for what you provision,
> and that is a completely different thing.
Amazon S3. Bandwidth and storage charges really are "pay for what you use". There is nothing to "provision".
This covers most of what I do (certainly most when measured in $) and I don't think what I do is very unusual.
Is what you do running a traditional x86 workload that needs to remain idle 24/7, even when not in use? Then you have provisioned that for 24/7, even though you may only use.
Or have you - as the article suggested - rewritten everything from the ground up to be a burstable application. In that case you pay a very small base idle fee and burst up as you need it.
If you have a traditional application you are paying for what you provision, not what you use. If you have a burstable app, then when you do is abnormal; it represents a tiny fraction of deployed applications in the world today.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2023
