CloudPundit: Massive-Scale Computing

the business of Internet infrastructure, cloud computing, and data centers

Posts Tagged ‘people’

What’s the worth of six guys in a garage?

Posted by Lydia Leong on May 29, 2009

The cloud industry is young. Amazon’s EC2 service dates back just to October 2007, and just about everything related to public cloud infrastructure post-dates that point. Your typical cloud start-up is at most 18 months old, and in most cases, less than a year old. It has a handful of developers, some interesting tech, plenty of big dreams, and the need for capital.

So what’s that worth? Do you buy their software, or do you hire six guys, put them in nice offices, and give them a couple of months to try to duplicate that functionality? Do you just go acquire the company on the cheap, giving six guys a reasonably nice payday for the year of their life spent developing the tech, and getting six smart employees to continue developing this stuff for you? How important is time to market? And if you’re an investor, what type of valuation do you put on that?

Infrastructure and systems management is fairly well understood. Although the cloud is bringing some new ideas and approaches, people need most of the same stuff on the cloud that they’ve traditionally needed in the physical world. That means the near-term feature roadmaps are relatively clear-cut, and it’s a question of how many developers you can throw at cranking out features as quickly as possible. Some approaches have greater value than others, and there’s inherent value in well-developed software, but the question is, what is the defensible intellectual property? Relatively few companies in this space have patentable technology, for instance.

The recent Oracle acquisition of Virtual Iron may pose one possible answer to this. One could say the same about the Cincinnatti Bell (CBTS) acquisition of Virtual Blocks back in February. The rumor mill seems to indicate that in both cases, the valuations were rather low.

Don’t get me wrong. There are certainly companies out there who are carving out defensible spaces and which have exciting, interesting, unique ideas backed by serious management and technical chops. But as with all such gold rushes to majorly hyped tech trends, there’s also a lot of me-toos. What intrigues me is the extent to which second-rate software companies are getting funding, but first-rate infrastructure services companies are not.

Bookmark and Share

Posted in Industry | Tagged: , , | Leave a Comment »

The perils of defaults

Posted by Lydia Leong on May 11, 2009

A Fortune 1000 technology vendor installed a new IP phone system last year. There was one problem: By IT department policy, that company does not change any defaults associated with hardware or software purchased from a vendor. In this case, the IP phones defaulted to no ring tone. So the phone does not ring audibly when it gets a call. You can imagine just how useful that is. Stunningly, this remains the case months after the initial installation — the company would rather, say, miss customer calls, than change the Holy Defaults.

A software vendor was having an interesting difficulty with a larger customer. The vendor’s configuration file, as shipped with the software, has defaults set up for single-server operation. If you want to run multi-server for high availability or load distribution, you need to change some of the defaults in the configuration file. They encountered a customer with the same kind of “we do not change any defaults”. Unsurprisingly, their multi-server deployment was breaking. The vendor’s support explained what was wrong, explained how to fix it, and was confounded by the policy. This is one of the things a custom distribution from the vendor can be used for, of course, but it’s a head-slapping moment and a grotesque waste of everyone’s time.

Now I’m seeing cloud configurations confounding people who have these kinds of policies. What is “default” when you’re picking from drop-down menus? What do you do when the default selection is something other than what you actually need? And the big one: Will running software on cloud infrastructure necessitate violating virgin defaults?

As an analyst, I’m used to delivering carefully nuanced advice based on individual company situations, policies, and needs. But here’s one no-exceptions opinion: “We never ever change vendor defaults” is a universally stupid policy. It is particularly staggeringly dumb in the cloud world, where generally, if you can pick a configuration, it is a supported configuration. And bluntly, in the non-cloud world, configurable parameters are also just that — things that the vendor intends for you to be able to change. There are obviously ways to screw up your configuration, but those parameters are changeable for a reason. Moreover, if you are just using cloud infrastructure but regular software, you should expect that you may need to tune configuration parameters in order to get optimal performance on a shared virtualized environment that your users are accessing remotely (and you may want to change the security parameters, too).

Vendors: Be aware that some companies, even really big successful companies, sometimes have nonsensical, highly rigid policies regarding defaults. Consider the tradeoffs between defaults as a minimalistic set, and defaults as a common-configuration set. Consider offering multiple default “profiles”. Packaging up your software specifically for cloud deployment isn’t a bad idea, either (i.e., “virtual appliances”).

IT management: Your staff really isn’t so stupid that they’re not able to change any defaults without incurring catastrophic risks. If they are, it’s time for some different engineers, not needlessly ironclad policies.

Bookmark and Share

Posted in Industry | Tagged: , , , | 1 Comment »

