Shrinkage!? But it's sooo big! More data won't leave storage biz proud Analysis The enterprise storage market is in a period of data growth according to IDC-forcasted zettabyte heaven, right? Er, no, because it's it entered a recessionary period, with negative growth. Says IDC. Total factory revenue of $8.8bn was reported for the quarter, down 3.2 per cent down on the year while the number of …
Perennially overpriced market run by the most change-resistant people in tech to encounter price war after decade of innovation starts to penetrate FUD and have an impact on customer buying descisions.
Shocked, I tell you. Truly shocked.
Oh, and the solution to all of this, of course, will be NVMe over fabrics! Trust us! NVMe over fabrics will solve everything! Because the answer customers have been waiting for to burdensomely expensive, proprietary storage that's difficult to manage is urdensomely expensive, proprietary storage that's difficult to manage that goes really fast.
Because in a market where up top 60% of respondents reply that they haven't deployed hybrid or all flash arrays clearly speed is the thing that's going to save everyone. Not lower prices. Or ease of use. Or open standards. More speed.
Yeah, those legacy, change resistant vendors will right the ship with NVMe over fabrics all right. Just you wait. Massive return to growth! Tremendous! The biggest growth, believe them!
...any day now...
There are a LOT of analysts pushing it. I really haven't seen many vendors succeeding with it yet, but they've got at lot of the expensive analysts convinced it's the next big thing.
I just look at how long it's been since the analysts in question actually worked at the coalface, snort and go back to getting work done.
Take cloud, is anyone there using SAN? even HCI/vSAN note really used
in the modern stack storage collapse into the data services (object, database, streaming, ..), connect directly using DAS, and backed up into object. so the overall SAN/NAS/HCI storage pie is shrinking, within it you may see one eating the other e.g. HCI or NVMEoF steeling from arrays.
why build a box with CPUs that all its use in life is to take blocks from the wire and organize on disk if it can do something more useful like process a protocol, search, index, etc. and instead of trying to figure out caching or compression at 4KB granularity it can do it once at the application, also guess what no need for 3 layers of journaling that kills perf. storage is not a service, rather infrastructure that serve a service/app, and now those new services/apps are consolidating with the disks/flash, no more room for blocks over a wire regardless if you call it SAN/HCI/NVMEoF.
Yaron
Oh, look, one of those people who ignore the part where the world isn't going to rewrite 40 years worth of applications in order to fit some pee-in-jars nerd's efficiency fetish, but they still want high availability.
Yeah, sorry (not sorry), shared storage is here to stay. And no, JBOD doesn't count.
Take your containers, and your cloud native, and your rewriting the whole goddamned world and crawl back into the tiny niche where money has no meaning from when you spawned.
Oh, right another one of those IT guys that thinks Cloud would just go away, and we can keep messing with FC SANs..
IT shops are migrating to cloud, u can put your head in the sand as much as you want, and Cloud doesnt have SAN. For guys like you they invented "migration services" to Seamlessly move your Oracle or VMware. guess what, those tools you are so fond of like Exchange, MS Sql, .. In Azure don't run on any SAN or HCI, and guess what they have the same or better HA, Global DR, and consist snapshots don't require any coordination w storage
Some just have hard time accepting the IT world would never be the same. The writing and financial report are already on the wall.
Yes, like Mainframes legacy won't just go away, it will stay for ever, but not sure you can grow a company based on it.
Yaron
"Oh, right another one of those IT guys that thinks Cloud would just go away,"
Actually, I think public cloud offerings will be around for quite some time as one amongst many options for use. The public cloud will not completely displace internal IT, except in niche circumstances.
" and we can keep messing with FC SANs.."
Fuck fiber channel. Companies don't make money resizing LUNs.
"IT shops are migrating to cloud,"
IT shops are adopting public cloud services (mostly SaaS) tactically. Point solutions for specific problems, which almost never includes IaaS. And the movement from the public cloud was almost as big as the movement to the public cloud in 2016. Companies are realizing just how many workloads are terrible fits for the cloud and bringing those back in house. A balance is being discovered where some workloads are best in the public cloud and some never will be.
You know, like every other "this will change everything forever" revolution in IT.
"and Cloud doesnt have SAN."
Yes it does. Public clouds absolutely run on SANs of some variety. Shared storage is at the core of all of them. Hell, in many you can even select your SAN vendor and get the management of that SAN exposed to you! If you're moaning about what a pain in the ass it is to manage LUNs (fuck LUNs!) try hyperconverged solutions. It's the same "there is no SAN" as you get in a public cloud.
" For guys like you they invented "migration services" to Seamlessly move your Oracle or VMware"
You mean the migration tools that require hours or days of downtime and then still get things wrong? Or require you to completely change how your internal networking is set up before migration, leading to a massive change program that provides ultimately no value to the business just to use a public cloud solution that costs the business half a dozen times more than running in house?
Awesome. Let's do that.
"those tools you are so fond of like Exchange, MS Sql"
What? Where am I fond of those? Fuck them both sideways.
"In Azure don't run on any SAN or HCI, and guess what they have the same or better HA,"
In Azure they run on JBODs attached to shitty Microsoft clusters which is why they both cost so goddamned much and why they have uptime that's two nines worse than what I'm providing in my shitty SMB shops that are held together with duct tape and the wishes of orphaned children.
"Global DR"
DR that never seems to work unless you're paying fuckloads of extra money for it? Pass.
"and consist snapshots don't require any coordination w storage"
Funny, all my hperconvergence solutions take snapshots just fine without coordinating anything with storage. Even the cheap HCI (Scale) can provide me lots of different solutions to solve this. Snap locally, snap remotely, DRaaS...all of it with a maximum of filling out two text boxes and three button pushes.
So what, exactly, are you blithering about here?
"Some just have hard time accepting the IT world would never be the same. The writing and financial report are already on the wall."
Clearly you're speaking about yourself. Your inability to read financial reports is making you oblivious to that part where the boom times for cloud are over, and things for cloud evangelists will never be the same.
"Yes, like Mainframes legacy won't just go away, it will stay for ever, but not sure you can grow a company based on it."
You can grow a company based on mainframes. Millions of companies are growing based on on-premises IT. What's actually questionable is how big a company can grow using public cloud IT, considering virtually all of the large players using cloud decamped off of public cloud solutions after a time.
Public cloud seems like a great plan for some workloads during some stages of a company's lifecycle.
But it sure as shit isn't the be-all and end-all of IT, nor will it ever be.
Just like you, Yaron, i run a public cloud (or more accurately "service provider cloud", as public cloud has come to mean only the Big Four) offering. I also consult with customers about how to optimize their on-premises solutions. Where we differ is that my livelihood isn't tied up in convincing the world that public/service provider clouds are the greatest thing since sliced bread. My livelihood is tied up in making sure that my customers' IT meets their needs. Whether that's in my cloud, someone else's cloud, in their own cloud, or not in any cloud at all.
Cheers.
Also should say that I'm sorry for coming off so strong here. That was wrong of me, and I apologize.
The whole "public cloud is the solution to all ills" thing is one of those nerd evangelism bits that really gets under my skin. The True Believers are absolutely fire-and-brimstone about it...and they are demonstrably wrong. (Just as, you know, anyone pushing any IT solution as the be-all and end-all is demonstrably wrong.)
I believe the reason this grates on me so is the unrelenting - indeed, desperate - nature of the True Believers. Never-ending sales calls at all hours of the day and night. Unrelenting social media attacks against anyone not willing to invest 10x their annual revenue in recoding all their applications.
It's not a good reason to be a dick on the internet, but with some self-examination, it's likely that which set me off.
It's important not to be fooled by what large players are doing. Even in the cloud space. Not everyone is using JBODs, or relying on object storage. There is an awful lot of hyperconvergence and a lot of traditional SANs amongst cloud/service providers.
This is because there are a lot of different use cases to be met.
If you are rewriting everything from scratch as "cloud native", using microservices, using application-level redundancy that doesn't need shared storage, or rely on storage to provide the backups/DR/resiliency for you, then you can absolutely get away with what amounts to a bunch of individual nodes with some disks in them and some software that takes periodic snaps for DR.
But this is only possible because these applications are meeting their RPOs by disbursing data horizontally across multiple nodes at the application level. This flat out doesn't work for legacy applications: the kind most businesses are reliant upon, and unlikely to recode for decades yet to come.
Legacy applications are "pets", not "cattle", and trying to get them to a "cattle" state takes an awful lot of management software layered on top. Configuration management, desired state configs, some means to separate the application from it's data and make that data highly resilient.
Traditional SANs and more modern hyperconvergence have been solving the "make the data highly resilient" problem for ages. If your application goes down, or the node hosting that application goes down, the data is there, accurate to the last bit, ready to be reconnected to. RPO of 0, RTO of however long it takes to restart the application.
But when you look at cloud solutions really closely, a lot of this goes away. If the resiliency isn't in the application then you start to have to make compromises on the RPO of the data side. An HCI cluster or even a traditional SAN spread across multiple racks in multiple power zones with redundant switching can be done relatively cheaply and easily. This gets a lot more difficult with JBOD "clusters", and you flat out can't provide this sort of resiliency in a "everything is local, no shared storage at all" setup.
Now, all storage has limits. If you have enough network connectivity then you can do real-time replication of your data layer across metro areas. Keep the latency below 10msec, and you're probably good for 99.5% of real-world applications. HCI and SAN solutions have this taped. Not a problem. This can provide real-time RPO of 0 across multiple datacenters, and it honestly isn't that expensive, if you're playing the game at datcenter scale.
Beyond that metro area, however, and HCI/SAN suffer from the same problem as JBODs or the "all local" server solutions favoured by some cloud providers: all they can do it send periodic snapshots places.
This means that your RPO goes above 0. Any time you experience an unexpected failure you loose data.
For some workloads that doesn't matter. If you have a web server, for example, managed by a desired state configuration tool like Puppet, then the worst case scenario is that you fail over to some older version of that workload, Puppet detects that the config isn't the latest, and then sets about re-applying the most modern config. So far, so groovy.
But this gets a lot more miserable for databases, files and anything else you want to store. Here is where rewriting and recoding and redesigning everything becomes the thing that cloud providers want you to do.
If you can recode your application to use object storage instead of file storage then you can store images and the like in the object storage. Storage that – wait for it – replicates the objects over the network to provide resiliency. Just like a SAN or HCI does. It's just cheaper to the cloud provider to set up that storage. It's also usually dog slow.
Databases go on fast storage, but you're encouraged to set up complicated database replication schemas to ensure that data is replicated between sites. Replication that occurs over the network. It's just not using the SAN or HCI storage to do it. This is usually pushing the cost back on to the customer, who pays for network traffic, and now has to pay for multiple database instances and multiple storage instances. Great for the cloud providers!
So if you're running a great big globally distributed application that needs to be coded efficiently to run around the world, tearing up your old applications in order to make them cloud native makes sense. This is because no storage mechanism is going to provide an RPO of 0 across oceans. The speed of light is a problem.
But for the overwhelming majority of workloads run by the overwhelming majority of companies, this simply isn't a real-world requirement.
Most companies are happy if more of their workloads have an RPO of 0 for daily use and an RPO of 15 minutes for disasters. They are usually okay with RTOs of "hours" in recovering from disasters, because "disasters" in this case are affecting their customers as well. Some workloads (such as your website) you want up 100% of the time, but that is cheap and easy to do using a SaaS solution, and doesn't require the whole rest of your infrastructure to be a globally distributed solution that's always available.
Many companies who need more resiliency than "within the same datacenter" are just fine with "RPO of 0 at a metro level" clustering and "RPO of 5 minutes snapped to a different geo". Slightly higher needs, but again, if the city ends up flooded out or somesuch, customers will generally understand a brief outage, or a 5 minute data loss.
So this leaves us with the minority of workloads and the minority of companies who absolutely need completely bullet-proof workloads that have world-wide geo-resiliency. These companies with these workloads need to, should, will and are recoding their applications to take advantage of what public cloud has to offer.
Again: what's important to note here is that the extremes don't apply universally. Perhaps more critically...there is zero incentive for most companies to move the majority of their workloads to the public cloud. Not as IaaS, not by rewriting them as SaaS.
SANs, NASes and hyperconvergence will be around for decades yet. And they'll sell in good volume. Because they're simple. Because they do the job. And because, ultimately, "cloud native" isn't the solution to all ills.
Trevor,
yes you come strong, and dont have all the facts straight, i happen to be deeply involved in those Clouds and know how they really work. i'm not a fan of public cloud, but think they have better architecture than traditional ones, and we should adopt their approach regardless if its Public/SP/on-prem. we can learn a lot from their innovation, most Enterprise tech haven't changed for 20 years.
if so many ppl left the cloud, it doesn't explain the surge in AWS and Azure revenue, i attended re:invent can tell you many Enterprise guys were there, some have a Cloud ONLY strategy ("CEO said we wont own any HW")
Fact #1, Azure doesnt use SAN/HCI, they use distributed FS (SMB3) and Blob store over 40/50GbE & RDMA, can point you to public links, VM images are files but many SaaS/PaaS offerings use files directly, they perform faster than most block storage, on the storage you can see their design is lots of NVMe & JBODs. millions of Office 365 users including myself and it works like a charm, better than the Exchange i used to have running over NetApp.
Fact #2, most data in the cloud is in those PaaS, SaaS and object not AWS EBS which is more expensive and limited, and all those file/object/db/.. PaaS & SaaS are using DAS or object for capacity. again hardly any SAN or HCI.
Fact #3, 80-100 bay 3.5" JBODs cost ~$5K attach 4 of those to couple of $5K servers and you have a $30K overhead on 3-4PB HDD storage, can add NVMe in those 2 servers for Metadata & Cache or use 2U 2.5" 60-72 bay JBOFs if you are after performance. this is probably 50-25% the raw HW cost of those HCI/Scale-out storage (Coho, Cohesity, Rubric, ..) with 2-4 servers in a 2U box with only 12-24 drives. we can go over the Excel offline, i did it so many times.
Fact #3, File and object doesn't have to be slow, MS can demo more than 1M IOPs FS, iguazio does >2M IOPs file access and 700K IOPs S3 (Chris saw that 1st hand), traditional all flash NAS guys are <200K IOPs and traditional S3 is ~10K IOPs but its an implementation issue. dont know how many block storage providers do 2M IOPs on 1:1 client:server.
Fact #4, Databases have evolved quite a bit, no more fixed schema rather dynamic + column compression, more use of Flash and tiering at the DB level, you will soon see others adopting our approach of using NVRAM for DB Journals, hot-metadata & Cache, how do you snapshot something that store data in 3-4 independent tiers ? how can you compress/dedup data that is already compressed at the DB level? Traditional DBs dont scale across more than few nodes simply since they work in lock-steps with the SAN, but new DBs from ALL vendors use DAS, distribute table spaces and coordination at the DB transaction level which is the only way to scale, yes you can shout as much as you want but seem to miss a lot of background.
Fact #5, Vertically integrated Databases are faster than over SAN or HCI, Checkout Exadata, Vertica, AWS Aurora as example, or iguazio . 1. with HCI you have two layers of coordination and network chatter 2. new Databases organize data in disk optimal fashion, striping and other storage smarts just degrade perf. yes, if you use MySQL which has a miserable architecture (real all rows/cols in a range for every query) it wont matter much, perf will always suck, just give it some flash so updates and indexes wont kill you.
MySQL will give you 10Ks TPs even if you give it a 1M IOPs flash, OTOH iguazio will get you 2M TPs (100x faster) because we manage the transaction all the way from the incoming RPC to the low-level memory page or sector w/o any Page-Cache/FS/Array serialization.
Yes, i agree orgs have many "Pets" and cant transition so fast, but they do it in steps e.g. move files from NAS to object, move to consume DB as a service with ODBC/JDBC, etc. some use consultants that do "App Modernization" (BTW not sure you heard but today most clouds offer non-disruptive live data migration for your DBs & Apps).
on the same time they build new strategic Apps that focus on Cloud and Mobile First, continuous customer engagement, real-time analytics. they do it because they are so afraid a startup like Uber or pay-pal or their competitor will disrupt their business. for the new Apps they need agility and elasticity, most IT shops cant handle those new "Cattle" Apps at the agility they need so some do it in the cloud.
would love to give you a deep dive 1:1 to show you why some of the myths you got used to are just myths.
Yaron
I believe your "deep involvement" with public clouds has "clouded" your judgement. They don't have better architecture. Just different architecture. No one architecture fits all.
The idea that we should adopt hyperscale hardware and software solutions for on-premises IT is just flat-out bonkers. Hyperscale solutions are designed for hyperscale applications. They aren't inherently better, they sure as hell aren't easier to manage and they aren't cheaper unless you are buying and managing at hyperscale. That's before we talk about RPOs and RTOs. Something you conveniently didn't discuss at all, with the exception of a handwave that amounted to "rewrite everything you have because that lets you be more like Azure".
If enterprise tech hasn't changed a lot in 20 years, maybe you should start thinking that there's a reason for that. Like the fundamental designs are fit for purpose, and that changes will be incremental rather than foundational.
Regarding this bit: "if so many ppl left the cloud, it doesn't explain the surge in AWS and Azure revenue, i attended re:invent can tell you many Enterprise guys were there, some have a Cloud ONLY strategy ("CEO said we wont own any HW")"
I call bullshit. Why don't you go talk to Netflix or Dropbox about the cost of the public cloud? These are some headline names that have left for damned good reasons, and they are by no means the only ones.
Consumption of services which themselves consume the public cloud is increasing. Point solutions like HR applications, payroll applications, etc. These are applications that are like utilities to companies: every company needs them, but they aren't what make the company go. They aren't remotely attached to the core business, they're just a thing that the company has to have. Like phones. So they consume it as a service in order to not think about it. That is what's driving a lot of the public cloud growth.
But, like phones (or any other utility), there's a ceiling to that usage. Just like desktops and eventually tablets plateaued once everyone who had one wanted one, so too will SaaS consumption of these "software utilities".
Archival storage is another thing that's growing in the public cloud space. One look at someone like Backblaze will explain why. Public cloud storage can be very cheap. As long as you don't care about speed.
While I am certain that there are a few companies - usually American Fortune 2000 enterprises, or silicon valley startups - that are willing to go with a "cloud first" or even a "cloud only" model, these are niche. There aren't many of these companies. A fraction of a fraction of a many millions of companies in the world are willing to make that sort of commitment, and for good reason.
Now let's address the rest of your points...
Issue #1: You focus on Azure, but Microsoft isn't the be-all and end-all of clouds. I am aware that Microsoft's primary. storage is their own messed-up franken-glorp. I am also aware that they, like the others, will provide SANs as required to larger customers.
IBM is slightly different in that they aren't so circumspect with their provisioning of traditional storage. They're pretty up front about offering Storage-as-a-Service. For example, they offer Netapp. Indeed: if you need it bad enough, IBM will provide it as a service as part of their public cloud, no matter what it is, or who sells it.
Issue #2: while most data in public clouds today is in object storage and using "native" database services, most public cloud services today are the low hanging fruit. Stuff that was easy and cheap to move, or which was built new for the cloud. That doesn't make the public cloud ready to tackle the overwhelming majority of extant workloads.
Issue #3 (1, because you can't count): I never said JBOD wasn't cheaper. I said it was stupid, unreliable, problematic and way - way - more difficult to manage. It absolutely is cheaper to buy, which is the only thing that matters to hyperscale providers. Of course, when you're not a hyperscale provider, ease of use matters a heck of a lot more. So do RPOs, RTOs and other such things.
Issue #3 (2, because you can't count): File doesn't have to be slow. Until you get above 10M files (NTFS) or 100M files (ReFS, EXT, BTFRS). Then you have to get really creative with the OS an server design to prevent the whole thing from turning to glue. Object can be modest if accessed directly as object storage. It's a miserable pig if you have to use a shim (for example, filesystem access shim on top of object storage, block shim on top of object storage, etc.) There are some startups that have made solutions that almost don't suck on top of object storage, but as a general rule, object is slow when trying to use it as the storage backing for anything other than native object put/gets. Which is a huge problem for all those applications that don't speak object.
Issue #4: And here's you're back to "tear up everything you know and rewrite it because my religion says you should". Microsoft just announced 16 year support for SQL servers, bub. As much as you may get aroused by the idea of new database technologies, they're not helping companies with the software they have today.
Also, no matter how hard you scream, there absolutely are storage solutions that provide snapshotting for storage volumes that are tiered across multiple tiers of storage. I use them every day in production. I don't even need a fancy database to do it! My storage tiers the volume for me, and I run my old, boring databases on top of it. I get fantastic performance without tearing up everything I have and wasting - yes wasting - money recoding applications because some dude on the internet got religion.
I'm not missing background at all on this, mate. You are. You seem to assume that because a vendor supports something that you champion - in this case DAS storage tiering - that it is naturally better than all the other things they support. Here's a giggle for you: all the major databases from all the major vendors support multiple storage approaches, and multiple ways of doing things. Because they have customers. Not acolytes.
Continued in next post.
Continued from previous post:
Issue #5: Speed isn't everything. In fact, speed isn't anything to a lot of people. Banging on about getting a few extra percentage points out of a database that uses tiered DAS and application-level replication versus the HA or replication you get from having your storage solution do the work is the exact sort of tone-deaf malarky that the NVMe of fabrics people are guilty of.
Yes, there are some people for whom database speed is all that matters. They want to run huge databases, distributed at a global scale and every microsecond matters. These are niche cases and they do not represent the majority of businesses nor the majority of workloads. If you want to go build something to grind out microseconds for them, have a ball. I'm sure the mainframe people will find you amusing.
Most companies who use a database, however, don't need that. They're handling functionally irrelevant transactions loads that can absolutely be handled on MySQL running off a consumer flash drive. What matters to them is ease of use. Oh, and cost.
What you - and the NVMe over fabrics people - don't seem to get is that the need for speed is niche. For most of us, speed is a threshold item. Workloads need to go so fast, and everything after that is irrelevant.
Issue #6 (because you started veering off into evangelism in 5): most orgs don't want to move to the cloud. Most orgs don't want to think about their apps. They don't just want what they have now to keep running and not bother them. "App modernization" is a thing pushed by nerds, usually because they have a "app modernization" service to sell. Businesses generally don't care until something forces them to, like the developer of the application going out of business.
Issue #7 (because you started veering off into evangelism in 5): Most organizations don't want to migrate to the cloud. Especially for their traditional apps. This is because it is way more expensive to run those applications in the cloud than on their own infrastructure.
Issue #9 (because you started veering off into evangelism in 5): Most organizations don't want to be "cloud and mobile first". They are cloud where it makes sense financially and where it makes sense from a regulatory perspective, and mobile only if they absolutely have to. (How'd that "mobile first" bit work out for your buddies at Microsoft, eh?)
Organizations can get continuous customer engagement, real-time analytics and the like from on-premises IT just fine. I'd be happy to teach you what happens when a developer and a sysadmin love their paycheques very much, and work together to produce something wonderful.
Issue #10 (because you started veering off into evangelism in 5): Most orgs don't need agility. They need to be better at what they do. The low hanging fruit in IT is still in grinding out human error from internal processes. Even small businesses can save millions every year simply by eliminating shipping errors with a small in-house middware app that integrated with logistics software. No cloud required. No databases that get millions, or even tens of thousands of IOPS. Bonus: eliminating shipping errors helps with customer satisfaction and gives them an edge over competition.
I'd love to give you a deep dive into how IT is practiced in the real world to show you why the myths you've convinced yourself are facts are nothing but taking the use cases of an extreme niche and incorrectly attempting to paint them as important - or even relevant - outside that niche.
Ease of use, cost and regulatory compliance are what matter. You might get some of this, some of the time from the public cloud. You get next to none of it by trying to run your on-premises IT like it was a public cloud. You do get it by fitting the best solution to problem and not trying to pretend you're someone you're not.
- Disclosure NetApp Employee, however my opinions here are my own, though probably filtered through my experience and influence of the information ecosystem in which I live -
Firstly, I enjoyed that, your rants are often entertaining,this one particularly so, I was a little disappointed that you didn't call Yaron out for calling SMB3 a distributed filesystem (which it isn't, its an access protocol) and what Microsoft calls DFS isnt exactly what most people think of when they think of a scale-out disributed filesystem like Gluster, or Lustre or GPFS.
Having said that personally I think the snark-o-meter was probably pushing into the red-zone a little too often, and I thought the ad-hominem retaliation was unnecessary, nonetheless that's your current style and you own it pretty well.
One area I disagree with though is your statement that "most orgs don't want to move to the cloud" . From my experience, there are a growing number of CIOs, often in the largest IT shows who do indeed want cloud (which usually = AWS) because the promise of what it can deliver outside of lift and shift in the PaaS layers like RedShift and EMR is actually pretty awesome. Almost every interesting open source initiative is available from them as a fairly reliable service and MSFTs and IBMs PaaS/SaaS offerings are also intriguing if not compelling alternatives to hiring or even just keeping skilled resources in house. It's not surprising that they are all getting an increasing chunk of the grow and transform budgets.
Because of that promise of a reliable and (reputedly) inexpensive environment to build out "Next Generation" IT capabilities, there are a good many CIOs that start with an easy option and try to push a whole of IT lift-and-shift operation, because it seems easy and straighforward .. take these VMs and put them there ... easy done ... (right ??). These rock-star CIOs get all kinds of positive press and then use that to move on to their next role (I've heard the average tenure of a CIO is 2.5 years) .. then once the rock star moves on, the janitor CIO comes in and spends the next 2.5 years cleaning up the mess they left behind, a lot of which involves finding new homes for their pets who are going feral on the cattle farm. The janitor CIO's don't get a lot of Kudos unfortunately, so the perception is that everyone is moving to cloud, which feeds the movement. There's some pretty solid evidence that most of the new discretionary IT spend (the grow and transform budgets) are getting pushed towards AWS, Azure, Softlayer (or whatever IBM is calling it these days) and Google.
People LOVE the idea of starting fresh and having simple solutions to complex problems, I've seen this happen before with each major IT fashion trend .. the "We're going all Open Sytems, Mainframe is Legacy", then "We're going ALL Windows, Unix is Legacy then "We're going all Virtualisation, Bare Metal is Legacy", then "We're going all Software Defined, Single purpose hardware is Legacy", or "We're going all Cloud, On Premesis is Legacy" ... and yet almost every fortune 500 sized datacenter (which is were most of the profit is made by IT companies) has a broad mix of all of these. Nobody stays with a single approach to all IT problems for long, history shows that having a healthy mix (or a hybrid approach if you want to use the currently fashionable jargon) is usually the best approach. Monocultures are great ways of building industrial scale in agriculture, they're also a great way of building a massive single point of failure that can be taken out by a single change in the environment.
In some respects I think Yaron is right in a lot of places,though I think he was a bit loose in his debating technique which isnt usually a wise thing to do when talking to you (red rag .. meet bull) and the comment section in el-reg isn't exactly the easiest place to pull together a cohesive debate, with decent references or other supporting evidence. It does however make a damn fine soap box to stand on.
Merry Christmas and any other appropriate holiday seasons greetings .. be excellent to each other :-)
From a revenue (and margin) perspective, SAN and NAS are shrinking. But there's no reason to believe that their capacity-share in the datacenter is going away. I just talked to a large retailer who has >5 years of POS data (>10PB) still stored in their Vmax and no plans to archive it soon. In other words don't underestimate the stickiness of traditional workloads with traditional infrastructure. It is clear that the storage world is bifurcating towards AFA+NVMe for IOPS, and towards Object Storage for persistence and protection. But that transition is slow and objective.
Here is what matters: When large OEM storage margins shrink steadily over time, R&D budgets shrink with them, and high-margin products (*existing* products to be specific) get resource priority. This vicious cycle means that customers MUST NOT look to large-OEMs to aggressively reap the benefits of ASP reduction, and they MUST NOT look to large-OEMs for R&D innovation. Listen to your analysts and make sure you are allocating time to hear from up-coming vendors.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
