Every few months (or weeks), the Cloud Computing industry seems to pick a topic and beat it to death from a technology or religious point of view. The concept of “Cloud SLAs” has been doing the rounds lately. Conveniently, these particular discussions came up after a few well publicized Public Cloud outages.
Lydia Leung (Gartner, @cloudpundit) recently got the pot stirring with her piece about HP and Amazon AWS SLAs. Lydia is very well respected in the industry and she does a nice job of digging into the details of various vendors SLAs. She obviously has a deep understanding of this space, especially as it relates to Enterprise customers, as she leads the Gartner IaaS Magic Quadrant program.
There is some interesting back and forth in the comments about what is a proper definition of an SLA. That would be all well and good if Cloud Computing used lawyers or auditors to solve business problems. But it doesn’t. It uses technology. And quite honestly, the business leaders that are paying for various Cloud Computing services don’t care about the legalese or the underlying technology. They care about the business. They care about moving the business forward and managing business risks. Cloud SLAs, in their current form (in most cases), don’t align the business risk and the technology risk very well.
Let’s step back a second and look at this in a slightly different context…
While the discussion about Cloud Computing has evolved over the past few years, far too often it still devolves into a semi-religious debate about Private Cloud vs. Public Cloud. Traditional IT viewpoints say that security and reliability should rule the day, while more progressive viewpoints argue that this old thinking is slowing innovation and the pace of business growth. Not surprisingly, these viewpoints tend to align to either a Private or Public slant.
What is somewhat surprising is that IT organizations have not followed a strategy that has been proven over many years and against various ROI calculations. The practice of “tiering” their applications. In the past this meant applying various levels of resources (typically faster CPUs, more RAM, faster network, various levels of redundancy, etc.) to different classes of applications. While some will say that dragging along any legacy concepts into the new cloud world is a disaster waiting to happen, the reality is that most Enterprises have a huge variety of application needs and application types. Expecting them all to run in a similar manner, with similar SLAs or costs is not realistic. It would be like saying that everyone can wear a suit and tie to the office, so they should all be paid executive compensation. Continued »
Even though I have deeply ingrained networking DNA from having worked many years at Cisco, I’ve tried to avoid writing about SDN too much. Does it get a lot of hype? Yes. Is it still in the early stages with lots of room for innovation and new ideas? Yes.
But over the past few weeks, I’ve come across a few “SDN Use-Cases” that are pretty straight forward, so I thought I’d write about them. Now keep in mind, this won’t be your typical blog about SDN, because I promise to break all these guidelines:
Discuss why SDN means the death of Cisco &/or Juniper
Discuss why SDN will immediately build networks using commodity x86 boxes, because they have fast chips (btw: listen to Packet Pushers #88 if you want good insight into why x86 servers don’t work exactly like switches/routers)
Discuss how SDN is only applicable to “web-scale” networks and “web 2.0 scale-out, share-nothing” applications
Make a list of which SDN start-ups will get acquired in 2013
Backstory: Due to economic uncertainty, new regulations, and maturity of the Cloud SP markets, 2013 and 2014 are expected to see a significant rise in the number of applications, both existing and new, that are run in SP Cloud environments.
These businesses are going to be looking for flexibility in how they onboard applications, how applications are protected, and how they an add, remove or change the environments.
So if you’re one of these viable Cloud SPs, you’re going to have a couple use-cases that need fairly immediate attention.
As I was getting back into the swing of things after the holidays and reviewing a bunch of news sources, a couple of things caught my eye. The first was the return of Portlandia, which made me think of one of my favorite lines, “Portland is a city where young people go to retire.”
The next item I noticed was the announcement of the OpenStack Summit 2013 (Spring), being held in Portland. OpenStack is the collection of open source cloud computing projects with the goal of creating an open alternative to existing cloud computing environments. It promises to allow customers to be able avoid lock-in and support multi-cloud environments. So coincidently, the dream of the open multi-cloud is going to be alive in Portland. Tattoos and Clowning is optional.
Or is it?
I was somewhat surprised to see that Dell claims OpenStack is being “dramatically forked”, causing them to delay their public cloud offering until late 2013 or 2014. This came only a few weeks after they announced support for OpenStack for their Private Cloud offering. While this is only one data point, it also appears to be confirmed by Dell’s OpenStack lead Rob Hershfeld. These comments don’t imply any significant problems with OpenStack, but it does bring up the question about how various companies will balance the tradeoffs of open projects and quarterly revenue demands. Innovation vs. Operations vs. Implementation. How much of the multi-cloud interoperability burden will be placed on customers, and how easily will it be for them to know where multi-cloud is possible? And does any vendor or Cloud Provider really have any incentive to help customers move their application workloads from one cloud to another?
The last item I saw was a knowledgable SysAdmin questioning if OpenStack actually prevents lock-in. He reinforced my prior statement that “open” doesn’t always make things less expensive or less complicated. Whether it’s IT Operations or Developers, almost any decision made about technology comes with some level of cost (people, hardware, software, licenses, integration), so “lock-in” is nothing more than the level of risk of making a decision plus on-going costs plus the cost of future changes.
How important is multi-cloud interoperability to your future IT plans?
How confident are you that multi-cloud technology will be available to your business when the time comes for those capabilities?
Several years ago, it wasn’t unusual to hear people say that public cloud computing was significantly cheaper that trying to build a private cloud computing environment. This was mostly because people would see the cost/hour (in USD pennies) and immediately think this was significantly less than the large CAPEX bill they recently paid for racks of equipment in their own data center.
For short-term projects, public costs are often less.
For high-capacity projects (100-1000s servers), or highly variable projects, public costs are often less.
For long-running projects, private costs are often less.
For limited variability projects, private costs are often less.
There will be plenty of people that can come back with examples of similar projects where the costs are higher (or lower) in one environment or the other. In fact, what is often found by people using cloud computing is that it doesn’t significantly reduce costs (over time). Instead, the prevailing ROI is beginning to be measured on levels of agility, better application performance, or time to market for new ideas (or applications).
Regardless of whether a company runs their applications in public clouds or private clouds, it’s important to understand how costs are incurred. Today, it’s still difficult to make an apples-to-apples comparison between environments as there is not a consistent unit of measurement, or a consistent list of what costs are included. [See this video for a short explanation of cloud computing still isn't priced like commodity markets, or listen to this podcast] Continued »
Traditionally, internal IT organizations have leveraged proprietary software and public Internet services have been built using open-source software. Some of this behavior was driven by legacy technology decisions; continuing to work with previous vendors due to existing applications. Some of this behavior was driven by availability and cost of technical skill-sets. And some of this was driven by the actual pace of change that could be managed by a large organization vs. an external provider.
As I wrote last week, there is a looming interest from Enterprise IT organizations to consider using some of the open-source Cloud Management frameworks to help them deploy Private or Hybrid Cloud services for their organizations.
Whether or not IT organizations actually deploy any of those open-source frameworks for their Cloud Computing environments is yet to be seen. But regardless of if that happens, I might suggest that IT should look at their operational model in the same way that open-source projects are operated. By embracing many of the core principals of open-source projects, IT organizations gain the possibility of not only being able to deliver more responsive services to their business, but also be able to manage the improving technical skill-set of their user base.
I’ve discussed before how some of these functions will be skills of people in your IT organization; let’s look at some of those principles and see how they could be applied to IT operations: Continued »
Sometimes it’s easy to get caught up in the Twitter echo chamber , believing that whatever is good for Google, Facebook or NetFlix must also be good for your Enterprise environment. All new applications, built to scale and running on commodity hardware. But the other end of the spectrum is the conversations that take place at Gartner Data Center, where Fortune 500 companies and less bleeding-edge IT organizations look for guidance on how to keep up with their business demands.
From those discussions, I noticed a couple of interesting polls/images.
The first one was posted by Chris Wolf (@cswolf, VP @ Gartner). While it only used about 100 data points, it does highlight that Enterprises are expecting their Cloud Management platform to come from someone other than the traditional “Big 4″ vendors (IBM, HP, CA, BMC).
The second one was summarized by Lori MacVittie (@lmacvittie). This asked the same question, but with a slightly different set of potential responses. It’s not completely unusual to see VMware leading, given their dominant market-share for the hypervisor (one of the new control points in the data center). But what was interesting was that almost 30% of the respondents said they were considering open-source options (OpenStack, CloudStack). This survey also showed even less interest in the incumbent vendors.
Neither of these surveys explicitly called out some of the start-up Cloud Management vendors, such as Cloudability, enStratus, Rightscale or ScaleExtreme, who tend to be focused on multi-cloud management, with public cloud being the primary deployment model. I suspect that is because the Development audience is still different than the IT Operation audience, and awareness of the multi-cloud management platforms is less well known. Shadow IT doesn’t typically become a management problem until the number of applications, or the amount of critical corporate data grows to larger levels.
While both of these survey have small data-sets, they do highlight that the Enterprise Cloud Management game is still wide-open to many vendors and many open-source projects. IT organizations are still trying to sort through the solutions from all the noise, and they are trying to determine how they will best be able to deliver IT services from a broad range of available resources.
[This is the second in a series of blogs focused on strategies to address the 80/20 Budget Dilemma in Enterprise IT]
Last week, I talked about the challenge of demand outpacing capacity and how IT departments could push business unit funded projects. That could be viewed as outsourcing IT, or leveraging all available resources. Either way, it’s letting the business get things done on their time schedule.
Today I want to explore an alternative that actually enables “Shadow IT“, while continuing to allow traditional IT departments to have visibility, governance and cost-awareness. I’ve used the phrase “Cloud Concierge” in the past, but the concept and technology continue to evolve and have potential.
The concept goes like this:
The IT department sets up a framework that allows any business unit to consume IT resources via a centralized portal. That portal might have a set of pre-packaged applications, or it could provide access to *aaS resources from multiple clouds. Companies like Cisco, VMware, Rightscale, enStratus and others provide these types of products.
The business units would be buying the services (internally or externally) with direct funding. This allows them to align costs to potential revenue streams.
The business units have access to (virtually) unlimited capacity, whether it’s internal or external cloud services, to drive their projects or just experiment on new innovations.
The IT department has the option to enable virtual-private-cloud functionality (or “hybrid cloud“, depending on your definition) if the application requires access to internal data or authentication mechanisms.
Because the centralized portal, not the actual services, are maintained by the IT department, they retain a level of visibility into new projects and new resource demands. They can use it for future capacity planning, future budget planning, or future skills training needs. They can also monitor which resources might need additional assistance for governance or compliance.
For external services (eg. from public clouds), IT departments can educate the business units about additional services they should leverage to maintain security, cost-awareness or connect to 3rd-party applications.
[This is the first in a series of blogs focused on strategies to address the 80/20 Budget Dilemma in Enterprise IT]
It’s widely acknowledged that the majority of IT organizations spend about 80% of their budget to maintain existing applications, leaving only 20% of the budget left for new projects or innovations to improve the business. In the past this was acceptable because the pace in which technology impacted business was slower, but over the last 5 years, this pace has radically increased. The flexibility, or inflexibility, of the 20% is often cited as the reason that many business leaders are growing increasingly frustrated with their IT organizations.
In today’s world, every new business project is an “IT project”, requiring new functionality that enables web, collaboration, mobility, analytics or social services. Each of these new IT demands are built on a business model that expects the new IT services to be delivered in a short timeframe, often with the expectation that IT has infinite levels of available resources. These projects are leading to a surplus of demand, against the perception of limited supply.
Given that many organizations are looking at relatively flat budgets in 2013, what are some of the alternative strategies that IT organizations can explore to better address these challenges?
Business Unit Funded Projects
While an internal IT organization may be a finite resource (capacity, budget, people), this does not mean that IT (technology) resources are not available to address these shortcomings. In fact, the variety of public cloud computing services might be the ideal alternative once internal IT reaches its capacity to serve the business. Many public cloud resources can be obtained on-demand (OPEX-only), meaning that they can start when the business project requires it, and they can be directly aligned to the usage objectives of the business. These public cloud services could be Software-as-a-Service (SaaS), Platform-as-a-Service (PaaS) or Infrastructure-as-a-Service (IaaS) offerings from various providers.
So how might this type of strategy help with the 80/20 budget dilemma? Continued »
A funny thing happened on the way to the next wave in IT technology – Cloud Computing – people seemed to want combine the portability of a time-machine with the freedom to change of the 1960s. Not only do people want the benefit of unlocking IT service delivery from capital expense budgets, but more and more they also want the flexibility to move the source of those services to any location or any provider.
So given that we’re still in the early days of this next wave, what is an appropriate level of concern to have for “lock-in” vs. focusing on bringing new value to the business via technology? And are there specific areas where lock-in might be more of a concern that other areas?
In the past, we often looked to standards bodies (eg. IEEE, IETF, W3, etc.) to define interoperability. But in today’s world, there are as many best-practices being defined via open-source projects as in any standards-body, so companies now need to decide if they value pace-of-change over standardization. IT organizations have traditionally leaned towards risk-migration as the higher priority, which is often in conflict with their business-side counterparts that want results now and aren’t thinking about the management and maintenance of legacy systems years into the future.
In some cases, we’re seeing levels of standardization between defined by loosely defined committees (eg. Open Data Center Alliance; podcast) or by groups of providers looking to establish market-baselines (eg. Cloud Foundry Core; podcast). Some companies view efforts like this as a good thing as it moves them farther along towards levels of interoperability, but there are still some in the industry who are never satisfied with the level of “openness” or often seek to find alternative motives from committees or vendors.
Ultimately the answer to the trade-off between complete standardization and keeping up with change should be driven by business needs. Waiting for a piece of technology to become completely standardized or be “completely open” means trading off business opportunity now. Demanding the freedom of portability, whether it’s at the application or provider level, typically means giving up some of the advanced functionality that made the technology unique for the business needs at the time.
Inevitably, change creates costs. Either opportunity costs, capital costs or operational costs. Whether that change is high in the stack (applications, development frameworks, middleware) or down in the technology weeds (management software, operational process, worker retraining, etc.), there is always going to be a cost. It’s critical that both the business and technology “costs” are evaluated and considered when trying to determine whether to focus on standardization or openness. Neither come for free.