You are not dating your vendor

Posted by Lydia Leong on April 16, 2009

One of the ongoing refrains of the analyst job is listening to clients gripe, day in and day out, about the things they don’t like about their vendors. Sometimes these things are niggling annoyances. Sometimes, though, these things are rage-inducing, or, in clients who tend to take everything calmly in stride, at least a distinct issue that materially impacts the service that they receive.

Sometimes these issues are recurring problems with a given vendor. I can tell you, for instance, that Vendor X has a process and organizational structure in place which essentially incentivizes its operations staff to kick requests from department to department without anyone being accountable for problems being resolved; unsurprisingly, this results in long resolution times for complex cross-functional issues, and frustrated customers. If you are with Vendor X, it’s something that you have to live with, since Vendor X’s internal politics do not permit fixing the core problem.

Sometimes, however, these issues are out of the ordinary, and would benefit from escalation. However, the majority of the time, the customer has generally not said anything to their provider about the issues they’re having — even if they’re so unhappy they’re planning to leave. Or if they’ve said something, they haven’t escalated into management. They don’t want to rock the boat, or disrupt the “relationship”. They’d rather suffer.

Since I have executive-level contacts at most of the service providers that our clients use, I usually offer to put such clients in touch with someone at their vendor who can see to it that real attention gets paid to the problem. Generally, unless their project is on the brink of failure, clients refuse that offer. Sometimes, they’ll permit me to raise the issue with the vendor, in a more anonymous fashion — i.e., something that doesn’t identify them personally, but which might provide just enough of a hint that the vendor can figure out who it is they ought to be helping.

I don’t get this. You are not dating your vendor. If you wait for them to bring you roses and chocolate, you are going to be disappointed. They will not read your mind, or recognize that you are quietly sulking and waiting for them to notice just how hurt you are and beg you to love them again. You are paying what is sometimes an egregious amount of money for services, and you deserve to get what you’re paying for.

To the vendors who wonder why they get anonymized passed-on complaints from analysts: It’s because analysts can be sort of like a combination of newspaper advice columnists, girl-gossip circles, and therapists. We can only do so much to coax clients into being honest with their vendors.

To the IT buyers out there: When you’re dealing with vendor frustrations, why do you seethe in silence, rather than complaining and escalating?

Bookmark and Share

Posted in Industry | Tagged: , | 1 Comment »

Scala, Ruby, cost, and development trends

Posted by Lydia Leong on April 6, 2009

A recent interview of some Twitter developers, on Twitter’s use of Scala has touched off a fair amount of controversy in the Ruby community, and prompting Todd Hoff of the High Scalability to muse on an interesting statement: At some point, the cost of servers outweighs the cost of programmers.

We all know that the scripting languages that are frequently favored in Web development today — Ruby, Python, and PHP — do not perform as well as Java, and Java in turn can be outperformed by well-written native C/C++ code. However, these popular dynamic programming languages typically lead to better programmer productivity. The argument has been that it’s more cost-effective to have more productive developers, than it is to buy less infrastructure. There is a point, though, when that scale equation can be flipped on its head — when the cost of the servers, due to the performance sacrifices, gets too high. (I would add that you can’t look at simple hardware spend alone, either. You’ve got a infrastructure TCO to look at. It’s not just about more people to maintain more servers, either — that equation is not linear, as a sysadmin can manage more systems if they’re all identical and there are good automation tools. But systems that are struggling due to performance issues soak up operations time with daily firefighting.)

Twitter’s developers are not advocating that people abandon what they know and love, but they’re forging a new path for themselves, with an open-source language developed in academia. Scala can be compiled to either Java or .NET bytecode, allowing it to interoperate bidirectionally with Java and CLR code; this is important for driving adoption because programmers generally like to work with languages that have a solid base of libraries (i.e., someone else has conveniently done the work of producing code for commonly-needed capabilities), and because this makes it possible for Scala to leverage the existing tools community for Java and .NET. Scala’s equivalent of Rails, i.e., a convenient framework, is Lift.

Scala doesn’t have much adoption now, but it’s worth noting that the rapid pace of Web 2.0 innovation is capable of driving extremely fast uptake of things that turn out to solve real-world problems. (For comparison: Not long ago, practically no one had heard of Hadoop, either, but it’s built quite a bit of buzz now.) That’s important for anyone contemplating the long-term future of particular platforms, particularly APaaS offerings that are tied to specific programming languages. The favored platforms can and do change in a tidal fashion — just look at the Google trend graph for Ruby on Rails to see just how aggressively interest can increase over a single year (2005 to 2006).

