We asked three experts, an analyst, a sysadmin, and a vendor consultant, to give us their views on what, exactly, is the cloud OS, or cloud operating environment, and why would anyone need it? Their contributions are below. Dale Vile, CEO of Freeform Dynamics To answer this question we must consider the context. In a recent Reg …
"It is the last piece of this puzzle that Microsoft clearly has the lead on. Server 2012 is an amazing operating system that was quite clearly designed with virtualisation and the cloud in mind."
Or to put it another way. Server 2012, the NT kernel and explorer shell with a few more catchup services tacked on to appear "new" & relevant. Server 2012 is not amazing, it's just another iteration of windows server with the normal "everything moved about so you have learn how to do simple management tasks again and buy new copies all your expensive software that doesn't recognise the new version number."
"buy new copies all your expensive software that doesn't recognise the new version number."
In fairness, you can hardly blame Microsoft for that, unless the expensive software you refer to is Microsoft's.
Where I think Microsoft are taking the lead here is in working towards a single toolset that manages resources both in your own datacenter and in theirs, without having to make a context switch or think differently about how you do things, just enabling management of resources regardless of where they are and making their datacenters a natural extension of your own.
For Enterprises who want the flexibility of "Cloud" in their own datacenters and the flexibility to occasionally offload some work to Azure, this could be really quite useful.
I just wish the marketing bods had come up with a better more-specific term than "Cloud", the term has been so badly abused to include things that it isn't that it doesn't really mean anything any more, same as the HTML5 abuse.
The first hostage was the cloud itself
Re: don't allow your company to become a hostage
What the industry that has fought us every step of the way is trying to do is equivalent to designing proprietary networking protocols and locking us into them.
The 'cloud' goes back to the old concept of the X.25 cloud and what we meant when we drew a literal cloud between one system and another was that the cloud abstracted the connection so you neither knew nor cared where it was or how the data got back and forth. The details of transport and location were not relevant to the conversation.
As time went on, those of us making network drawings started to refer to the side of the cloud facing the client as if the cloud itself was an entity that contained the resources it delivered. It simplified the representation of designs to show only what the client saw as services provided by the cloud.
At this point in time, marketing people have begun to speak of the cloud as a thing unto itself -- as if the resources it delivers *are* the cloud. You have to 'get some cloud' now. Some who, like me, have been at this since the 1980s and earlier are starting to get a little antsy about this mutation of the concept. We have been 'moving' to the cloud forever, but it was not a marketing idea.
The movement 'to the cloud' has been underway for a long time. It is an inevitable logical next step as the global network acts less like a long haul communications line and more like a bus.
Companies like Microsoft are fighting like mad to make sure that you don't use the cloud to escape their proprietary infrastructure. Part of their strategy is to confuse the conversation. If people understood this better they would be insisting on vanilla standardized non-proprietary protocols to abstract Storage and CPU cycles so that it was easy to rent portions of their infrastructure as they needed them, without worrying about how that infrastructure was attached.
Ethernet, TCP/IP, and various RFC specs are what have created this rich ecosystem that makes talk about 'the cloud' as a provider of resources make sense. The moment someone starts talking about their proprietary cloud infrastructure you should be wary. Replacing X.25 with TCP/IP was the right thing to do. Enhancing TCP/IP to increase addressing ability makes sense. Replacing or encumbering TCP/IP with proprietary extensions and enforcing what can deliver services, not so much...
I would suggest there are two broad types of Cloud OS.
The first I think Dale Vile alludes to, namely the real-time, loosely-coupled, highly distributed, highly scalable OS that stitches all the compute nodes together. Any one who worked with Transputers and other massively parallel and/or distributed architectures would be familar with this style of OS kernel. By it's nature it sits below the hypervisor, although todate it has probably been bundled up with the hpyervisor.
The second, I think Cliff Evans alludes to, namely the OS that handles the emergent properties of the Cloud. Obviously to date much activity in this space has been devoted to cloud administration and management, but we can expect this to evolve to include services more directly relevant to applications and data.
At least as far as this article is concerned, two of the three folks participating are pitching Microsoft cloud. (I realize Trevor is independent since I have read some of his other posts but it should be more balanced).
Which is one reason I decided not to take El reg up on their offer to write articles here. I can have my own biases in my comments and blogs, but I feel a higher level of responsibility(whether it is expected or not) when participating in a more formal news article.
As it stands today "The Cloud OS" is pure PR fluff. It has been since VMware coined vSphere 4.0 back in 2009? 2008? I forget the first "Cloud OS" (predating Oracle's claim by years). Maybe there were others before it.
Making a cloud is possible, but I firmly believe most organizations can and do get fine with a slightly older paradigm(never thought i'd use that word). One that has gone out of style, one that really was never in style the way the cloud is - Utility computing. Where you can leverage the capacity of servers, storage and network to drive utilization up(thus significantly reducing real costs on said tier 1 infrastructure) and maintain high levels of availability (vmotion, storage vmotion (or their equivalents) - MAC address takeover for fast network fail over, etc). FAR less complexity -- a little more manual effort around the edges, and you retain the ability to maintain control - often times cloud systems remove capabilities in order to compromise in other areas.
My boss made an interesting comment to a group yesterday, he said we are working to double our VM capacity in our environment and we are doing this at a cost of 15% of the original purchase(never really thought of it in that angle), rather than doubling the cost. We aren't adding a single server to double this capacity either (thus no additional vSphere licenses).
"The concept of the cloud OS lashes together various technologies under a single banner in an attempt to drive people towards a subscription-based consumption model for their computing needs."
Great. But why does no one delve into latency? You've outsourced your IT and saved on costs. But what about the wider implications? I've asked before: It sure is an attractive idea to outsource menial daily maintenance and overall worry to Cloud providers. But I rarely glimpse any insight into the impact of latency? Can someone offer some real-world enlightenment? Do all companies take at least one critical app, port it to the cloud, and then do benchmarking before migrating?
Re: Cloud Latency...?
Interesting question. Can you expand on it? What are you precise concerns? I've not seen latency as an issue on anything I've tested or run in production...not even Lync! (Though, admittedly, Office 365's exchange/HTTPS mail does get crappy as hell if you are on a thready wireless connection in the third world...but Outlook does do caching...)
Re: Cloud Latency...?
I think AC was referring to real enterprise applications eg. Olympic results systems, airline reservations, etc. where the user interface doesn't need to be particularly fast, the backend has a lot of processing and co-ordination to do. Be interested in seeing a 'real' telco backend being put into the public cloud ...
'Interesting question. Can you expand on it?'
As OP please note I don't work in the Cloud, but I'm following the trend and wondering what I need to learn. There's lots of pro-Cloud articles on the Reg on a weekly basis. But few have practical specific examples of migration, and even fewer case studies in the comments. I'd like to get some feedback from people working in this area at the heart of user migration. Take three hypothetical case studies:-
#1. O365 User migration: How are users finding O365 migration from an overall network latency aspect? i.e. How is user experience varying from opening spreadsheets in the cloud versus locally? In addition, what about formatting differences, complexity of linked spreadsheets, VBA macro limits etc? How is that affecting usability? Its impossible to gauge the success of O365 in the real world as the license figures are a joke. How are users responding that's what I am being asked by decision makers.... In a sense I need 'Amazon.com' reviews for business users...
#2. Business migration: A Sales team has their in-house CRM or similar migrated to the Cloud. Lets assume the In-house app had solid response times before. What kind of latency can the users now expect to have to deal with by running Cloud versions of their apps? In general, how does the migration planning process work? Does a Cloud provider offer a customized CRM as a test-bed? Then if decision makers approve, one entire app is fully migrated and tested. If the customer is still happy then further migration can take place. but how is all this panning out? Because the $ costs are dominating the discussion over any user experience costs.
#3. General question. When articles cover the Cloud they often cover cost, hosting and server virtualisation details. But I would like to know which apps or business lines are best suited to Cloud migration? Lets ignore security and privacy concerns for the moment. Functionally, which businesses migrate to the cloud easier? i.e. Which can deal better with network outages or sluggish network latency without it killing the entire business... And which types of functionality or applications migrate to the Cloud the fastest apart from CRM?
Re: 'Interesting question. Can you expand on it?'
RE: #1 nobody uses the web apps unless forced to. That means that all e-mails are downloaded locally and cached on the local Outlook. They use local copies of Office. That makes it work as fast as an exchange server, excepting for Very Large Files which are attached and aren't cached. These down have to download when you open them, but I have not heard a single complaint from my Office 365/MS Office customers or my Google Apps/Thunderbird/LibreOffice customers.
RE: #2 cloud provider will generally offer a testbed platform for CRM alongside the production version. The migration process is a bitch and a half, but this is no different than migration from any installed CRM to a new installed CRM. Latency is generally improved in cloudy versions because the cloudy infrastructure is almost always faster and better maintained than internal stuff. Costs only make sense if you fire a bunch of nerds and factor that in. Otherwise, cloud is always more expensive.
RE: #3 I have e-mailed myself that question so I can go hit it with a hammer. I'll make you a complete article on that, fair enough?
Re: 'Interesting question. Can you expand on it?'
Good man Trevor. Your O365 is enlightening. Thanks!
Re: 'Interesting question. Can you expand on it?'
Re: Which can deal better with network outages
We were discussing this the other day, since we have a little bit of our stuff 'on the cloud' and are talking about greater migration.
The observation that we have is that for people like us (developers or techie managers and friends), a downed network connection blows us out of the water anyway. We are online all day. A couple of years ago I shifted my primary working environments to virtual machines. I almost always use stuff like RDP to log into a system other than the workstation I am at.
For someone who requires internet access for their work anyway, movement to the cloud should be easy. But...
1) Moving infrastructure to the cloud is still too expensive for most things. This will change, but so far it seems true.
2) For medium sized offices with 20 to 50 employees sharing and Internet connection, they will have to beef up their 'connection to the switch'. A 5mbps connection will fall apart with that many people actively working across it.
3) Latency *does* become a killer after a while. Latency < 10 locally, 10 or 20 to the backbone, 40 or 50 to a regional server is fine. At 100ms drilling into a large remote data center you might start to notice and beyond that it could become a problem.
- Crawling from the Wreckage Want a more fuel efficient car? Then redesign it – here's how
- Review Xperia Z3: Crikey, Sony – ANOTHER flagship phondleslab?
- Human spaceships dodge ALIEN BODY skimming Mars
- Ex-US Navy fighter pilot MIT prof: Drones beat humans - I should know
- Downrange Are you a gun owner? Let us in OR ELSE, say Blighty's top cops