When you start to look at what it means to automate and orchestrate a process such as the one mentioned above, you will start to see what I mean by “what you think you’re doing is less than half of what you’re really doing.” Hmm, that may be more confusing than explanatory so let me reset by first explaining the generalized process for turning a series of commodity IT activities into a workflow and by turn, an orchestration and then I think you’ll better see what I mean. We’ll use the example from above as the basis for the illustration.

The first and foremost thing you need to do before you create any workflow (and orchestration) is that you have to pick a reasonably encapsulated process to model and transform (this is where you will find the complexity that you don’t know about…more on that in a bit). What I mean by “reasonably encapsulated” is that there are literally thousands of processes, dependent and independent, going on in your environment right now and based on how you describe them, a single process could be either A) a very large collection of very short process steps, or, Z) a very small collection of very large process steps (and all letters in between). A reasonably encapsulated process is somewhere on the A side of the spectrum but not so far over that there is little to no recognizable business benefit resulting from it.

So, once you’ve picked the process that you want to model (in the world of automation, modeling is what you do before you get to do anything useful ) you then need to analyze all of the processes steps required to get you from “not done” to “done”…and this is where you will find the complexity you didn’t know existed. From our example above I can dive into the physical process steps (hundreds, by the way) that you’re well aware of, but you already know those so it makes no sense to. Instead, I’ll highlight some areas of the process that you might not have thought about.

Aside from the SOPs, the run books and build plans you have for the various IT assets you employ in your environment, there is probably twice that much “required” information that resides in places not easily reached by a systematic search of your various repositories. Those information sources and locations are called “people,” and they likely hold over half of the required information for building out the assets you use, in our example, the composite application. Automating the process steps that are manifested in those locations only is problematic (to say the least), if not for the fact that we haven’t quite solved the direct computer-to-brain interface, but for the fact that it is difficult to get an answer to a question we don’t yet know how to ask.

Well, I should amend that to say “we don’t yet know how to ask efficiently” because we do ask similar questions all the time, but in most cases without context, so the people being asked seldom can answer, at least not completely. If you ask someone how they do their job, or even a small portion of their job, you will likely get a blank stare for a while before they start in how they arrive at 8:45 AM and get a cup of coffee before they start looking at email…well you get the picture. Without context, people rarely can give an answer because they have far too many variables to sort through (what they think you’re asking, what they want you to be asking, why you are asking, who you are, what that blonde in accounting is doing Friday…) before they can even start answering. Now if you give someone a listing or scenario in which they can relate (when do you commission this type of composite application, based on this list of system activities and tools?) they can absolutely tell you what they do and don’t do from the list.

So context is key to efficiently gaining the right amount of information that is related to the subject chain of activities that you are endeavoring to model- but what happens when (and this actually applies to most cases) there is no ready context in which to frame the question? Well, it is then called observation, either self or external, where all process steps are documented and compiled. Obviously this is labor intensive and time inefficient, but unfortunately it is the reality because probably less than 50% of systems are documented or have recorded procedures for how they are defined, created, managed and operated…instead relying on institutional knowledge and processes passed from person to person.

The process steps in your people’s heads, the ones that you don’t know about—the ones that you can’t get from a system search of your repositories—are the ones that will take most of the time documenting, which is my point, (“what you think you’re doing is less than half of what you’re really doing”) and where a lot of your automation and orchestration efforts will be focused, at least initially.

That’s not to say that you shouldn’t automate and orchestrate your environment—you absolutely should—just that you need to be aware that this is the reality and you need to plan for it and not get discouraged on your journey to the cloud.

By Rick Blaisdell; CTO ConnectEDU

Cloud computing has definitely revolutionised the IT industry and transformed the way in which IT Services are delivered. But finding the best way for an organization to perform common management tasks using remote services on the Internet is not that easy.

Cloud management incorporates the task of providing, managing, and monitoring applications into cloud infrastructures that do not require end-user knowledge of the physical location or of the system that delivers the services. Monitoring cloud computing applications and activity into requires cloud management tools to ensure that resources are meeting SLA’s, working optimally and also not effecting systems and users that are leveraging these services.

With appropriate cloud management solutions, private users are now able to manage multiple operating systems on the same dedicated server or move the virtual servers to a shared server all from in the same cloud management solution.  Some cloud companies offer tools to manage this entire process, some will provide this solution using a combination of tools and managed services.

The three core components of cloud environment, Infrastructure as a Service (IaaS), Platform as a Service (PaaS) and finally Software as a Service (SaaS), now offer great solutions to manage cloud computing, but the management tools need to be flexible and scalable just as the cloud computing strategy of an organization should be. With the new paradigm of computing, cloud management has to:

