Is this even controversial?
Pay-as-you-go/subscription is a ripoff. Surely everyone knows that.
But what choice is there in the long run?
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 …
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.
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:
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
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.
'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.
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.
Opinion Broadcom has yet to close the deal on taking over VMware, but the industry is already awash with speculation and analysis as to how the event could impact the cloud giant's product availability and pricing.
If Broadcom's track record and stated strategy tell us anything, we could soon see VMware refocus its efforts on its top 600 customers and raise prices, and leave thousands more searching for an alternative.
The jury is still out as to whether Broadcom will repeat the past or take a different approach. But, when it comes to VMware's ESXi hypervisor, customer concern is valid. There aren't many vendor options that can take on VMware in this arena, Forrester analyst Naveen Chhabra, tells The Register.
Broadcom has made its first public comment in weeks about its plans for VMware, should the surprise $61 billion acquisition proceed as planned, and has prioritized retaining VMware's engineers to preserve the virtualization giant's innovation capabilities.
The outline of Broadcom's plans appeared in a Wednesday blog post by Broadcom Software president Tom Krause.
VMware today revealed details about Project Arctic, the vSphere-as-a-service offering it teased in late 2021, though it won't discuss pricing for another month.
VMware's thinking starts with the fact that organizations are likely to run multiple instances of its vSphere and VSAN products, often in multiple locations. Managing them all centrally is not easy.
Enter vSphere+ and VSAN+, which run in the cloud and can control multiple on-premises instances of vSphere or VSAN. To make that possible, users will need to adopt the Cloud Gateway, which connects vSphere instances to a Cloud Console.
Updated Hitachi has taken a modest step towards becoming a public cloud provider, with the launch of a VMware-powered cloud in Japan that The Register understands may not be its only such venture.
The Japanese giant has styled the service a "sovereign cloud" – a term that VMware introduced to distinguish some of its 4,000-plus partners that operate small clouds and can attest to their operations being subject to privacy laws and governance structures within the nation in which they operate.
Public cloud heavyweights AWS, Azure, Google, Oracle, IBM, and Alibaba also offer VMware-powered clouds, at hyperscale. But some organizations worry that their US or Chinese roots make them vulnerable to laws that might allow Washington or Beijing to exercise extraterritorial oversight.
Microsoft is flagging up a security hole in its Service Fabric technology when using containerized Linux workloads, and urged customers to upgrade their clusters to the most recent release.
The flaw is tracked as CVE-2022-30137, an elevation-of-privilege vulnerability in Microsoft's Service Fabric. An attacker would need read/write access to the cluster as well as the ability to execute code within a Linux container granted access to the Service Fabric runtime in order to wreak havoc.
Through a compromised container, for instance, a miscreant could gain control of the resource's host Service Fabric node and potentially the entire cluster.
OpenInfra Berlin OpenInfra still has ideas to share, including an intriguing funding model for open source projects the Foundation discussed at its in-person event last week in Berlin.
The "Directed Funding" initiative – a significant change to how some projects might be funded in the future – is about allowing organizations to fund a specific project rather than seeing their cash spread across projects for which they have no interest.
Jonathan Bryce, CEO and executive director of the OpenInfra Foundation, told The Register this wasn't a case of following a trend in the open-source world that he described as "this kind of pay to play-type scenario."
Analyst firms S&P Global Market Intelligence and Gartner have both offered negative evaluations of Broadcom's takeover of VMware.
S&P surveyed VMware customers and found 44 percent feel neutral about the deal, and 40 percent expressed negative sentiments.
But when the analyst crunched the numbers for current customers of both VMware and Broadcom, 56 percent expressed negative sentiments. More than a quarter rated their response to the deal as "extremely negative".
Chinese web giant Tencent has revealed it’s completed a massive migration of its own apps to its own cloud.
The company started thinking about this in 2018 after realising that its many services had each built their own technology silos.
Plenty of those services – among them WeChat, social network, qq.com, games like Honour of Kings and YouTube-like Tencent Video – have tens or hundreds of millions of users. Each service appears to have built infrastructure to cope with peak traffic requirements, leaving plenty of unused capacity across Tencent’s operations.
Days after the debut of doodle-recognizing Express Design on the Power Apps platform, Microsoft has updated its Azure sibling: Form Recognizer.
Azure Form Recognizer, as its name suggests, pulls text and structure from documents using AI and OCR. The theory goes that users can automate data processing with the tech, which accepts PDFs, scanned images and handwritten forms (although, as with all handwriting recognition systems, scrawl barely readable by humans can equally stump the robots.)
Broadcom's stated strategy is very simple: focus on 600 customers who will struggle to change suppliers, reap vastly lower sales and marketing costs by focusing on that small pool, and trim R&D by not thinking about the needs of other customers – who can be let go if necessary without much harm to the bottom line.
The Register offers that summary based on Broadcom's own words, as uttered at a November 2021 Investor Day.
The Broadcom event kicked off with an overview from president Tom Krause, who illustrated the outfit's go-to-market plan with the following diagram.
Biting the hand that feeds IT © 1998–2022