Slashdot Mirror
How Increasing Cloud Reliance Affects IT Jobs
snydeq writes "Kevin Fogarty takes a look at how the rise of cloud computing will impact IT jobs, outlining which roles stand to gain prominence in the years to come, and which roles will suffer as organizations extend their commitments to the cloud. 'Ultimately the bulk of IT could look more like a projects office than the way it looks now, when most of the hands-on work is done inside. It probably won't be a total transformation, but moving into cloud, there will be more of that and less DIY.'"
Great, I was hoping they'd get around to removing the last bits of enjoyment from my career before I retire. They're even ahead of schedule!
http://alternatives.rzero.com/
Your business is dead in the water.
If that only happens 2 days a year, you just factor that as a cost unless there is some critical reason you must remain up (hospital).
Also, it becomes difficult to differentiate your business from others.
As jobs get completely slaughtered something has to give. Shorter work weeks or civil unrest.
She was like chocolate when she drank... semi-sweet at first and then increasingly bitter.
Sod IT, go to law school. When it's all up in the cloud and the cloud breaks there'll be a killing to be made.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
"Cloud" exists because the MBA's wanted their own word for Internet.
Do not mock my vision of impractical footwear
Well then it's a good thing that VMWare just put up a big old toll plaza on the road to the cloud that will slow things down significantly for many organizations. For those that aren't aware VMWare just announced their pricing model for ESX 5 and it's pretty freaking outrageous, $90/GB list bought in $2800 increments if you want Enterprise with most of the good features.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
"The Cloud" is really just the latest advance in the relentless encroachment of "appliances", which are just the IT-specific implementation of the replacement of skilled tradesmen with capital-intensive systems and disposable peons that has already done a pretty good job in other industries.
You can replace thousands of jacks-of-many-trades smalltime sysadmins with a few architects and a bunch of screwdriver monkeys. ROI, here we come! (Even the confusion over what constitutes a "cloud" arguably shows the progression in finer detail: Things like EC2 only abstract away the hardware and interconnect stuff, while leaving you with the need for VM admins to actually turn the cloud into services. Things like Azure or Google's App whatever it is abstract away the sysadmins and leave you just needing the coders to write the applications. Hosted applications, webapps, 3rd-party email providers and the like abstract away the apps, and just leave you to point the client at the right URL. As soon as we all get our Chromebooks, we can fire everybody but the licensing person and the janitor, and each replacement laptop will automatically be provisioned according to the spreadsheet maintained by the licensing person as soon as the janitor plunks it on top of the RFID fob built into the desk...)
On the (very bleak) bright side, we might at least get to enjoy a little righteous schadenfreude when the axe comes for those techie-uber-libertarians who have spent years watching other peoples' creeping unemployment with the smug conviction that they are too good for that, and the peons can always retrain for the new jobs that the invisible hand of innovation will shortly be providing...
The problem with the "cloud" is that you put your complete trust in
a. the cloud provider
b. the telco that connects you to the cloud
As anyone who has ever had to deal with outside vendors knows, they have no real commitment to your business. You are a single account.
When your business cannot connect to the systems, it is a crisis for your business.
For them, it is another day in the office.
Corporations without any IT staff interfacing with "vendors" who are highly proficient at making soothing technical noises while cranking out large bills? Wheeee...money growing on MBA-shaped trees.
And "What trade secrets?" is the least of it....CEOs better start being careful about the content of the emails they send to their mistresses, 'cuz leverage is leverage.
Orwell: "In a Time of Universal Deceit, telling the Truth is a Revolutionary Act"
Oh really. How do you connect to that cloud thingy. You still need some local IT infrastructure for that.
Contractually guaranteed. Good luck with that contract, when your business depends on third party, third party fscks up and only you have is some paper.
http://en.wikipedia.org/wiki/Dropbox_(service)#Criticism
Only if your cloud service provider does not have some dependency on client OS.
Private clouds will win in the end. With public clouds you get:
1. No hardware control.
a) You have no control over your server hardware. It could be running on counterfeit bits of string and chewing gum from China for all you know (try explaining that to a defense contractor).
b) You have no control over physical access to your hardware. You'd better hope the guy they hired at minimum wage to watch the door at night didn't get a better offer.
c) You have no control over bandwidth and connectivity agreements. I hope the ISPs between you and the datacenter are friendly, because a single peering dispute with you on the other side or a new and unfriendly QoS arrangement and you're fucked.
2. No cost control.
a) Presently cloud services like Amazon's do not allow you to set usage caps for your servers. A DDoS at the right time could cost you unheard-of amounts of money, your job (hey, you're responsible for this cloud thing, right?) or even bankrupt your enterprise.
b) Usage-based costs are unpredictable and will play hell with your budget forecasts.
c) Fees for everything. TANSTAAFL.
3. No data control.
a) You have no guarantee your data is securely disposed of when your cloud provider recycles its drives.
b) Your data could go missing at any time for no reason in a manner that prevents its restoration from anything but expensive offsite storage, which you're still maintaining now that you're using the cloud, right? -- As Amazon so eloquently proved.
c) What happens when your cloud provider goes out of business like Iron Mountain?
Private clouds will afford you most of the benefits with none of these problems. In the end it all boils down to money: the cloud has brought us commodity-scale computing, and you get what you pay for. If anything, I foresee a bright future in fabrics, and not the textile kind. Better brush off those networking credentials.
For a midsized company, one would be a fool not to go with cloud based services.
Until that close encounter between an excavator and both of your redundant Internet connections... ;-)
The cloud exists to hide infrastructure. The cloud is an abstract network. If, for example, all the service's ties to the USA die, you are automatically routed to the datacenter in Germany. You don't know or care about how it works, it just does. It doesn't fail because it is the cloud.
If you service cannot automatically deal with failure, it is not the cloud, it is just a regular node on the network.
When the systems were in your office, you had X number of points of failure.
And you had someone on site who's job it was to make sure that those systems were available to you.
So you're moving to the "cloud" to save money ... by increasing the number of the points of failure.
So then you add additional systems to mitigate the problems that come with the "cloud". And you probably outsource the maintenance of those systems as well.
And everything is fine until there is a problem. At which point you realize that all the people who you depend upon to keep your systems working only see you as another account. If your business fails, then they're out a portion of their income (until they replace the account with another one).
EC2 is not the cloud. EC2 can provide you with the tools necessary to build a cloud service, but by itself it just a datacenter full of computers. And you cannot throw your application on a few EC2 instances in the same datacenter and call it a cloud application either. That is not the cloud, that's just a networked application.
If a service cannot survive simultaneous catastrophic failures in multiple physical locations, it is not a cloud service. Without being intimately familiar with it, I would like to say that Amazon's S3 service would fit the bill for being a cloud service. Given what Amazon has said about it, it does sound like it meets the criteria of the cloud. EC2, however, does not.
I'll bite.
Scalability: Depends. Some things may scale like putting files for download with Akamai. Other things, not so much. The cloud is a tool in the architect's toolbox.
Admin payroll: Someone is going to need to architect things, so you will still have an IT department, if only to maintain your internal network links, and make sure the desktop PCs don't become botnet clients. Don't forget networking. You will need to have those fat pipes to access the cloud provider, so you will still need a space for those Cisco Nexus 7000 boxes with the clear covers.
Guarenteed SLAs: Read the contract... the SLA may not be as good as people think it might be.
Oh, and if the cloud provider goes bankrupt, the data on their servers is free for the taking by anyone who so desires. Even though it is SOP for auctions to wipe the drives, this gets forgotten or "forgotten". Promises mean nothing when some competitor in Elbonia now has your payroll (sold your employees' info to ID thieves), your client list (and is offering the same services for 50% less), your source code (with a version of your product that is exactly the same except in name), your suppliers (which are then harassed to make better deals elsewhere), and others.
No recorded breach with a cloud provider... time will tell on this one. Nothing is 100% secure. Gmail has had people report incidents, Dropbox has had the security tokens that people talked about, and so on.
No server room? I'm sorry, but even with "economies of scale", you are either paying for a data center in house, or you will be paying for one somewhere else. Don't forget regulations about physical security of data.
DB/OS versions? Sure. However, if something breaks your app's code due to an update done without notice, there is no way to roll back. ITIL 101 here.
Exchange versions? See above.
Don't assume the cloud provider has backups automatically. If someone logs on as an admin with a cloud provider and blows all your storage away, it may not be recoverable, while the old LTO-5 tape library will be able to restore data. When push comes to shove, and in some industries, you better retain data for a while (up to 50 years if dealing with the FAA), you need to pack your own parachute. I trust tape, and moving archived data to the latest archival version every couple years far more than a cloud provider's promise. However, I'm one of those "IT guys" that the parent apparently dislike, so if someone wants to be fast and loose with their data, they can store it on the cloud and assume that their storage has all the snapshot features of the EMC SAN they want to chuck.
Cloud computing is a useful tool. It won't replace server rooms anytime soon. Maybe I'm a fossil, but I rather trust a VTL, replicated SAN, or even good old fashioned tape far more than I would trust just an assurance that a cloud provider has my data backed up.
I gotta say, I've tried several "Cloud" services and I am not impressed when it comes to TCO. While it's nice to have on demand provisioning, the performance of the virtual server instances are generally very poor compared to basic dedicated servers that are similarly priced.
Don't believe me.... run a simple sysbench and test the cpu and file io on EC2 (or your favorite cloud service) and compare it to a hosted dedicated box. In general on a similarly priced and spec-ed VM/machine you are going to find orders of magnitude better performance on the dedicated box, and that performance equals money saved.
In addition, many dedicated hosts now have 2 or 4 hour provisioning times - so if you don't need more boxes instantly, it's not as if you need to wait that long.
So yes, in the end, cloud services can be convenient.... but you certainly pay for that convenience. They are great for testing and development, but long-term hosting.... eh.... most companies would be better off if they stopped drinking the kool-aid and looked at other options.