• continue to make cloud easier to use;
• provide security policies for the cloud environment;
• allow safe cloud operations and ease migrations;
• provide for financial controls and tracking;
• audit and reporting for compliance.

Numerous tasks and tools are necessary for cloud management. A successful cloud management strategy includes performance monitoring in terms of response times, latency, uptime and so on, security and compliance auditing and management, initiating, supervising and management of disaster recovery.

So, why is it so important to implement a cloud management strategy into an organization? By having a cloud management strategy that fits into the cloud computing resources that a company uses, it offers a faster delivery of IT services to businesses, it reduces capital and operating costs, it charges backs automatically for resource usage and reporting and it allows IT departments to monitor their service level requirements.

This post originally appeared on http://www.rickscloud.com/cloud-management/

A common scenario is that people feel that there is no need to involve the security folks until after the team has come up with a solution.  Then the team pulls in the security or compliance folks to validate that the solution doesn’t go afoul of the organization’s security or compliance standards. Instead of a team member who can help with the security and compliance aspects of your project, you have ended up with an umpire.

Now think back to when you were a kid picking teams to play baseball.  If you had an odd number of kids then more than likely there would be one person left who would end up being the umpire. When you bring in the security or compliance team member late in the game, you may end up with someone that takes on the role of calling balls and strikes instead of being a contributing member of the team.

Avoid this situation by involving your Security and Compliance staff early on, when the team is being assembled.  Your security SMEs should be part of these conversations.  They should know the business and what the business requirements are.  They should be involved in the development of solutions.  They should know how to work within a team through the whole project lifecycle. Working this way ensures that the security SME has full context and is a respected member of the team, not a security umpire.

This is even more important when the initiative is related to virtualization or cloud. There are so many new things happening in this specific area that everyone on the team needs as much context, background, and lead time as possible so that they can work as a team to come up with solutions that make sense for the business.

www.youtube.com/watch?v=maFiFYDW0bo

Few of our clients understand the difference between operating a cloud infrastructure and operating a traditional datacenter, but it’s not that they’re dumb; it’s just that the whole idea of cloud is new and different. There aren’t a lot of fully functioning cloud infrastructures out there so, obviously, there’s not a lot of personnel experienced running those infrastructures. With this post I want to explain what it means to run a cloud infrastructure and by that I mean I will explain the difference between what you know now versus what you need to know—and change—later, when you’re faced with operating one of those beasts.

The first thing you have to do is basically unlearn everything you know about operating your datacenter…ha ha, OK, not exactly everything, but there’s a lot that goes on in your datacenter now that is irrelevant and inadequate for operating a cloud infrastructure.  The whole idea of people doing “stuff” (i.e. provisioning servers, configuring switches, carving up storage, etc.) has to be completely rethought because in a cloud infrastructure, you rely on the systems for doing those things.  In a cloud infrastructure, you are basically decoupling the business benefit of your compute assets (storage, servers, networks, etc.) from the management and operation of those assets so that you can individually optimize each.  You have the freedom to focus on the business aspects versus the technology or, vice versa, the technology over the business aspects.

How this is done is by the extensive use of automation and orchestration of commodity IT functions (i.e. The “stuff” mentioned above) directly integrated to change and configuration management systems that are governed by rules and policies set by you and the business.  The face of these aggregated systems, the cloud infrastructure, is a self-service portal with a catalog of options that you allow users to choose from (based on their role and responsibility within the organization).  You can also see, from a single pane of glass (i.e. a dedicated program or web page), the entire operation of the infrastructure including performance metrics, problem areas and alerts, usage and utilization as well as the ongoing costs of all of the services being delivered…

…and that’s the point right there: once you decouple the business benefit from the operation and management of your technology, you are essentially delivering IT services to the business in the form of well-defined business benefits.  An example of a business benefit is the delivery of a set of provisioned servers (database, app and web servers), in a very specific configuration, with an explicit set of software development tools installed with a certain amount of dedicated storage and network bandwidth…all at the simple and direct request of a user, without involving IT personnel.  And…maybe 90 days later…the user is emailed a request to verify that the server is still in use and, if not, permission to decommission it and return all of the resources it was using back to the specific pools of resources where they came from.