As a coda to all of this, Twitter’s Alex Payne has a smart blog post, noting that social media fills the vacuum between peer-reviewed journals and water-cooler conversations, yet deploring the fact that in these mediums, emotion can rule over what is measurable. The takeaway — whether you’re an IT manager, a marketing manager at a vendor, or an investor — from my perspective, is this: There’s an emotional context to programming language choice. These are not merely technical communities; these are fandoms, and they form part of a developer’s self-identity.

Bookmark and Share

Posted in Infrastructure | Tagged: , , | 3 Comments »

Discipline and agility are not opposites

Posted by Lydia Leong on February 18, 2009

Too many service providers (and companies in general) use “discipline” as an excuse for “lack of agility”. Discipline does not mean appointing a committee to study the problem for the next year. Exercising caution and prudence does not mean failing to act. Laying a solid foundation does not mean standing around doing the equivalent of watching the concrete set. This misguided notion of discipline is made even worse if the committee sits around drawing personal conjectures based on fear, and concluding that moving with paralyzing slowness (because, I guess, sudden motion draws predators) is the only safe possibility.

There are highly agile companies out there who study and solve problems in a rigorous way — they go out and gather data, they analyze the data, they come to a conclusion, they come up with a solution, they decide what they want to measure to determine the success or failure of the solution, and go out and act. There’s enormous value in swift, decisive, fact-based action. Bonus points if the decision-making is focused on what delivers value to the customer, and that value (whether qualitative or quantitative) can be clearly articulated and measured.

Bookmark and Share

Posted in Industry | Tagged: , | Leave a Comment »

Gallup Strengths

Posted by Lydia Leong on February 12, 2009

A client recently asked me what my Clifton Strengths are. I couldn’t remember at the time, but I’ve dug out old 1.0 results from back in 2006…

  • Ideation. People strong in the Ideation theme are fascinated by ideas. They are able to find connections between seemingly disparate phenomena.
  • Strategic. People strong in the Strategic theme create alternative ways to proceed. Faced with any given scenario, they can quickly spot the relevant patterns and issues.
  • Input. People strong in the Input theme have a craving to know more. Often they like to collect and archive all kinds of information.
  • Learner. People strong in the Learner theme have a great desire to learn and want to continuously improve. In particular, the process of learning, rather than the outcome, excites them.
  • Intellection. People strong in the Intellection theme are characterized by their intellectual activity. They are introspective and appreciate intellectual discussions.

Bookmark and Share

Posted in Analyst Life | Tagged: | Leave a Comment »

Identity overflow

Posted by Lydia Leong on February 11, 2009

Back in 2005, my colleague Monica Basso and I wrote a research note titled, “Wide Array of Communications Overwhelms Users“. In it, we pointed out that the proliferation of communication mechanisms and the complex intermixing of personal and business communications would become increasingly unmanageable.

Until a few months ago, Gartner had a policy that disallowed analysts from participating in most forms of social media. So, up until recently, I’ve had relatively clean distinctions in my communications — a personal instant messaging account, del.icio.us, Facebook, Twitter, and so on, used strictly to communicate with friends. LinkedIn was the face of my business profile.

Now that my employer is actually encouraging use of social media, I’m finding myself facing a problem of converging business and personal identities. I am happy to build big social networks, but categorization and compartmentalization are a big problem. For instance, how do I deal with the fact that my vendor contacts see my high school acquaintances scribbling random things on my Facebook Wall? Should my blog followers who want to see my interesting technology links also have to endure my MMORPG links on del.icio.us? What do I tweet to my various accounts? (On Twitter, I have a business identity, a private friends-only identity, and a public personal identity, but ironically, I find Twitter almost impossibly distracting to deal with, so I tweet and read tweets very seldomly.) How much do I really want to federate of myself on FriendFeed?

I feel like social networking, whether targeted at personal or business use, really needs strong tagging and categorizations. Here are the people who happened to work at the same company as me, that I’ve spoken to a few times; here are my immediate co-workers; here are the people I’ve worked closely with and think are awesome. Here are business contacts at other companies that I want to stay in touch with but don’t have a personal relationship with. Here are vague past acquaintances, current friends, and my inner circle of close buddies. And I desperately want tools on all social networking sites that let me limit the flow of me-related content: public, all connections, just these specific groups.

But more broadly, we are still missing really elegant ways to manage the incredible flow of communication and information that’s coming our way. There’s a commercial opportunity there that’s still not been taken.

Bookmark and Share

Posted in Analyst Life | Tagged: , | 5 Comments »

Self-service shouldn’t mean an information void

Posted by Lydia Leong on February 9, 2009

