For more on the cloud by Don Jones, see "Please Stop Saying 'Cloud'"
I'm not a big fan of the word "cloud," because it's largely overused and overloaded. When I started hearing "private cloud" being floated around, I thought enough is enough! How is a "private cloud" any different from what I've traditionally called my "local area network?" Why in the world did we need another term for it?
Then I thought about it. Forget, for a moment, the overloaded use of the word "cloud," and think about the original concept of "cloud computing." I'm talking about services like Amazon's EC2 service, Microsoft's Azure service, or even SaaS offerings like SalesForce.com. These share a few very distinct characteristics:
- You provision the services you need yourself, more or less on-demand. You don't have to wait for someone to set up new services for you.
- You only pay for the services you actually need and are using, and you can get an accounting of that usage.
- You don't have any real view of the physical infrastructure -- servers and so forth. You only see the services you're using.
If those three characteristics are what set "cloud" apart from other "hosted services," then we're on to something when it comes to a "private cloud." Most corporate datacenters don't have all of these characteristics, and very few datacenters even have one of those characteristics. But think of the advantages you could get by having a datacenter that shared all three of those characteristics:
Self-Service Provisioning
This is becoming more and more popular inside companies, and with good reason: Self-service provisioning helps take IT out of the loop for common resource requests. No, you're not going to let just anyone in your company be a "self-service customer," but you can certainly authorize selected individuals. This might be as straightforward as a self-service Web portal that lets managers set up new employees and their Exchange mailboxes, or as complex as a portal that lets authorized managers spin up new virtual machines on an as-needed basis.
IT still has to monitor this activity, because we still need to make sure there is sufficient physical infrastructure to support the self-provisioned resources, but IT doesn't need to be involved in the actual provisioning. Of course, this is only a viable plan if you also have...
Chargebacks
IT is viewed as overhead by most companies, and it's because there's often little tie-back to the business itself. That should change. Many companies already do chargebacks for things like e-mail, and that's a great first step. In an ideal world, every IT service would allocate its cost back to the business activity that is using it. That's difficult today, but the emergence of "private cloud" tools and technologies is aimed squarely at making chargebacks more efficient and practical.
Think about it: Today, you probably wouldn't let line-of-business managers spin up new virtual machines on-demand through a self-service portal. Why? Because the cost of hosting, monitoring, and maintaining those things would quickly escalate out of control. But that's because today's line-of-business managers see IT as a basket of freebies. If they could self-provision VMs, and those VMs immediately showed up on the line of business' P&L statement, then those managers would make smarter decisions. Instead of IT saying, "no, that will cost too much," the business manager will say, "no, I can't afford that." It's no different than ordering desks, paperclips, or other physical goods.
Of course, for the idea to be practical, you have to...
Abstract the Infrastructure
Essentially, you become a "hosting provider" within your own company. That is, you become a cloud computing provider to your own lines of business -- thus the term "private cloud." Nobody but IT needs to worry about the infrastructure -- they just "buy" services like user accounts, mailboxes, databases, virtual machines, and the like. They "pay" for those services, thus giving IT the money needed to implement them. Every IT decision becomes tied to a direct business need, and allocated budget from the people who feel they need those services.
Yes, it's a Shift...and No, We're Not There Yet
This is definitely a shift in the way IT does business, and in how the business is managed. It isn't going to happen because one systems engineer suggests it; this kind of change starts right with the CEO, CTO and CFO. In small ways, many IT shops have been doing this for years -- and it's a good idea. Over the next decade or so, you'll start to see a gradual shift to the "private cloud," helping better connect IT decisions with business need and benefit. It doesn't need to happen quickly, but as the tools and technologies arrive that enable this kind of business structure, businesses will slowly start to adopt it.
Posted by Don Jones on 05/06/2011 at 11:47 AM0 comments
Here's a true story: I was once teaching a VBScript class (this was, obviously, years ago) when a student asked if there was a way to write a script that would enforce the membership of computers' local Administrators group. I smiled, knowing that I was about to make this person very happy. "You don't have to write a script," I said. "You can just use the Restricted Groups settings in a Group Policy object." The person shook their head. "We can't. Our Active Directory administrator doesn't like Group Policy, so we can't use it."
I was floored. I literally did not know what to say. I'm pretty sure I stood there with my mouth hanging open for a full minute, shook my head vigorously, and went on teaching as if nothing had happened. What else could I have done?
In the years since, I've run across a metric butt-tonne of similar situations, where folks couldn't do the right thing due to some political reason -- often a misinformed political reason. The most recent: "We can't use PowerShell remoting to remotely administer computers because our security policy won't let us open the necessary port." At the same time, these folks are allowed to use Remote Desktop, which imposes a massively greater performance burden on their servers. They are allowed to use technologies like Windows Management Instrumentation, which uses a much wider range of TCP ports and is somewhat less controllable than PowerShell Remoting. In other words, Remoting is verboten simply because it's new, and the organization's security officer or policymakers won't take the time to understand it.
Folks, this is ridiculous. If you're an IT decision maker in your environment, your main job should be to fight this kind of -- well, let's just call it BS, because that's what it is. This attitude is like saying, "we bought this new car, but we can't use it because we don't really like the idea of gasoline."
Products are built the way they are for a reason. Over time, those reasons will change and evolve, and the products will change and evolve to suit. You can't "just decide" to not use a product the way it was intended because you don't find that way aesthetically pleasing, or because you "don't like it," or because you haven't taken the time to understand it. I can accept, "we're not using it yet, because it's under review." In fact, that statement shows a level of maturity I applaud. You know a feature exists, you're not familiar with it yet, but you're taking the time to become familiar.
From now on, when people ask me how to do something, I'm going to tell them the right way (or ways, if there are choices). But I find myself increasingly unwilling to engage in elaborate hacks and manual workarounds just to accommodate ill-advised, uninformed policies. Use the products the way they're meant to be used, or stop using them and buy something that works the way you want.
Now, that's distinct from instances where there's a compelling, business-related reason. For example, if you told me, "we can't use Group Policy because we're in a highly distributed environment, and our tests show that replicating GPOs puts too great a strain on our WAN bandwidth," then fine. That's a legitimate reason and we can start looking for a workaround. That's a bad example, of course, because GPOs don't do any such thing...but you get my point. A well-informed, business reason to not use a product in a specific way is just fine.
What about you? What goofy policies do you have to deal with that just don't make any technical sense -- or even any common sense? Let me know in the comment section below.
Posted by Don Jones on 05/02/2011 at 9:41 AM4 comments
As I'm writing this, the Internet is finally recovering from the massive outage experienced by Amazon.com's cloud computing infrastructure. Wow, you just don't even realize who's hosting with them until something goes wrong: HootSuite, NetFlix, Reddit, FourSquare, and many more major names all experienced outages.
It's okay -- computers break. I'm sure the folks at Amazon are looking hard at why and coming up with ways to prevent that kind of failure again. Great -- let's move forward.
Actually, let's look back for just a second. Not at the failure or the fallout, but what this means to a business who has chosen to outsource to a cloud computing provider. I know that Amazon provides a solid Service Level Agreement (SLA) to their customers, and that the customers affected by this outage will doubtless be receiving a service credit. Of course, since you "pay as you go" with this kind of cloud computing model, you could argue that these customers aren't owed very much, because they weren't consuming any resources.
Therein lies a risk for cloud computing, and it's one that pundits have identified in the past: That SLA will never cover your lost business. I don't know how much business NetFlix lost, or HootSuite (which has paying customers to contend with, now), or any of the others -- but I know their business impact won't even begin to be covered by whatever Amazon gives them under their SLA.
This has been a major argument for avoiding cloud computing services. I think, however, that it's a bad argument. Consider the alternative: You host all of your services in your own data center. It goes down, like Amazon did, and your redundancies don't work either, which is what happened to Amazon. Who's going to compensate you for your business loss?
Nobody. Certainly not Dell, IBM, HP or whoever sold you your servers. Not the power company, if that was the source of the problem. Not your HVAC contractor, if that's what went wrong. Nobody. The only difference is that instead of having the possibility of controlling the situation and repairing it faster, with cloud hosting you just sit and wring your hands and cuss a lot. But notice that I wrote "the possibility." Just because your services are in your own datacenter doesn't mean you will definitely be able to impact the problem in any way. What if your datacenter flooded? Got hit by a meteor? All of your HVAC units burned out? There are plenty of things that go on in your own data center that are beyond your control, and when those things go wrong you're still tearing hair, cussing, etc.
Yes, you can build redundancies for almost anything -- up to and including a complete, redundant datacenter. Cloud hosting providers can do that, too, and it's often more economical for them. So I'd argue that you simply need to select a hosting provider that has built a more redundant system than you could afford to do yourself. The resources-on-demand model of cloud computing is really, really compelling for a number of businesses. There are still valid reasons not to outsource to a cloud computing provider, such as data security concerns, but I don't think the "well, the SLA won't pay us for our business loss" is a valid reason. Do your due diligence and make sure your provider is set up the way you like, and then hope for the best. That's all you do in your own data center.
Posted by Don Jones on 04/29/2011 at 1:36 PM0 comments
I'm an MVP Award recipient from Microsoft, primarily for my work with its PowerShell technology, and you don't often see me use the words "wasting time" and "scripting" in the same sentence. But now it's out there: I truly believe that a lot of IT teams -- if not most -- are wasting time messing around with the scripts.
Let me be clear and state that this is not a blanket condemnation of scripting or of PowerShell. Quite the contrary, in fact. I believe in the right tool for the right job. Scripting is the right tool when the job is one of two things: First, whenever you have to automate some business process that is unique to your organization, and which cannot be efficiently accomplished in any other way. Second, whenever you need to automate some process that is rarely performed. In that instance, you're not really automating something that's truly repetitive; you may be automating it because it's done so infrequently that nobody accurately remembers how to do it. Either scenario points directly to scripting.
So what doesn't point to scripting? The automation of tasks -- particularly complex ones -- that are common across our industry, and which could be better and often less expensively accomplished by a third-party tool
Some elaboration is in probably in order. First, you have to understand that I do not expect Microsoft to provide tools to accomplish every little task that every organization in the world might want to perform with the company's products. Microsoft's job, in my view, is to provide a baseline set of tools and a solid underlying platform, and to do so in a way that enables third parties (whether your team or ISVs) to build additional domain-specific tools on top of what Microsoft provides. If your organization, for example, frequently needs to scan through file and folder ACLs to see who has permission to what, then I don't necessarily expect Microsoft to put a tool for that in the box. It just isn't a universally needed task (although I admit that this particular example is becoming pretty widespread), and even amongst the organizations that do need to perform this task there's a lot of variation in how they need the results presented.
So, third-party tools are, and should be, a way of life. When should you not build them yourself, and instead go to a third-party ISV for them? When those tasks are a critical, almost daily part of your business. Let's switch examples for a moment and consider the need to collect Active Directory auditing events into a single, consolidated, searchable log. You could certainly write scripts to do that, and I have a number of consulting clients who've done just that. They're limited to the information in the event log, of course, and that information isn't always the most human-readable. Most of the examples I've seen required an administrator to spend about a week building, and then perhaps 10 hours a month maintaining and tweaking. So in the first year, that's about $7,000 in man-hours. Folks usually spend a lot more time consuming that data -- the two customers I've worked with who took the time to quantify that work spent an average of 40 man-hours per month sorting, filtering, searching and presenting data from those raw event logs. They spent another 20 hours per month doing what I call "dealing with" the data -- for example, translating event IDs into a meaningful message, looking up SIDs and GUIDs, and so forth. All work made necessary by the low-level nature of the data in the logs. They assigned a value of about $30,000 per year to that effort. Round number, $37,000 per year total.
That's a lot of money. These same organizations steadfastly refused to bring in a third-party change auditing solution for close to seven years, meaning they spent about $260,000 in man-hours. One of them is still doing so. The other got sick and tired of the additional hidden costs of scripting -- like when its Script Guru left the company, and someone else had to spend three weeks coming up to speed on the scripts ($5,000 more to the bill). That company runs a 6,000-user Active Directory domain, and their third-party auditing solution cost them $108,000 in the first year and about $20,000 in annual maintenance fees thereafter. Five-year cost: $188,000. It's in the first year now, and its time commit on those same tasks is nearly zero because it selected a tool that provides exactly what it needs, more or less automatically. Even reports are produced and mailed out automatically.
That's just one example, and the point isn't so much that one company's specific numbers as it is the general theme: Scripting isn't free. It requires man-hours, even just to maintain, and comes with a big risk that your "Script Guru" will leave you in a lurch at some point. You can mitigate that by educating more of your troops in scripting, of course, but do so strategically. Focus on the tasks that don't need to be run often (making script maintenance less expensive), or focus on tasks for which an affordable tool simply isn't available. The argument, "Well, if they weren't writing scripts, we wouldn't need those people" doesn't hold water -- there's always work for an admin. Let them be admins, not software developers. Look closely and you may find that tools to automate daily, mission-critical tasks are less expensive in the long run, provide better functionality than you could script yourself and do a better job of meeting all of your organization's business goals.
I'm not saying don't script. I'm saying script when it makes sense. Be a strategic decision maker.
Posted by Don Jones on 04/25/2011 at 2:50 PM6 comments
Okay, we need a serious dose of reality here. I just finished a customer engagement where the company's IT director, in no uncertain terms, told me that his company was having nothing to do with "the cloud." I nodded, and asked why. Turns out he'd recently attended a tech conference, where the keynote address (according to him) was basically summed up as, "no company is going to outsource their IT to the cloud." He agreed that outsourcing his IT was a bad idea, and so no cloud for him.
Sigh.
I blame the IT marketing sub-industry for this. Let's start by agreeing to never use the term "cloud" again. They co-opted that term from the telecommunications industry anyway, and the term makes a lot more sense there because nobody is going to run their own telecom infrastructure unless they are a telecom company.
What folks routinely refer to as the "cloud" in the IT industry is actually something very different. It's a huge variety of services and approaches, all of which offer to let you outsource some portion of your IT capabilities – things you might normally handle yourself, in your own datacenter. This is hardly a new concept: I've had a "cloud e-mail" address (it ends in yahoo.com) for close to a decade, now. I've been using "cloud computing" (a Web hosting service) for just as long. The idea of outsourcing bits of your IT environment to an offsite service provider is well-established; it's only recently that everyone suddenly wants it to be called "the cloud."
The only thing new in the more modern outsourcing model is the idea of on-demand provisioning and pay-as-you-go. My old-school Web hosting provider charges me a fixed fee every month; with a true "cloud" hosting arrangement, my fee might shrink and grow as more people visited my Web site. The site would dynamically expand and shrink to accommodate demand (or, in some instances, I could manually provision more resources to accommodate demand), and I'd pay for what I was using.
Saying that your company will never outsource your IT capabilities is fine. Most companies won't outsource everything, because it doesn't make any sense whatsoever. But that's not what this "cloud" model is all about. The idea is that you outsource the bits that make sense for your organization, creating a "hybrid IT" environment where some services come from your datacenter, and others come from offsite. In fact, I really prefer the term "hybrid IT" over "cloud," because I think it more accurately describes what the model is all about.
Take e-mail: Some companies could never, ever, ever outsource their e-mail. I get it. You need to have direct control to maintain your security, your availability, whatever. Fine. Other companies, however, view e-mail as a serious pain in the you-know-what, and would give anything to have it "just work." Those companies should outsource their e-mail, creating a hybrid IT environment where some services come from outside the company. Those same companies might well continue to handle their own in-house applications, databases, and so forth, because they need to in order to achieve their business goals. In other words, you outsource what makes sense. Often, that includes IT services that aren't crucial to the day-to-day operation of your company, that don't directly tie into what your business does for a living, and that cause you more stress and headaches in terms of keeping them up and running every day.
That's the other thing: People keep pitching "the cloud" as a way to save money. I call "foul" on that, because I've rarely seen it to be true. What hybrid IT does offer, however, is a way to remove some distractions. Don't want to spend months deploying a CRM solution, and then spend hundreds of man-hours a year supporting it? Fine, use SalesForce.com. Outsource that one distracting bit that your organization needs but doesn't directly want to own. That's hybrid IT. You might not save money either way, but you'll have less headache.
Please don't think for an instant that your company, for whatever reason, won't ever outsource anything to "the cloud." You will, eventually. In fact, a smart decision maker will keep his or her eyes open for the opportunities that make sense.
What do you think? Let Don know by adding your comment to this article, e-mail him here, or follow him on twitter @concentrateddon.
Posted by Don Jones on 04/13/2011 at 11:50 AM8 comments
Welcome to my new blog! As you may know, I write the monthly "Decision Maker" column for Redmond magazine. Much of that column's content is based upon my consulting and analysis experience. My main job at Concentrated Technology is to provide strategic consulting for our various business clients around the world; basically, that means I sit down with businesses, figure out what their challenges are, and help them decide which ones they can address – and how to do so. We also work with a variety of Independent Software Vendors (ISVs) to help them understand what the marketplace needs in terms of solutions, to properly focus their products features, and so on. All of that work generates a lot more information than I can include in a monthly column, so the folks at Redmond magazine and I decided to start this blog, where I can share information as I come across it.
This is not going to be news analysis -- I've heard over and over from my readers that they get more than enough of that in various places already. No, my goal here is to help you understand the industry's directions on a variety of subjects -- Microsoft's directions in particular. I'll show you where various ISVs are going with their solutions, and help you see the gaps that exist in Microsoft's native product functionality. I'll share intelligence on what other organizations like yours are doing to solve their day-to-day IT challenges, so that you can get a feel for what's emerging as "best practices" within our industry.
I hope you'll find it useful, and I hope -- from time to time -- that you'll take a moment to share your own experiences. Drop a comment at the end of an article, or contact me directly (use the form at http://concentratedtech.com/contact to do so). I may even contact you for more details on what you and your organization are up to from an IT perspective, and if you're interested in being part of one of our focus groups or surveys, definitely let me know.
Let's get started.
Posted by Don Jones on 04/10/2011 at 11:50 AM0 comments