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.
Bad Premise: Cloud Outages are *not* driving IT back to premises June 14, 2011
Posted by Rob H in Amazon, Architecture, CAP Theorem, Economics, Open Trends.Tags: Architecture, CAP, Elastic, Outage, SLA
1 comment so far
I wrote this responding to Lauren Carlson‘s (Software Advice) Blog Post. Lauren – I’d be more likely to agree with the statement that “SLAs are dead” Here’s why…
<soapbox>
Recent industry buzz about cloud service level agreements (SLAs) and reliability miss the core point about cloud. Cloud is about agility, business models, consumerization of software and merciless pursuit of efficiency.
The fact that Amazon EC2 built its base without an “enterprise” SLA is exhibit #1 that the IT world changed and it’s not going back.
Here are my reasons why IT pandoras can’t get cloud back into the box.
#1. Cloud has vastly superior network connectivity
The concept of your users accessing your applications from inside your firewall is so 2005. Today’s reality is that significant amounts of network access is externally routed means that applications need to live where they have excellent bandwidth to their users and to other applications.
#2. Cloud has elastic consumption of resources
Cloud is not less expensive infrastructure, it is mainly more flexible. If you’re worried about an outage, then cloud is exactly the investment for you because you position a backup site at another location without having to pay for online resources. It’s much harder to take down a site that invests the time to design a system that dynamically reallocates load between sites.
#3. Cloud drives more robust architecture
The fact that cloud delivery is more opaque and modular without a five 9s SLA has driven a cloud application architecture revolution (see CAP). We have shifted the app paradigm from robust scale up hardware to robust scale out software. Also significant, DevOps innovations have made deployments repeatable and adaptable.
The only “logical” argument for pulling applications back from the cloud is to assert control over more of the delivery chain for your application. It the same reason that we think that driving is safer than flying – we’re the ones sitting behind the wheel when we drive. News flash - driving is NOT safer than flying.
Cloud applications are not about hardware infrastructure, they are about SOFTWARE. Perhaps one of the greatest disservices foisted on the market was saying cloud is synonymous with “Infrastructure as a Service” and ”Virtualization.” Cloud applications are powerful because we created ways that circumvent the limitations of IaaS and VMs!
</soapbox>
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!
