If you absolutely must do a ‘private cloud’ thing, here's how I dislike the term “private cloud". As far as I'm concerned, there's really no difference between what I'd call a “traditional” homespun virtualised infrastructure and what they call “private cloud” these days. As Gartner puts it, private cloud is: “A form of cloud computing that is used by only one organisation, or that …
Seems fine for the beancounters. Reduces IT costs and staff costs.
Then along comes a guy with a JCB to lay a new pipe across your car park and phut goes your connection to that lovely business critical data.
Unless you have at least two totally separate and redundant connections to 'the cloud' then you are just asking for trouble (IMHO). single points of failure and all that.
At least with an on premised cloud (viz existing server farm) the only danger from the errant back-hoe is that the offsite backups might not get made for a day or two.
Given the very public cloud outages in the past week, who is going to standup and say sorry (like the VW Chairman) when you biz goes TITSUP after you bet it all on offsite cloud.
now where's my umbrella? I looks like rain ahead.
Surely in this brave new cloudy world all your employees are scattered across the hipstersphere. They should all be in various coffee shops sipping skinny lattes and spaffing confidential data across the wi-fi on their BYODs. So unless a JCB goes through the whole of Shoreditch simultaneously, it's not a problem. Plus Finance will moan about the costs of second lines so you won't get one.
Bitter? Moi?
Please tell us what Coffee shops you frequent so that we can avoid them just to stop ourselve from slurping all that lovely Wifi data and selling it to the Chinese/Russians
In my company (anon for obvious reasons)doing that sort of thing is getting close to a sacking. That's why we have 3G dongles provided with the laptops. We are not supposed to use Wifi even at home.
As for the hipstersphere? I think I had hips once....
It has been known for a JCB for dig up a main BT cable and plunge whole areas in data darkness. I guess that if it happened to Shoreditch no one would notice anyway apart from the slight increase in hot air rising from the area.
Yeah cos that comms link that the JCB battered only connects you to 'the cloud' and will have no impact on the on-prem luddites whose branch / distributed office / hosted services / B2B capability / campus networks who use JCB-proof comms links to connect to their data.
Not saying cloud's the answer like.
"Unless you have at least two totally separate and redundant connections" - JCBs and/or their drivers have an innate ability to find the one spot where those logically/commercially "separate" connections are not so separate. Either they have been bundled up together by a downstream 3rd party into one physical conduit or they cross over each other.
"A form of cloud computing that is used by only one organisation, or that ensures that an organisation is completely isolated from others."
Not as isolated as you think. How isolated is it, for example, from the organisation who have it in their server racks, connected to their network infrastructure, running on their power, possibly backed up by their systems too?
It's like the whole VPS web hosting thing. Yeah it's your own "private" server, on which many other peoples web applications also run. Private? No. Contained? Perhaps.
Actually, they are 'private'.
AWS will, for its larger customers will carve out areas within their networks that contain servers that are only used to host software for said customer. You really don't have to worry about a noisy neighbor unless its from a different group within your company. Expand the reserved space by increasing the VNs and servers on the VN.
So yes, its 'private'.
As a case in point - you've mentioned worrying about a "neighbour". I'm talking about the people who actually control the infrastructure - in your example Amazon themselves.
Pretty sure that if you put a file on a disk owned by Amazon they can read it. If you're uploading it through some password protected interface or application - so what? As long as they can find the location of the files they can read them. If the files are encrypted that's slightly different. But again, it would depend how they are accessed as to exactly how secure they are.
In the example of a VPS web server - 10 different companies might have their own contained and "private" environments. If I work for the hosting company and have root level access, pretty sure the idea of it being private goes out of the window.
Though a genuine concern, the bigger problem with leaky data is internal - people at your company who have access to the data. They are more of a threat than a bored sysadmin at cloudy farm provider. He will probably want to read his comic book than to look through a bunch of boring jibberish. The mole has access already and in many cases has a position requiring access to the data.
To me anyway cloud implies a large amount of automation. I think this automation is way overkill for most organizations and generally requires a significant amount of work to make it work and generally isn't very flexible (to quote a recent el reg article gartner said something like less than 5% of the users of in house IaaS was happy with the setup).
Virtualization on the other hand by itself to me is utility computing. Pools of resources that can be carved up into VMs(compute) or volumes(storage). Some automation may be there (vSphere DRS or HA or other types of things) but it's not fully automated from VM to application(s) totally integrated and "aware".
Which is why to me a lot of users of public clouds end up paying so much because they implement utility computing in a cloud environment where it is not built to support(and when you do that not only do costs explode but problems expand by orders of magnitude because things don't(or can't) self heal etc.
Indeed, which is why someone starting an article "As far as I'm concerned, there's really no difference between what I'd call a “traditional” homespun virtualised infrastructure and what they call “private cloud” these days." shouldn't be writing said article. There is a very well defined explanation of what constitutes a cloud from NIST (they wrote it a decade ago) and it's available at csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf.
A quick read of it's two pages will explain why Hyper-V without a properly set up SC-VMM (and most are not fully implemented) and vSphere in pretty much any form are not clouds at all. Neither, for that matter, is vCloud Air as it lacks various cloud functionality.
It's entirely possible to implement a private cloud on top of these technologies, but it's extremely rare for that particular juice to be worth the squeeze when compared to just buying public cloud.
Rackspace Private CLoud is like:
"Let's spin up a new VM!!"......
Me: Rack, did you already added that VM?
Rack: No, we are waiting for a signature from your manager
Me: Informs manager:
Rack: Ok, we have received the approval, we are going to make a plan.
Me:Ok..
Me: Waits
Me:Rack, what is the status?
Rack: We are planning it out and a technician will create the VM for you
Me: Ok, please let me know when it's done
Rack: Ir's done, please test...
Me: Thanks! That only took 2 weeks!
HAHA! I have a similar tale from the fine folks who got tricked into moving ALL their web eCommerce site to an IBM hosting facility:
eDummy manager: Can you host our crap and stuff so we can fire all these super expensive sys admins and other support costs, er people?
IBMsalesdroid: Sure can, guy! We can move your crap to Colorado in our super duper hosting center and give you a new virtual environment in about 30 minutes!
eDummy: We're IN!!1!
IBM: (what a frickin' tool) Okay, buddy, let's fire those guys after we get them to give up the passwords and such!
eD: Sweet! This is going GREAT! Upper management has been taken on special fishing trips and given gifts from the IBMers, what could possibly go wrong?
*move of site and new h/w goes online
eD: Okay, friend, let's have those sweet quickly built environments!
IBM: Sure thing, just wait a month for the paperwork to clear, and also for you to forget any possibility of having any different Java than the one version we support. OS not to your liking? Tough luck, guy. We just support this one that is not the version you were even using before, but this is what you get, you dumb bastard. Where's my PO?
eD: Crap, let's just hire everyone back at 150% rates and buy all new equipment and move EVERYTHING BACK IN-HOUSE.
true story.
Finance Guy: Hey IT, we need a new expense tracking system which can handle cross border approval flows, document storage and keeps up to date with the various accounting rules of each of the countries that we operate in. Oh, and we will also need a mobile app for it and if it could load information automatically from the credit card system that would be great.
System guy: Sure we can build one for you, probably take about a year. Oh and we will need a number of contractors to help build it out as it will require a number of specialist skills, we will need to update the hardware and you will need to give us tax rules for each country you operate in (and regular updates), help us determine the data sources and data feeds from any other application you want to sync with
Finance Guy: F#ck that - I can buy one in the 'cloud' for a monthly subscription fee and have it live in 1 month. Will cost a fraction of what you are proposing. Users will already be likely trained on it when they join as its a commonly used software which they may have used in a previous company.
....
move on 12 months...
....
Finance guy: We need to transfer the expenses tool as there is a much better one which plugs into our new CRM software. Only issue is, I need to have historical access to all the old info but it's all in a different cloud system and we have no way to understand how to get it (legal requirement)...help...
Systems Guy: ...
Finance Guy: crap, our systems guys have gone as we didn't need them as we were self-administering....
pro's and con's people - no solution is going to be the best to cover existing business needs (and business timelines/budgets) and protect against future issues but I agree the collaboration between the business users and the systems/IT team needs to be a lot better and a lot more balanced on future needs - not just for security but also for future migration
Today the term 'cloud' is the key buzzword. If you don't use that term in describing your infrastructure, the pointy haired executives and bean counters question your IT knowledge.
Private Cloud is another term for a leased data center w leased equipment maintained by the DC.
But vendors who want to make their leased DC options sound 'hip' and 'modern' have latched on to the term 'private cloud'.
Of course that's also what you get when you have AWS carve out a niche of servers solely for a single customer too. So Caveat Emptor.
"Frankly, you could remove the word “cloud” and not notice the difference."
Totally agree with you and, quite possibly given the above statement, so does the author of this piece.
Every so often, some marketing bod comes up with a new term for something that we already have but don't have a quirky name for, or they come up with a new idea that masks something that if we knew exactly what it was, we'd hate it.
The current word doing the rounds is "telemetry" which is being used as a synonym for corporate snooping. "Cloud" was a term to mean "centralised leased operational unit domain" or somesuch, the result being an offsite lump of server service and storage. It won't stop there either, not as long as marketing execs continue to reap the rewards of terms that appear to catch on.
Or, as I used to say, "...the greater good... the greater good..."
Nope, private cloud means much more than a vnware install in your data centre - it means IAM, capacity on demand, instant containerisation, database as a service, stream as a service - all the things that AWS, Microsoft and Google invest billions in. Which is why it's almost impossible. And why Gartner say that 99 out of 100 private clouds fail.
I have a mess of issues with "public cloud" - mostly to do with security issues and mitigation processes. However the single biggest issue in getting from point a to point b is that automation *has* to come into the equation. Part and parcel with automation of application deployment is that "standard deployment" is typically specific to a vendor - so you have to build your deployment tools around a vendor stream - and when you have 40 or 50 software vendors in the feed line it can get *disgustingly* difficult to harmonize your installations to not trip over one another. I've built cfengine kit to deploy *dozens* of apps in a *reasonably* automated fashion (LDAP would have made my life soooo much easier) but regularly get "but our specialist application that needs that wants it installed HERE, not there" (and I've 100% satisfied that set of issues with path functionality on linux, hpux and aix) what gets me *most* about some vendors is how when putting software into a *nix environment they completely and utterly ignore posix standards, os vendor standards and general best practices by assuming that the application will a) run as root, b) own the entire host from top to bottom and c) get to choose its own ports UIDs and GUIDs.
Cloud, by the way, in my books, is nothing but a buzzword for "really damned good automation that works". But even then the automation can still suck.
(why, yes, I *am* arguing with a vendor about what they said in the sales pitch versus what their field engineers are trying to do in my datacentre right now, thanks)
If I had my way, any requirement to run as root (*nix) or with Admin privileges would immediately rule out use of that piece of software.
What's even more depressing is that when a vendor claims that requirement, they don't really need it. I had this wit an accounts package - when questioned, it turned out they only needed write permissions to one - yes, just one - registry entry. Properly setting the permission on that entity enabled the app to run in the logged-in user's privilege context.
For some reason, accounts apps seem to be the worst at this. We had it at Olivetti in the early 80's with the app developers for the S6000. A large clue-by-four was needed.
It amazes how the people who complained the most about having special needs for In house implementations seem quite happy to jump to vanilla cloud installs. When the reality of what the vendor charges for something extra bites suddenly they don't needs it so much, in reality they fudge a manual workaround rather than admit reality
The reason for this is that the obsessive it bod who insisted on military grade security for the internal systems doesn't get consulted when moving to cloud because he never delivered anything on time or budget.
Vanilla cloud can be delivered on time and under budget very easily, making it look a success immediately, and the guy who implemented it a team player who works for the company rather than against.
The world isn't fair, the trick seems to be not caring about the outcome which most of us find impossible, myself included.
Amazon will be forgiven quickly for this because they will own up, fix the issue, and most importantly because they have already shown their value over internal IT to most of their customers.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