Joel Spolsky has two UI design principles:

  1. Users don’t have the manual, and if they did, they wouldn’t read it.
  2. In fact, users can’t read anything, and if they could, they wouldn’t want to.

These ought to be core principles of cloud UI design, and, in fact, most cloud infrastructure providers do seem to earnestly be trying to hide complexity between simple, colorful UIs. (Although ostensibly simple things are often not as easy as they look. Appliance-builders and application-stack builders, for instance, usually turn out to be vastly more involved than the GUI, or even the demo, indicate.)

The bright shiny buttons are certainly inviting, and encourage a certain amount of try it and see if you like it, but for a business which is trying to figure out what cloud to go with, understanding the swathe of possible options can be a shockingly difficult exercise. What cloud providers often don’t do a very good job of explaining is what the heck it really means to use their cloud. The in-a-nutshell “this is exactly what is and isn’t going to be different from the systems and network administration you do today” explanation is simply missing.

That’s important, because it means that lots of cloud providers are missing out on the chance to differentiate themselves. Cloud infrastructure is not a commoditized service, yet, and won’t be for several years, while the technology is still immature, and features and the quality of implementation still distinguish providers from one another.

Of course, there’s the challenge: How do you do that without making people read more than a handful of words?

Bookmark and Share

Posted in Infrastructure | Tagged: , | 1 Comment »

The (temporary) death of premium

Posted by Lydia Leong on February 6, 2009

We’re in the midst of a fascinating discontinuity in IT purchasing patterns. Even the dot-com crash didn’t cause this kind of disruption. Practically everyone is scrambling to save money immediately, and some organizations are looking at long-term belt-tightening.

The most obvious immediate impact is that buyer tolerance for paying a premium is rapidly diminishing. Quality is suddenly being eyed with greater objectivity, as businesses stop feeling like they need to have “the best” and start actively considering what services and service levels they really need and can cost-justify. It doesn’t matter (enough) if they love their current vendor and feel they’re getting excellent value for the money. It’s about absolute dollar amounts and aligning spend with needs rather than want-to-haves. Risks are being taken in the name of the bottom line.

Bookmark and Share

Posted in Marketing | Tagged: | Leave a Comment »

The turf war of unified computing

Posted by Lydia Leong on January 22, 2009

The New York Times article about Cisco getting into the server market is a very interesting read, as is Cisco’s own blog post announcing something they call “Unified Computing“.

My colleague Tom Bittman has a thoughtful blog post on the topic, writing: What is apparent is that the comfortable sandboxes in which different IT vendors sat are shattering. Those words demand that computing become a much more flexible, unified fabric.

Tom ruminates on the vendors, but setting aside any opinion of Cisco’s approach (or any other vendor making a unified computing attempt), my mind goes to the people — specifically, the way that a unified approach impacts IT operations personnel, and the way that these engineers can help or hinder adoption of unified data center technologies.

Unified computing — unified management of compute, storage, and network elements — is not just going to shape up to be a clash between vendors. It’s going to become a turf war between systems administrators and network engineers. Today, computing and storage are classically the domain of the former, and the WAN the domain of the latter. The LAN might go either way, but the bigger the organization, the more likely it goes to the network guys. And devices like application delivery controllers fall into an uncomfortable in-between, but in most organizations, one group or the other takes them into their domain. The dispute over devices like that serves as the warning shot in this war, I think. (An ADC is a network element, but it is often closely associated with servers; it is usually an appliance, i.e. a purpose-built server, but its administration more closely resembles a network device than a server.) The more a given technology crosses turf lines, the greater the dispute over who manages it, whose budget it comes out of, etc.

all your cloud are belong to us]
(Yes, I really did make a lolcat just for this post.)

He who controls the entire enchilada — the management platform — is king of the data center. There will be personnel who are empire-builders, seeking to use platform control to assert dominance over more turf. And there will be personnel who try to push away everything that is not already their turf, trying to avoid more work piling up on their plate.

Unification is probably inevitable. We’ve seen this human drama play out once this past decade already — the WAN guys generally triumphed over the telephony guys in the VoIP convergence. But my personal opinion is that it’s the systems guys, not the network guys, who will be most likely to triumph in the unified-platform wars. In most organizations, systems guys significantly outnumber the network guys, and they tend to have a lot more clout, especially as you go up the management chain. Internal politics and whose vendor influence triumphs may turn out to influence solution selection as much as, or more than, the actual objective quality of the solutions themselves.

Bookmark and Share

Posted in Infrastructure | Tagged: , | 3 Comments »

 
Follow

Get every new post delivered to your Inbox.