Yes, it is that simple but, creating, managing and ultimately delivering that type of capability isn’t easy at all, it takes a lot of upfront work to get right which is why you have to stop thinking about your datacenter the way you do now and start thinking about being a service provider.  The basic process is that you need to look at the things your business (your consumers) want to buy from you (more on that in a bit); analyze all of the many processes, the people involved and the tools and resources you will use to provide that thing; translate all of that into an automated process (a workflow) that will be carried out by your systems (and test and QA those workflows); and then add that menu item to the list on the self-service portal that you present to your “consumers” who can then use that process over and over again.  And, with respect to your consumers buying from you, because you have direct visibility into all of the various processes involved and completely understand the usage and utilization of all of the supporting resources—CPU, memory, storage, networks, licenses, etc.-you can associate a cost to every service you deliver…both the start-up and the ongoing monthly costs…very easily.

As you can see, this is much, much different than filling out that form for requesting hardware from management; waiting for approval; sending hardware specifications to procurement; waiting for approval; waiting several weeks to several months for delivery; racking and stacking the hardware; waiting for approval from Security to plug into the network; plugging into various switches and networks; using many different interfaces (to storage, to core switching, to virtual infrastructure, etc.) to configure the hardware; using another completely different set of interfaces to load system images, software stacks, etc.; and following various procedures found in different places managed by different divisions.  And, after all that work, you only know what the hardware and labor originally cost to buy and setup; you have few options for figuring out what a monthly cost might be (so you don’t bother) so your consumers never know the true cost and subsequently over-provision.

So, as you can hopefully see, the systems that have grown up around, and been optimized for, managing the processes used in traditional datacenters (as just noted) are completely inadequate for managing the processes used in a cloud infrastructure because you are delivering IT services which have distinct and explicit requirements that just do not exist in current systems.

Starting with an on-premises private cloud of your own seems like a sensible choice. A cloud environment of your own, that you can keep cool and dry inside of your own datacenter. Architects can design and build it with the components of their choice, management can have the control that they’re used to, and administrators can manage it alongside every other system. Security issues can be handled deftly by your consultant or cloud-champion – after all, your cloud is internal and private!

Another perspective is to skip out on a cloud strategy, forgo some early benefits, and wait for all of the chips to fall before making any investments. This is the respectable “do nothing” alternative, and it’s a valid one.

Yet another perspective is to take a close look at cloud concepts and prepare your company to act, when appropriate. Prepare, act, appropriate time. Sounds like a strategy brewing.

What Is Cloud Anyway? C’mon, What Are the Real Benefits?

What are the benefits? We should define benefits in terms of increased revenue or reduced costs for the organization overall. “Better manageability” alone is not a benefit. “Better manageability” is a benefit in that it leads to reduced costs in the form of fewer people, if the manageability truly is better. How about improved time to market? Isn’t that a benefit? Sure, only insofar as it leads to the deployment of revenue-generating or cost-reducing applications to production sooner than before. Nearly all of the benefits of using cloud computing are associated with reduced operating expense.

The careful reader will recognize some of these characteristics as consistent with the NIST definition. Here it goes, a cloud is…

Neat Abstraction: abstract requirements (or requests) from specifications. This allows IT departments the freedom (technical, of course) to deploy workloads on the most efficient platform available, whether it is internal private cloud, external SaaS, etc. This characteristic enables a catalog of pre-engineered offerings.

Flexible Capacity: Administrators should be able to add or remove capacity from the cloud system without impacting the performance of other workloads running there. Administrators should also be able to adjust capacity on an individual workload without impacting the performance of other workloads. Benefit? Avoid unnecessary infrastructure purchases and reclaim unused capacity.

Workload Portability: Workloads should be packaged so that they can be moved to a different infrastructure without impacting performance. Under the VMware vSphere platform, VMotion achieves this within their system. I think that, eventually, workloads will be portable, even to different providers. Even then, you may not want to separate the workload – e.g. you may not want to separate the application layer and the persistence layer of your application. Benefit? Deploy workloads to the most efficient platform that satisfies requirements (see Neat Abstraction above). This is a key characteristic as the market for cloud computing changes almost every day– new providers enter the market, existing providers exit the market, and prices change.

Consistent Access: Application functionality should be similar across platforms – be it a web browser, “fat client,” mobile device, whatever.
Additionally, this means that workloads can be provisioned in the same way, regardless of the target platform. This is a key characteristic that enables the “brokering” of IT services.

Self-service? (Maybe): I don’t think that cloud is needed to provide this, or that self-service is needed to provide cloud computing. But it’s commonly in the conversation. What is the benefit? Improved time-to-market by cutting out the “middle man” in IT that designs infrastructure based on customer requirements.

Resilient and Redundant? (Maybe): Same treatment as with self-service. It’s commonly in the discussion.

