2012: A year of Cloud Coalescence (whatever that means) January 5, 2012
Posted by Rob H in Clouds, Hadoop, Linux, Open source, OpenStack.Tags: 2012, DevOps, hadoop, OpenStack, PaaS, quantum
1 comment so far
This post is a collaboration between three Dell Cloud activists: Rob Hirschfeld (@zehicle), Joseph B George (@jbgeorge) and Stephen Spector (@SpectoratDell).
We’re not making predictions for the “whole” Cloud market, this is a relatively narrow perspective based on technologies that on our daily radar. These views are strictly our own and based on publicly available data. They do not reflect plans, commitments, or internal data from our
employer (Dell).
The major 2012 theme is cloud coalescence. However, Rob worries that we’ll see slower adoption due to lack of engineers and confusing names/concepts.
Here are our twelve items for 2012:
- Open source continues to be a disruptive technology delivery model. It’s not “free” software – there’s an emerging IT culture that is doing business differently, including a number of large enterprises. The stable of sleeping giant vendors are waking up to this in 2012 but full engagement will take time.
- Linux. It is the cloud operating system and had a great 2012. It seems silly pointing this out since it seems obvious, but it’s the foundation for open source acceleration.
- Tight market for engineering and product development talent will get tighter. The catch-22 of this is that potential mentors are busy breaking new ground and writing code, making it hard for new experts to be developed.
- On track, OpenStack moves into its awkward adolescence. It is still gangly and rebelling against authority, but coming into its own. Expect to see a groundswell of installations and an expected wave of issues and challenges that will drive the community. By the “F” release, expect to see OpenStack cement itself as a serious, stable contender with notable public deployments and a significant international private deployment foot print.
- We’ll start seeing OpenStack Quantum (networking) in near-production pilots by year end. OpenStack Quantum is the glue that holds the big players in OpenStack Nova together. The potential for next generation cloud networking based on open standards is huge, but it will emerge without a killer app (OpenStack Nova in this case) pushing it forward. The OpenStack community will pull together to keep Quantum on track.
- Hadoop will cross into mainstream awareness as the need for big data analysis grows exponentially along with the data. Hadoop is on fire in select circles and completely obscure in others. The challenge for Hadoop is there are not enough engineers who know how to operate it. We suspect that lack of expertise will throttle demand until we get more proprietary tools to simplify analysis. We also predict a lot of very rich entrepreneurs and VCs emerging from this market segment.
- DevOps will enter mainstream IT discussions. Marketers from major IT brands will struggle and fail to find a better name for the movement. Our prediction is that by 2015, it will just be the way that “IT” is done and the name won’t matter.
- KVM continues to gain believers as the open source hypervisor. In 2011, I would not have believed this prediction but KVM making great strides and getting a lot of love from the OpenStack community, though Xen is also a key open source technology as well. I believe that Libvirt compatibility between LXE & KVM will further accelerate both virtualization approaches.
Big Data and NoSQL will continue to converge. While NoSQL enthusiasm as a universal replacement for structured databases appears to be deflating, real applications will win.- Java will continue to encounter turbulence as a software platform under Oracle’s overly heady handed management.
- PaaS continues to be a confusing term. Cloud players will struggle with a definition but I don’t think a common definition will surface in 2012. I think the big news will be convergence between DevOps and PaaS; however, that will be under the radar since most of the market is still getting educated on both of those concepts.
- Hybrid cloud will continue to make strides but will not truly emerge in 2012 – we’ll try to develop this technology, and expose gaps that will get us there ultimately (see PaaS and Quantum above)
Thoughts? We’d love to hear your comments.
Rob, JBG, and Stephen
You can follow Rob at www.RobHirschfeld.com or @zehicle on Twitter.
You can follow Joseph at www.JBGeorge.net or @jbgeorge on Twitter.
You can follow Stephen at http://en.community.dell.com/members/dell_2d00_stephen-sp/blogs/default.aspx or @SpectoratDell on Twitter.
The 451 Group Cloudscape report strikes chord misses harmony (DevOps, Hybrid Cloud, Orchestration) November 2, 2011
Posted by Rob H in Architecture, Clouds, Dave McCrory, DevOps.Tags: 451, applications, Architecture, cloud, DevOps, hybrid, networking, orchestration, ProTier, Storage
3 comments
It’s impossible to resist posting about this month’s 451 Group Cloudscape report when it calls me out by name as a leading cloud innovator:
… ProTier founders Dave McCrory and Rob Hirschfeld. ProTier [note: now part of Quest] was, indeed, the first VMware ecosystem vendor to be tracked by The 451 Group. In the face of a skeptical world, these entrepreneurs argued that virtualization needed automation in order to realize its full potential, and that the test lab was the low-hanging fruit. Subsequent events have more than vindicated their view (pg. 33).
It’s even better when the report is worth reading and offers insights into forces shaping the industry. It’s nice to be “more than vindicated” on an amazing journey we started over 10 years ago!
Rather than recite 451′s points (hybrid cloud = automation + orchestration + devops + pixie dust), I’d rather look at the problem different way as a counterpoint.
The problem is “how do we deal with applications that are scattered over multiple data centers?”
I do not think orchestration is the complete answer. Current orchestration is too focused on moving around virtual machines (aka workloads).
Ultimately, the solution lies in application architecture; however, I feel that is also a misdirection because cloud is redefining what an “application architecture” means.
Applications are a dynamic mix of compute, storage, and connectivity.
We’re entering an age when all of these ingredients will be delivered as elastic services that will be managed by the applications themselves. The concept of self management is an extension of DevOps principles that fuse application function and deployment. There are missing pieces, but I’m seeing the innovation moving to fill those gaps.
If you want to see the future of cloud applications then look at the network and storage services that are emerging. They will tell you more about the future than orchestration.
Substituting Action for Knowledge – adopting “ready, fire, aim” as a strategy (and when to run like hell) March 28, 2011
Posted by Rob H in Agile, DevOps, Lean, Open Trends.Tags: Agile, antidepressants, cloud, DevOps, Lean, operational model, operations, roadmap
1 comment so far
Today my mother-in-law (a practicing psychiatrist) was bemoaning the current medical practice of substituting action for knowledge. In her world, many doctors will make rapid changes to their patients’ therapy. Their goal is to address the issues immediately presented (patient feels sad so Dr prescribes antidepressants) rather than taking time to understand the patients’ history or make changes incrementally and measure impacts. It feels like another example of our cultural compulsion to fix problems as quickly as possible.
Her comments made me question the core way that I evangelize!
Do Lean and Agile substitute action for knowledge? No. We use action to acquire knowledge.
The fundamental assumption that drives poor decision-making is that we have enough information to make a design, solve a problem or define a market. Lean and Agile’s more core tenet is that we must attack this assumption. We must assume that we can’t gather enough information to fully define our objective. The good news, is that even without much analysis we know a lot! We know:
- roughly what we want to do (road map)
- the first steps we should take (tactics)
- who will be working on the problem (team members)
- generally how much effort it will take (time & team size)
- who has the problem that we are trying to solve (market)
We also know that we’ll learn a lot more as we get closer to our target. Every delay in starting effectively pushed our “day of clarity” further into the future. For that reason, it is essential that we build a process that constantly reviews and adjusts its targets.
We need to build a process that acquires knowledge as progress is made and makes rapid progress.
In Agile, we translate this need into the decorations of our process: reviews for learning, retrospectives for adjustments, planning for taking action and short iterations to drive the feedback loop. Agile’s mantra is “ready, fire, aim, fire, aim, fire, aim, …” which is very different from simply jumping out of a plane without a parachute and hoping you’ll find a haystack to land in.
For cloud deployments, this means building operational knowledge in stages. Technology is simply evolving too quickly and best practices too slowly for anyone to wait for a packaged solution to solve all their cloud infrastructure problems. We tried this and it does not work: clouds are a mixture hardware, software and operations. More accurately, clouds are an operational model supported by hardware and software.
Currently, 80% of cloud deployment effort is operations (or “DevOps“).
When I listen to people’s plans about building product or deploying cloud, I get very skeptical when they take a lot of time to aim at objects far off on the horizon. Perhaps they are worried that they will substitute action for knowledge; however, I think they would be better served to test their knowledge with a little action.
My MIL agrees – she sees her patients frequently and makes small adjustments to their treatment as needed. Wow, that’s an Rx for Agile!
DevOps: There’s a new sheriff in Cloudville September 9, 2010
Posted by Rob H in Clouds, Hiring.Tags: Architecture, cloud, DevOps, RAIN
8 comments
Lately there’s a flurry of interest (and hiring demand) for DevOps gurus. It’s obvious to me that there’s as much agreement between the ethical use of ground unicorn horn as there is about the job description of a DevOps tech.
I look at the world very simply:
- Developers = generate revenue
- Ops = control expenses
- DevOps = write code, setup infrastructure, ??? IDK!
Before I risk my supply of ethically obtained unicorn powder by defining DevOps, I want to explore why DevOps is suddenly hot. With cloud driving horizontal scale applications (see RAIN posts), there’s been a sea change in the type of expertise needed to manage an application.
Stereotypically, Ops teams get code over the transom from Dev teams. They have the job of turning the code into a smoothly running application. That requires rigid controls and safe guards. Traditionally, Ops could manage most of the scale and security aspects of an application with traditional scale-up, reliability, and network security practices. These practices naturally created some IT expense and policy rigidity; however, that’s what it takes to keep the lights on with 5 nines (or 5 nyets if you’re an IT customer).
Stereotypically, Dev teams live a carpe diem struggle to turn their latest code into deployed product with the least delay. They have the job of capturing mercurial customer value by changing applications rapidly. Traditionally, they have assumed that problems like scale, reliability, and security could be added after the fact or fixed as they are discovered. These practices naturally created a need to constantly evolve.
In the go-go cloud world, Dev teams are by-passing Ops by getting infrastructure directly from an IaaS provider. Meanwhile, IaaS does not provide Ops the tools, access, and controls that they have traditionally relied on for control and management. Consequently, Dev teams have found themselves having to stage, manage and deploy applications with little expertise in operations. Further, Ops teams have found themselves handed running cloud applications that they have to secure, scale and maintain applications without the tools they have historically relied on.
DevOps has emerged as the way to fill that gap. The DevOps hero is comfortable flying blind on an outsourced virtualized cloud, dealing with Ops issues to tighten controls and talking shop with Dev to make needed changes to architecture. It’s a very difficult job because of the scope of skills and the utter lack of proven best practices.
So what is a day in the life of a DevOp? Here’s my list:
- Design and deploy scale out architecture
- Identify and solve performance bottlenecks
- Interact with developers to leverage cloud services
- Interact with operations to integrate with enterprise services
- Audit and secure applications
- Manage application footprint based on scale
- Automate actions on managed infrastructure
This job is so difficult that I think the market cannot supply the needed experts. That deficit is becoming a forcing function where the cloud industry is being driven to adopt technologies and architectures that reduce the dependence for DevOps skills. Now, that’s the topic for a future post!


We’ve been so busy working on getting