Let’s face it, we live in an on-demand economy. As consumers, we expect instant gratification – whether booking a plane ticket online or downloading an app. And now that need for speed applies to IT infrastructure.
It’s what makes public cloud computing so compelling: users want self-service and IT resources delivered within minutes. But the legacy infrastructure and management systems in most internal IT departments weren’t designed for this new on-demand operating model.
If you’ve ever played Jenga, you know what happens when you remove the wrong block too quickly; it falls apart. That same complexity and fragility slows down most IT teams and their existing infrastructure: they have dozens of systems that don’t necessarily work all that well together. And when users request IT infrastructure resources, the end-to-end cycle time often takes several weeks.
Workload Automation is the triggered or scheduled activities that drive batch and real-time business process automation moving data across an ecosystem of applications and compute environments. This is mission critical “back office” IT business data process capability. I introduced Workload Automation in a previous blog, http://blogs.cisco.com/datacenter/workload-automation-job-scheduling-applications-and-the-move-to-cloud/. We have customers who use the Cisco Tidal Enterprise Scheduler to perform the most critical activities in their enterprise. Many of the health care providers, insurance companies, manufacturing giants, and financial service outfits rely on these technologies to drive their business.
We recently made generally available our workhorse release of the Cisco Tidal Enterprise Scheduler for the next few years.
A powerful global change has begun. Through cloud services and automation, people are discovering and inventing new ways to deliver IT services with blinding speed. As a direct result, IT Operations are changing — and those that adopt a pragmatic cloud are creating competitive differentiation for their business faster than most companies.
But there are many stones on the road to Damascus on which to stub you toes.
Some IT shops moving to a cloud are not yet ready to take ownership of that Private or Hybrid Cloud deployment or to change their operations. These shops will not be successful.
Some expect their vendor to build it and own it. Other shops are relying on third parties. This will work at first but it will quickly get too expensive.
Finally, some of the visionaries want to own it themselves but don’t know where to start. These organizations need to build a maturity roadmap that gets them started quickly and easily so they can learn what works and what needs improvement.
We have worked with a large number of organizations. This has given us perspective on the 12 habits of successful cloud implementations. Here they are.
12 Habits of Successful Cloud Builders:
1. They invest in training from their cloud automation software provider so that they can take ownership of and drive the technical work.
2. Cloud builders are indeed that, their goal is to build: over time they rely less on vendors and third party services to build their cloud; they have a plan for that transition.
3. Moving to cloud requires new roles. Builders define new roles in their organizations to take into account the new skills and competencies needed. They think through career implications and pathways. Read More »
Today’s announcement that Citrix is dropping support for OpenStack has reverberated through the clouderati sphere like a new Justin Bieber song through my niece’s third grade class. Super important but will not matter much when the next idol arrives.
In any case, a lot of smart people have written about it. I’ll leave them to explain the whole thing.
But the post that most caught my attention came from Thorsten at Rightscale‘s. We both share something in common: we both build products that connect to cloud API’s. Including vendor who have API’s that claim to be compatible EC2. This experience, I think provides a useful point of view when thinking about API compatibility. Not to mention it creates a jaundiced view of the human soul.
Thorsten writes.
I’ve said it many times and I’ll repeat it again: it’s the semantics of the resources in the cloud that matter, not the syntax of the API. This means that “API compatibility” has to reach very, very deep to be meaningful. Let me give you a couple of examples around EC2.
Some people say that in the next few years that Infrastructure as a Service cloud deployments will be focused mostly on private clouds. And then they say that enterprises will migrate to public clouds after they have become “experienced” in running a cloud. About a year ago I could really see this story played out. Now, fifteen months after we introduced Cisco Intelligent Automation for Cloud, I have some different points of view. I would have thought that by now that private cloud architectures would have begun to converge to a few standard patterns. This has not happened. The world is still diverging when it comes to both Private and Public cloud architectures.
I do see patterns arising in successful cloud deployments and here are some of the key ones:
#5: Pragmatic Approach: IT shops that come with a long list of RFP requirements and questions take a long time to source a technology provider and to achieve production success. Others that are pragmatic (can I say Agile in their approach) get to cloud quicker and learn from their successes and missteps alike.
#4: They Have a Cloud Instance Roadmap: After a cloud deployment, some IT organizations think that is it, they are done, next project, my move to cloud is complete. Hold it right there, did you know that cloud is not a single step where you through a switch, but a succession of deployments of great scope from one step to the next? A roadmap is needed that covers: hardware, network, storage infrastructure, virtualization technology and release version, management and orchestration software instance version and finally the services that you are offering to the end users and how the service catalog is changing over time. Those that have a roadmap roughed out are generally more successful than those that have a big bang perspective.
#3: Appreciation for Challenge of Management of Change:Moving to cloud is a big change in an operating model; careers are created and new roles are defined. How does an organization move to the new model with different technology, processes and people? When a team proactively manages the change in the non-technical they ensure long term success. It is not just about self service, cloud catalogs, orchestration, domain management and virtualization. It is more about service designers and automation authors and changes in operational processes.
#2: Rise of the Cloud Architect: Since cloud is about a new operating model a new position and role is needed. If you have a cloud project and do not have a cloud architect tying it all together from cost models, to hypervisors, to orchestration and orderable service definitions, you need a organization role tune up ASAP.
#1: A Service Centric Approach: Most people get this one right away. Service centric projects are the key focus for ITaaS. However, I can’t tell you how many times when I am talking to an IT team, the opening bell results in a speeds and feeds conversation around provisioning that piece of infrastructure and that virtualization API. If you ask the question about what services they want to offer their end users for self service ordering you will get a request for more time to answer that question. Service Centric IT shops will take the time to start first with the business requirements and the perspective from the end user point of view. Transform your cloud project approach to a service centric agile project and you will go far.