Most Organizations are Using Cloud Today

Does your company use Salesforce.com for CRM? How about ADP for payroll or time entry? And I bet your company sources travel and expense systems to some outside provider. Why do most organizations outsource payroll or travel/expense IT Services? Because they’re commodity systems. (Note that payroll data is pretty sensitive – with employee SSNs, bank account information, compensation information, etc.)
Which other IT Services in your organization are commodity? Also note about these already-outsourced systems… they’re entire IT Services. Not just applications. And they take on the characteristics of cloud.

Service Management: You Knew This Was Coming

You knew you were going to have to get around to IT Service Management someday. Some vendor has been talking to you about the importance of that CMDB for at least the last decade. Here’s why all of this ITIL stuff is important. You need Service Management to measure the benefits of using cloud computing ;for example, is your organization able to improve time to market consistently? By how much? Some sort of request fulfillment process is needed to understand time-to-market in a quantitative way. Consider this:

1. You need IT service management to build a cloud

a. Service Catalog Management, as a process, is needed to ensure that self-service offerings are relevant

b. Capacity Management is needed to ensure that the relevant offerings in your catalog are delivered in timely fashion

c. Configuration Management and a CMDB is needed on a few different levels…to support other processes like capacity management but also to understand the infrastructure that supports an application so that you can outsource it once that makes sense for your organization

2. Your organization needs IT service management to understand the benefits of cloud computing

a. See above discussion on improved time to market; your organization needs to first measure time to market and then track it to show improvement; integration with fanancial management would be nice to quantify the benefit in dollar terms

3. Investing in IT service management is a “middle way” to prepare your organization to take advantage of cloud computing without choosing a cloud product, vendor, or even a strategy

4. Investments in improving IT service management will not be lost if you ultimately decide that cloud computing is not a good match for your business

Food for Thought

I hope that this post inspired some ideas about how your organization might make use of cloud computing. Here are some closing thoughts to consider:

1. Does your organization make use of any outside “cloud” services today?
2. Which applications running inside of your organization are both stable and commodity?
3. When was your most recent investment in IT service management? Were the benefits measurable?

I’d be interested in hearing some feedback on this.

Well this same thing applies today in IT. The point is to plan properly or you will end up buying more wood for your project, ultimately wasting a lot of time and money. Without a blueprint how could you build a house? Would you build a shed in your backyard without a plan? Technologists love to rip open the box and start installing things; often times the first thing that gets set aside are the instructions or the manual. You often hear people saying “instructions, who needs instructions, toss them out.” We are all guilty of this, even at home. We get a new gadget and the first thing we do is to power it up and start playing. Why, because it’s more fun! How often do you end up starting over and referring to the instructions? This is why there’s a factory default button on so many technology products.

Well guess what? There isn’t a factory default button for your cloud! For that matter, this same principal applies to a lot of large scale projects: VDI, Active Directory, email, networking and unified communications. I think this is why we are seeing so much more talk about Converged Infrastructure from companies like VCE and HP. They do a lot of the planning, testing and design validation for you. This lets customers focus on the parts that are important to the business.

Proper planning is the most critical aspect when it comes to building your private cloud. In fact, we typically recommend spending a majority of the time in this phase of the project. This will avoid that inevitable press of the factory default button. I know that I have been called into projects many times when things start to go south. When you start to dig in you often find that proper requirements, such as gathering and planning, may not have been done. Requirements gathering gives you and your team something to work toward and keeps the project on track.

Take storage for example; this has a significant impact on performance and scalability when planning for both VDI and a cloud. Determining IOPS, the read/write ratio, and RAID level can have a huge impact on performance and available storage. I recently had a customer that had planned for a very moderate Read to Write ratio of 70% Read and 30% Write and only 10 IOPS per desktop. As it turned out, the applications they were using required a much more substantial 30% Read and 70% Write ratio and about 55 IOPS per desktop.

The results of this were catastrophic; the storage design had to be completely re-architected at a substantial cost to the project. The negative impact to the project and the perception to the end users were very difficult to overcome in the end. Once a user experiences something negative, such as poor performance within their applications or desktop, it often becomes very difficult to overcome the perception the users have to satisfy their needs.

Vendors put together a tremendous amount of information such as white papers, reference architectures and best practices. These documents should be read with caution; it is not a one size fits all solution for everyone. Often your consulting partners have firsthand experience and can bring an enormous amount of “lessons learned” in the field to the table.

Although it may be more fun to rip the boxes open and jump right in, proper planning and requirements gathering is key to the success of your project and will help you avoid having to press that factory default button.