mainframe
This sounds very much like a mainframe. Everything you need in 1 box, possibly also provide thin client end user computing aswell.
The end of IT as we know it is upon us. Decades of hype, incremental evolution and bitter disappointment are about to come to an end as the provisioning of IT infrastructure is finally commoditised. By the end of the decade, the majority of new IT purchases will be converged infrastructure solutions that I only semi-jokingly …
This should come as no surprise. The mainframe-like model has always been a sensible one from a management and control perspective (probably from an economic one, too, despite frequent complaints to the contrary), so it's been pretty much inevitable that it would eventually be re-invented - under another name, of course! :)
Utopia may be just around the corner, but it seems like a mighty ugly pill...
Isn't it always?
All the work week be done on tablets and internet connectivity will be fast and reliable.
Internet connectivity is fast and reliable for a significant chunk of the parts of the world that have enough money to entire tech companies. 5 years from now it will be better. 10, 15? The first IEMs will start to emerge around 2020. They will probably start to make their way to the SMB space for the first time in 2025. They will be ubiquitous by 2030.
The pieces are all there for anyone willing to see.
Will compliance managers also be replaced by devops, I wonder...
SecOps, actually. I have a piece on that here.
Some of that is explained here. But most of it boils down to this: no matter how much packaged software exists there will always be the need for custom software that meets the very specific needs of a given company. Even if that "custom software" is little more than parsers or translation layers that take one set of data from one application and feed it into the next.
I'd go so far as to say that not only will demand for developers increase over the coming decade, but that they will become essential to larger small businesses and an unquestioned presence in all midmarket companies. Much like systems administrators had been for the past 15 years or so.
IEMs are really about doing away with the need for dedicated ops teams in all but the largest or most niche outfits. It is a lot harder to get rid of developers.
Operations teams keep the lights on. They build the digital edifice of the business, but it is the business that must occupy that edifice and make profits.
Developers are the business in a very real way. The code they create encapsulates the business logic. They automate mundane tasks. They replace entire departments with code. They can even - and this will become far more common far quicker than you think - program robots to do mundane physical tasks.
Once the building is built you don't need builders. You might keep a maintenance guy around, but how much better for most businesses to simply lease the building and let the landlord handle the maintenance? Or, if they own the building, hire a maintenance company to keep it ship-shape?
We are very rapidly approaching the point where operations simply won't be needed by most companies. I do not forsee a point in my lifetime where developers will face the same problem.
I think it's more of a case of transition rather then obsoletion. DevOps, NetOps, SysOps are essentially the roles we have now (i.e. Sys Admins, Network Admins etc.) but with a far more focussed perspective on integrated provisioning. Infrastructure in a box isn't exactly a new concept, and, despite there being extremely clever software to troubleshoot/fix/implement services on the fly, there will always be a need for a techie to give management what they need rather than what they think they need.
Sorry, but I must disagree. The old specialties will go away as they are simply no longer needed. Technology is adding ease of use as a core competency, even at the infrastructure level. That is removing the need to have all these niche infrastructure specialties running about. You really just need capable developers. They can make competently designed infrastructure go.
The only other specialty most organizations will need is SecOps. Though I suspect most won't believe they need SecOps until breaches inevitably happen to them.
What time horizon do you foresee when:
1) technology vendors of all stripes have their kit so well dialed-in that it is truly push-button
2) developers are truly capable enough to do all the ops things which are handled today by "specialists"
Just trying to gauge my retirement window opening, as the web3.0 programmers will presumably be keeping everything running on their own by then. ;-)
Aside from the tongue-cheek, I'm semi-serious with the question. Because the technology vendors I see and experience today are still having trouble keeping up with their own marketing. While their stuff is sometimes easier to setup these days, it's not always more stable/reliable/etc. Maybe your estimation of their improvement and progress curve is higher (and more rapidly accelerating) than mine.
I for one will be happy when it happens, but I expect to be sitting comfortably on the sidelines by then.
> SDI blocks would decimate internal IT teams
Bollocks.
Internal IT teams don't spend most of their time plugging in servers; they spend it managing *applications*. Some of those applications are generic (e.g. E-mail), and one can envisage such appliances being packaged to run on top of this lego brick infrastructure. But many applications are business-specific and/or written, configured and maintained in-house.
The lego brick lets you easily assign extra CPU, disk or RAM to an application when required - and that's a good thing.
It may also *help* with backup and DR (although the application may need to be co-operate - e.g. you can't back up a database successfully without the database knowing)
But a VM infrastructure by itself doesn't deliver any business requirements - it's the apps that do. And changing/configuring those apps in response to business requirements isn't going to go away.
Care to point out which link of the 20 or so you provided, some of which are just simple definition of terms, others that are links to corporate sites, etc. provides the proof that somehow application management will go away?
That will certainly be news for all those companies that have internally developed applications - I guess their developers better re-skill as the IEMs will take over development, the how of which is somehow explained in one of your links?
I don't disagree with your basic premise that the convergence will continue to grow, I've seen that with vBlocks, with some technology I can't talk about yet that is essentially vBlock 2.0, and will continue to evolve as more layers of abstraction are thrown on top so you get further and further away from the actual metal. That only takes the infrastructure management out of it.
That may allow me to not only migrate a running application from Texas to California to London at will, but an entire application suite or even an entire (virtual) datacenter. That would mostly free us from today's infrastructure concerns like RAS and DR, but the software running below all that abstraction still has to accomplish something. Someone has to tell it what to accomplish, how to collect information it needs from the outside and how to deliver what is accomplished to whoever or whatever requires it. An IEM isn't going to do that, people are.
And we won't be there by 2020, either.
This for one.
Here is another worth reading.
What I discussed in the article itself - and in associated articles - is more than "just a hyperconverged solution", which you seem focused on believing I'm talking about. It's more than just VMs. It's the ability to consume applications through an application store/virtual appliance library/etc.
Legacy applications may need care and feeding, but that whole style of application design is going away, and fast. Cloud native application development models are the norm amongst younger developers and there are rapidly becoming more of them than there are of us.
Developers are largely able to maintain infrastructure on their own. They are being trained to code in monitoring, make failure-tolerant applications, and interact with all infrastructure subsystems from disaster recovery and backup to storage.
Right now, today, and for the next five years or so, there is a lot of money to be made automating legacy software. But once that's automated, it's mostly done with. Entire teams of sysadmins and specialists can be wiped out and replaced with a single maintenance drone as the new applications are developed against infrastructure that is addressable by API.
Developers will blossom in the datacenter of the 2020s. Operations is already dead, it just hasn't accepted it yet.
Security will blossom in the datacenter of the 2020s, and if operations don't convert from their existing specialties to security, they'll be out of a job.
In large enough or niche companies there may be room for teams of operations admins. But in most companies - including most enterprises - the operations team circa 2025 will be a fraction the size ti is today. The developers will explode in size. The security teams will explode in size. The operations teams will consist of the proverbial "man and a dog".
And yes, the first IEMs will start rolling out by 2020. By 2025 enterprises will have finished reorganising their IT teams such that operations functionally no longer exists. By 2030 IEMs will be cheap enough for the SMB, and so much new software will exist that SMBs can run this stuff on their own, without nerds.
What I think you don't grok is that how applications are build has changed. It used to be that automation, high availability, backups, disaster recovery and so forth were all done by operations teams. This is increasingly not the case. New applications have this stuff built in, and this is the model of design being taught to new developers.
Tomorrow's applications won't need the sort of care and feeding that today's do. They will just need (relatively) stable APIs. We'll spend the next five years automating our legacy software, 5 years after that realizing that operations is not doing anything for the money we pay them and then it's "man and a dog" time.
Meanwhile, one at a time, those legacy applications will be replaced.
Operations is already dead. But feel free to bet your career on its continued viability if you so choose.
The article seems to suggest that the successful IEM vendor would inevitably have every last one of your short and curlies in a vice-like grip. Does that mean there is a business case for never using these, or for insisting on an open standard? Perhaps not. Most businesses are already so utterly dependent on warts in old versions of Active Directory that even upgrading to a supported version of Windows *with Microsoft offering to help* appears to be beyond some of them.
Liked the line about HP's Saturn V. :) Is this a case where none of the existing big players have the vision to let the new product cannibalise their existing market share in the products that will soon be in the dustbin of history?
Nail on the head.
I can tell you how the pieces are aligning. I can't tell you yet who will win, or whether open standards (read: OpenStack, most likely) will win. I suspect that if two proprietary IEMs appear that are mostly interoperable (where "interoperable" can be achieved with some minor conversion of automation/orchestration runbooks between the IEMs) then enterprises won't care. They only ever needed EMC and Netapp to play off one another, (or Oracle, DB2 and SQL)...why would they need more than two, possibly three IEMs?
Interesting few years ahead...
The end result of all of this convergence is that IT folks are going to have to have more of a systems integration skill set. I agree that it will probably knock down a lot of the silos we see in IT, especially in domains like Storage Admin or VM Provisioning Admin. This is mainly due to the fact that a lot of the vendor-specific complexity will be abstracted away once the fundamental units shift completely from, say "NetApp LUN" to "XXX GB generic storage." Or, "VMWare VM version 8, name X, disk 1 on datastore Y, NIC on VLAN Z, host group A, affinity policy B" shifting to "Database Server Template Z" All of that complexity is going to exist still, but it'll increasingly be inside a "no user serviceable parts inside" box.
The first comment up top says "sounds like a mainframe" and they're absolutely right. IBM rolls in a generic "box" with all the functionality abstracted away, automatically sends service guys to fix broken stuff, etc. and charges an eye-watering fee per MIPS to pay for it all.
I think IT people who are sufficiently schooled in the end-to-end functionality of systems and applications will still have a place at the table. Except for the simplest of web-based cases, like phone app front ends or something, I can't see -all- of the complexity needed to get something working reliably go away, nor can I see developers being handed the keys and being told "go nuts, provision anything you need." (No offense to developers, but that method is how we get system requirements of 4 socket equivalent reservations with astronomical memory and disk requirements for simple apps.) It will be a big shift for many in IT - I know lots of people who are geniuses in a few tools and have spent lots of time learning a very narrow specialty.
This post has been deleted by its author
Makes you feel like Sarah Conner; fully aware of the coming armageddon but unable to make anyone believe you. Trevor is spot on where careers are concerned and the readers' denial is very much the norm.
I've written many a blog post on the career related side of this (on a networking blog) and it's clear no-one wants to even consider the possibility that things will change in a significant way. Specialisation is one way to stay relevant but I'd say it's more likely to be a balance, serious skills in a few things, a good knowledge and understanding of many, many more.
I ended the last blog with this:
"Your silo is eroding rapidly, their containers multiply and everything will become software. Only you can decide whether you are a part of that future (take part, add value and be useful), or stay in the past and suffer the consequences."
You use the phrase "the coming armageddon" (sic) and "Only you can decide whether you are a part of that future". Speaking for myself in the very least, I came into the IT industry knowing that my desire to obtain technical knowledge is an unsatiable beast that must be fed on a daily basis. Those of us who care about their profession should not be content with merely resting on their laurels but instead actively seek to expand that knowledge. IIAB (Infrastructure in a box) is no different from any other paradigm shift that's happened in IT (remember how hardware vendors, particularly data centre vendors, shat themselves initially when virtualisation was just a buzzword?). We will adapt. We will change accordingly.
Ease of use as a core competency is a fanastic goal. It doesn't mean however that because there are several layers of abstraction in terms of, say, provisioning a new application that there should be a total absence of technical expertise from the mix. Companies/Businesses will always require some form of customisation and, more importantly, will require people who not only understand the technology but also the business needs too.
And? So? Why do you think that gets you a job?
Companies have hundreds of operations nerds today. Why does "customizing an IEM" or even "periodically updating the automation for legacy and paleo software" require hundreds of systems administrators going forward?
Once the infrastructure can largely take care of itself, the old software is automated, and developers are making the new software with automation built-in and control of the infrastructure that software runs on through APIs....why do they need more than 4 people to do what had ben done by hundreds?
Someone has to do maintenance and update runbooks. I absolutely, 100% agree. So that's 3 shifts of 8 hours a day and one extra body to cover in while you rotate the other three out for vacations and training.
That is what is under discussion here. The technologies that will allow going from 100 operations sysadmins to 4. It's the technology that is going to mean that instead of SMBs relying exclusively on VARs and MSPs handling IT as consultants until they get to about 50 seats you'll see SMBs be able to avoid hiring sysadmins until they are 250 or even 500 seats. The VARs and MSPs will eb able to handle many - many - more seats worth of servers across their customer base with far fewer administrators.
There will still be a need to have end user helpdesk support. That's seperate from IT operations. There will still be a need for developers - the number of devs will explode. There will be a massively growing need for security and compliance professionals.
But the days of getting paid to watch blinkenlights or create users in some wretched piece of paleo softtware are coming to a rapid end.
unless you are absolutely the best of the best of the best and you can do architecture work you're going to be shit out of luck as a systems administrator. And with so many sysadmins hitting hte market as redundant, the downwards wage pressure is going to be extreme. Those 4 guys kept around from a department of 100 are going to be paid peanuts.
If you think I'm wrong, then by all means, plow ahead.
Well, I would rename IEMs into IEMs -infrastructure enabling machines- ;-)
I agree certain jobs will diminish. But industrialization is the horse we all are riding on – let it run, dude.
Extrapolation forgets
-changing incentives for the involved parties over time
-the demand side of the equation
Taking into consideration the ongoing digitalisation of all our life/business sectors we are just in front of a new and big wave of IT services which couldn't be realized in old school infrastructure.
It's easy to talk about all this in abstract. Prognosticating about the future of IT is a fool's game, and putting actual dates to things is sheer madness. If I'm going to take the risk of being so laughably wrong in public, I should at least join Gartner so that I can milk a high salary out of promoting my humiliation, no?
Such prognostications about the future of economies and financials is what the likes of Mark Carney and governments do all the time to fool themselves and the masses into believing that they know how to handle and run things and that such things can be handled and run quite easily with the demand and supply of readily printed paper money supplied with the addition of an interest rated charge to return more than was supplied. And they bring out all sorts of sticky cakes and sweet buns to make it look like they no what is to happen from the failures which have resulted in the past and produced the present ……. http://www.telegraph.co.uk/finance/bank-of-england/11786604/Bank-of-England-Super-Thursday-Interest-rate-rise-expected-next-year-live.html
And Trevor [Potts], should you have written …”IBM has evolved SoftLayer into their first IEM” …… rather than “IBM has evolved SoftLayer into the first IEM”, for the latter is surely one of those known unknown things*:-)?
Nice to know though, that El Reg is so switched on to what is happening/happened in the Greater Bigger Picture Show, and so prepared to further share more and more about how IT Powers and EMPowers IT Takeover and Makeover of Global Systems and Universal Assets.
Methinks it be a very likely fact though, that rather than any sort of a mainstream/markets player being instrumental in anything of such a nature in the present for the future, are the leaders to be found in the ilks of a postmodernist Bletchley Park/Unit 61398 operation ….. Virtual Terrain Team Effort.
*Donald Rumsfeld .... the oracle that just keeps on giving:-) ....... "There are known knowns. These are things we know that we know. There are known unknowns. That is to say, there are things that we know we don't know. But there are also unknown unknowns. There are things we don't know we don't know."
IBM has evolved SoftLayer into their first IEM” …… rather than “IBM has evolved SoftLayer into the first IEM”, for the latter is surely one of those known unknown things
You are right, your version is clearly more precise to mine. Pint to you.
Such prognostications about the future of economies and financials is what the likes of Mark Carney and governments do all the time to fool themselves
Don't disagree. I believe that's covered in the preamble where I say, essentially, "so I realize that by making predictions in public I am setting myself up for future humiliation if (and maybe when) this all proves to be utter bollocks". I know I'm sticking my neck out.
That said, I think every now and again we need people to take that risk and talk about where things are going. This allows us to all have a think about things and then have discussions. Is the scenario presented possible? Is it likely? What are the implications? Do we like the scenario presented?
If we feel the prognosticator is right, how can we adapt to best take advantage of the changes discussed? If we like the changes discussed, how can we encourage the future to unfold in this manner? If we don't like those changes, how can we try to alter the outcome?
I have a visibility of IT as a whole that few people have. By and large, it's my job to get that visibility and I pay for it in endless briefings and presentations.
I am good at seeing patterns. Tracking thousands upon thousands of variables and assembling the jigsaw puzzle of possibility. This is what I see coalescing out of the spinning fragments of effort from dozens of organizations and thousands of engineers, all working separately but (unknowingly) towards similar goals.
There are a lot of unknowns - known or otherwise - but IT is actually a fairly predictable industry. It's run by nerds who rather like logic, after all. ;)
Future knowledge freely shared, TP, is a wonderfully dangerous thing in worlds reliant on secrecy and selective mis/disinformation to try to survive intact and I disturbed in a changing landscape and, particularly and peculiarly so too, in Live Operational Virtual Environments ....... CyberIntelAIgent Space Command and Control Centres, .... but IT holds no actionable fears for the SMARTR SCADA Enabling and Sublimely EMPowered and EMPowering.
AI@ITsWork in Progress with Futures and Options in Hedged Developments? Yes, of course IT is. And a much sooner rather than later when you think application for Virtual Machines/Infrastructure Endgame Machines.
I tend to agree with most points - it's effectively unavoidable that the lower layers will be increasingly transparent and abstracted, that scalability and ease of relocation will increase massively, that all these things we're doing separately now are going to become far less intense and almost automated.
But at least for a fair few years, it will still go wrong, there will still be things which require human hand-holding, so I'm not too concerned. Plus, let's not forget that you will still need people capable of easing the migration in the first place.
I'm primarily a networks guy, with smaller Windows, UNIX and operational support hats; to pigeon hole myself in networking and stick my fingers in my ears shouting "lalalala!" when faced with anything else is not only short sighted (for the aforementioned reasons, and your article), but it would prevent me from doing my job well. If you look at some devs, you will probably find that a fair few of them also need to expand their own skillset into the networking and sysadmin universe - so yes, they'll be needed, but they also need to adapt.
I suppose the simple conclusion is that the pace of change will always inevitably speed up; if you're in or starting in IT now and will want a job for more than the next five years, expect to have to learn a lot of ever changing skills, otherwise you've made the wrong career choice.