Archive

Archive for August, 2007

Links – 08/28/2007

Don’t Worry, It’s Safe to Power off that Server and Power It on Again (Vinay Pai): Vinay posts on one of the biggest myths in data center operations: the “Mean Time Between Failure” myth. In short, if you ran 1000 servers for 3 years, there is a .06% chance that any power supply would fail. From this, he notes that dual power supplies are an inefficient solution (from a green standpoint) to a decidedly minor problem. Remember this point for some of my future posts–this myth is busted, and knowing this opens you to some very quick and simple power efficiency practices.

Lowering Barriers to Entry: Open Source and the Enterprise (The Future of Software: Stephen O’Grady): Stephen, of Red Monk fame, argues that the real value of open source software is not its price or code quality, but the ease in which it can be introduced into an enterprise. According to Stephen, open source puts the power of software acquisition into the hands of developers and architects. Would you agree? Is there an equivalent possibility for open source hardware? SaaS? Utility computing? Or will those drive the pendulum back to central management control?

Scalability != concurrency (Ted Leung on the Air): Given my past as a enterprise software development junkie, this article is particularly interesting to me. A little debate is breaking out about the shortcomings of Java in a highly concurrent hardware model, and there seem to be a few upstart languages making a name for themselves. I’m was not aware of Erlang, but you can bet I will spend some time reading about it now (despite its apparent shortcomings–see below). For those interested in utility computing and SLAuto, remember the goal is to deliver the functionality required by the business using the most cost effective resource set necessary to do so. Software is a big part of the problem here, as inefficient programs (or even VMs, it seems) can minimize the impact of better hardware technologies. Keep an eye on this, and if you are writing software to run in a SaaS / utility computing world, consider the importance of concurrency to gaining cost effective scale.

http://www.russellbeattie.com/blog/java-needs-an-overhaul (Russell Beattie): This is the article that triggered Ted’s comments above. An interesting breakdown from one developer’s point of view, with an brief overview of Erlang’s shortcomings as well.

Categories: Uncategorized

Links – 08/23/2007

August 23, 2007 2 comments

AWS and Web 2.0 Mapping (WeoGeo: Paul Bissett): Paul, founder of WeoGeo, a company focused on geospacial solutions, made a comment in this post that I thought needed sharing:

Mapping, particularly quantitative mapping like GIS, and AWS go together like peanut butter and jelly (I have 3 small kids who have been out of school all summer, so this was the first analogy that came to mind). The utility computing of EC2 and the large web-addressable disk storage of S3 provide opportunities for developing and sharing of mapping products that previously were cost prohibitive.

A solar-powered data center saves energy its own way (SearchDataCenter.com: Mark Fontecchio): Frankly, I think this may actually be a wave of the future. Time to buy cheap real estate in the California desert, folks. (No access to the grid required! Drill a well for water, dig a septic tank, and Internet access is your only utility need.) Given the success AISO.net is having here, I would be surprised if more small-medium sized data centers don’t pop up where the sun shines almost every day.

Hell, with the spaceports going up in New Mexico, that state’s deserts might not be a bad place to place your bet either.

Categories: Uncategorized

Business doesn’t ask for utility computing, part 2

August 22, 2007 1 comment

Bob Warfield (of the stealth mode company, SmoothScan) called me out on the admittedly flippant argument I put out for IT ownership of infrastructure strategy and architecture. I made this argument specifically in the face of business units (and even hosting clients) who are extremely resistant to sharing “their” servers with anyone. Bob’s response is insightful, probably exactly how BUs will respond, and deserves a careful response.

IT is a service organization. (Translation: You work for us, and we’re more mission critical than you are. You are replaceable by VAR/SIs and by SaaS. Be careful when getting uppity with us.)

Damn straight. We are a service organization, and as such our sole purpose of costing our enterprise money is to meet your functional and service level requirements in the most cost effective way possible.

However, your statement does not explain why you shouldn’t share servers. If we demonstrate conclusively that we can better meet your service levels at a lower cost with virtualization and/or utility computing, clearly it is in the financial interest of the company for you to pursue the concept further. In the same vein, if you can prove that you can get the business functionality you need for cheaper through a SaaS solution, we should help you make that happen.

You have not always met your SLA’s and delivered your projects on time and on budget. In fact, there is at least one major nightmare project on everyone’s mind at any time. (Hey, it’s software, what else is new, it wasn’t our fault, part of it is business’ fault beacuse of how they spec’d their requirements and then failed to deliver, yada, yada. But, fair or not, IT gets the blame. IT has more glass on its house than anyone.)

We completely agree–IT has often failed to deliver (or been party to delivery failures). However, because we are focusing on infrastructure issues, let’s let the SOA guys describe how they will mitigate software delivery failures.

There are two key forms of project failures for IT infrastructure:

  1. Failing to acquire, install, configure and provision hardware in a timely fashion
  2. Failing to meet agreed upon SLAs when operating that hardware and their software payloads.

Assuming we physically receive the hardware in a timely fashion, we then must use automation to greatly reduce the cost of getting new systems up and running quickly. Whether or not systems are shared by business units, this need is there.

In fact, because we are utilizing resource pooling in a utility computing model, it will often be possible to provision your software without requiring you to wait for any associated hardware. Want to get a quick beta marketing program up and running in a matter of hours? Give us the binaries and we will find capacity for it today. We’ll determine the need to add additional capacity to the system later, once we see trends in overall infrastructure demand.

As far as service levels go, response to violations have to be automated. No more waiting for someone to respond to a pager call–if a server dies in the middle of the night, SLAuto systems must quickly restart or replace the failed system. With automation involved in meeting your SLA needs on shared systems, we aim to remove the dependency on “human time” and the limits of siloed resources, which are what was killing us before.

BTW, our new friend (insert name of Enterprise Software Sales Guy) has told us all about these topics, so we’re knowledgeable too, and we think you ought to listen to us. (Very dangerous game for the Enterprise Sales guy, but if IT already shut him down, this is exactly how they’ll play it in many cases because they have nothing to lose.)

Again, unless Mr. Enterprise Software Sales Guy was selling you something that manages infrastructure (in which case, why do you care?), what he is selling doesn’t impact the decision of why or why not to share servers with other business units in an IT utility. If he is telling you it does matter, he’d better be able to demonstrate how his product will beat the ROI we are projecting from utility computing. Oh, and that is a BIG number.

We still remember those times when you put the needs and requirements of your own organization ahead of our business needs. You wouldn’t choose the app we wanted because it didn’t fit your “standards”. The app you did choose stinks and our competitors, who use the app we wanted, are now running rings around us. (Yep, it happens. I’ve seen IT frequently choose an inferior or even unacceptable app because they didn’t care and had the power to ram it down the business’ throats. When it blew up, IT either lost credibility or the business suffered depending on how the culture worked. This happens at all kinds of companies, large and small, successful or not.)

In my earlier example, I made it clear that you have the right to push as much as you want for functionality and aesthetics. Applications are the point where both originate, and we fully support your demands that we not make your application decisions for you (but hope we can make them with you). However, architecture is a different story, and infrastructure architecture is about as far removed from functionality and aesthetics as you can get (except in relation to service levels, but we already covered that). Again, if we deliver the functionality you want at the service levels you require in the most cost efficient way reasonably possible, then you shouldn’t care.

Oh, and by the way, we take full responsibility of reporting to you the SLA compliance levels and associated cost of infrastructure as we move forward, so you can determine on your own if we are really achieving our goal. Of course, that might come in the form of a bill…

The core of Phil’s comment boils down to the following:

You won’t wean the business from sticking their nose into IT’s business so long as these cultural factors persist. Earning the write to be a trusted deliverer carries with it the responsibility to be trustworthy.

Have you been trustworthy?

If not, even if it wasn’t your fault, consider a more consensus oriented approach. After all, the speeches described above boil down to “do it because I say so”. I try to avoid that with my kids where possible, and it is possible almost 100% of the time.

To that I reply “mea culpa”. I was stating my case in a much less friendly tone than I would in real life to make my point. You are right that all business relationships must (ideally) be consensus driven. However, in the end the cost savings driven by a multi-tenant approach (be it utility computing, virtualization or SaaS) can’t be achieved if each business unit demands owning its own server.

One last thing: it has been my experience in the last year or two that business units are much more open to sharing infrastructure within a company. As long as data security is maintained, business application owners are most concerned about the same things IT is–delivering required functionality at required service levels for as little cost as possible.

Sharing infrastructure with another company, however, is an entirely different story.

Categories: Uncategorized

Links – 08/21/2007

MaaS – Money as a Service (Roman Stanek’s Push-Button Thinking): The analogy of banking to software usage is a good one. As Roman says:

“[A]s nobody would keep their money at home stuffed in a mattress anymore, I don’t expect users to go through the pains of installs, upgrades, re-installs and maintenance of complex software products. “

Sure enough. However, note that there are always some entities that keep their own cash handy: banks, for one, not to mention government treasuries. In the same vein, I think there will always be certain non-IT organizations that will maintain their own data centers, such as financial firms with proprietary IT that enable competitive advantage, as well as law enforcement and national defense.

Millions of Square Feet (RackLabs: Lew Moorman): This is an interesting example of how computing needs translates directly into physical space. I’m interested in knowing what RackSpace / RackLabs view of the business model for utility computing is, but at the very least we can see that giant compute farms are most definitely in our future.

Tech’s own data centers are their green showrooms (InfoWorld: Robert Mullins, IDG News Service): This article covers the “eat your own dog food” approach that both Sun and Fujitsu are taking in terms of energy efficient computing. It is interesting to me, however, that none of the solutions described simply turn unused equipment off…

Categories: Uncategorized

Business doesn’t ask for utility computing,either…

August 20, 2007 5 comments

Call for more EA collaboration (Enterprise Architecture: From Incite comes Insight…: James McGovern) and
SOA and EDA: SOA-selling battle goes on in blogosphere (SOA and EDA: Jack van Hoof): Interesting discussion regarding Jack’s post, “SOA and EDA: Business doesn’t ask for SOA“. There seems to be a little bit of backlash to the argument that no one should have to sell SOA to the business. However, James puts it wonderfully when he presents the following observation:

Imagine finding a carpenter with thirty years of experience and having him ask you whether it is OK if he uses a nailer instead of the trusty hammer and nail. Wouldn’t this feel absurd?

Absolutely. IT architecture is actually very rarely a business issue. This is as true in infrastructure as it is in software. Which is why arguments from the business that “I don’t want to share my server with anyone” shouldn’t hold a lick of weight with IT. If you encounter that kind of resistance in your world, just fire back the following:

“As long as I am meeting your service levels, how I deliver them is not your concern. Like the relationship between home builder and client, we are responsible for delivering the product you pay for to required building codes (meaning IT technology governance, not business “want to haves”) and contractual quality specifications (SLAs).

Feel free to “drive by the property” occasionally to see our progress (and comment on aesthetic and feature completeness concerns), but trust our professional experience to design and build the required infrastructure. As a cost center, believe that it is in our interest to drive down costs, passing the savings on to you.”

This argument would probably hold true for the hosting-client relationship as well…

Categories: Uncategorized

Plumbers are plumbers, dude…

August 18, 2007 2 comments

Allan Leinwand, a venture partner with Panorama Capital, founder of Vyatta, and the former CTO of Digital Island posted an interesting article about what it will take for today’s telecom service providers to become major players in the Internet of the future. As Allan puts it:

If there’s one thing that service providers denounce, it’s being classified as the plumbers and pipe fitters of the Internet, destined to move bits between co-location facilities. With the software-as-a-service (SaaS) and Web 2.0 revolutions in full swing, service providers are pounding the table, insisting that they have evolved beyond the mundane task of moving bits to become “service provider 2.0” companies.

Allan goes on to demonstrate that the true advantage that these SPs have over startups is their understanding of scale, though he is less than certain that they will be able to take advantage of the opportunity.

I believe the telecom providers have never moved beyond being the plumbers, though innovative plumbers that have figured out all kinds of ways to charge you for every turn of a faucet. Doubt me? Just look at the Web 1.0 world. Every single Internet access provider I have used has offered me a “home page” of their making, with supposedly advanced services for accessing mail, news, search and other key features of the early Internet. And in every case, I quickly replaced their tired page with either my My Yahoo page or Google. Not a single one was able to offer me anything innovative enough to see them as leading edge technology in the Web content space.

The same will be true for SaaS (Software as a Service), FaaS (Frameworks as a Service) and PaaS (Platform as a Service). They may be great at scaling network architectures, pretty damn good at scaling computing infrastructures (making one or more Bells a player in the compute capacity space), but they haven’t got a clue how to provide the art that makes Internet content compelling. I’ve worked with telecoms and Internet access providers in the past, and I wouldn’t trust them to create an ERP package, social networking site or even an online photo album that would hold a candle to Salesforce.com, Facebook or Flickr respectively.

It all comes down to the layering that Isabel Wang points out some major players are evangelizing these days. To quote Isabel:

Amazon and Microsoft made me realize that Internet infrastructure solutions should be – will be – delivered in 4 layers:

(a) Data centers/physical servers/virtualizataion software

(b) Utility computing fabric comprised of large pools of servers across multiple facilities

(c) Application frameworks, such as Amazon’s web services APIs

(d) Shared services, such as identity management and social networking

Damn straight. Think about the implications of the above. To expand on those definitions a little bit, if you want to cover all of the bases in the Web 3.0 world, you have to deliver:

  • servers (physical and virtual) with supporting network, storage, power, cooling, etc. systems
  • automation and management intelligence to deliver service levels in an optimal fashion (insert SLAuto here) on that infrastructure
  • some killer APIs/frameworks/GUIs to allow customers to apply the infrastructure to their needs
  • all of those core capabilities that customers will require but will not want to build/support themselves (such as the things that Isabel notes, but also there is some SLAuto here as well)

The SPs that Alan references are great at Isabel’s layer (a), and have a head start on delivering (b). However, when you move to (c), all of a sudden most service providers fall down. Even the wireless guys rely on Java / Microsoft / Nokia / etc. to provide this interface on their networks. Today, there are no telecoms, hosting providers or other Internet service provider that comes even close to handling (d).

Is anyone handing all four layers? Sure, the software companies that know how to scale: Google, Amazon, Microsoft, Salesforce.com, Ebay, etc. These guys worked from the top down to build their businesses: they wanted to provide applications to the masses, so they had to build (d), (c) and (b) in order to keep the required (a) manageable. Some (soon most?) of these guys are working to make a buck off of the rest of us with their technology.

It took startups–quickly growing startups, mind you–to work through the pain of being dominant Web 3.0 pioneers. However, even they don’t own the entire infrastructure stack needed to do truly dynamic web computing, and they are really still pretty damn primitive. (For example, while many of these vendors have internal automation to make their own lives easier, they offer their customers little or no automation for their own use.)

Telecoms will always own the networks that in turn make the rest of our online lives possible. They may also acquire companies that know how to do the software infrastructure side a bit better–identity infrastructure especially seems like a good telecom business; after all, what is a phone number other than a numeric user ID? But they will not likely be the owners of the social networks of the future. They probably will never be the dominant capacity providers in the utility computing world. However, owning the network is a powerful position to have.

Network neutrality, anyone?

Update: You should read the comments to Alan’s article, as well. Lot’s of very smart people saying much the same as my long post, but in far fewer words. 🙂

Categories: Uncategorized

Links – 08/16/2007

Convergence of Virtualization and Green Data Center Trends Could Be Perfect Timing for Microsoft (ITBusinessEdge: Kachina Dunn): Kachina notes that Microsoft may gain the most from the way the virtualization market is setting up. Combine that with the comments that Chris Kanaracus made about Microsoft’s “compute cloud” strategy, and you begin to get the feeling that Mr. Softy may out-engineer its rivals in utility computing technology. I hope not, because (like VMWare) they are still obsessed with locking people into their platform. We need that utility computing portability standard!

Ozzie Reveals More Details of Cloud Development Platform (RedmondDeveloper: Chris Kanaracus): Another good breakdown of Microsoft’s “PaaS” (Platform as a Service) play. Ray’s comments at the end of the article give me the feeling that Google, Amazon, Salesforce.com and others are not free and clear of MSFTs influence, yet.

“We believe we are the only company with the platform DNA that’s necessary to viably deliver this highly leveragable platform approach to services. And we’re certainly one of the few companies that has the financial capacity to capitalize on this sea change, this services transformation.”

Grid computing: Term may fade, but features will live on (ComputerWorld: Barbara DePompa): Barbara discusses the view of many that the term “grid computing” may go extinct in the face of virtualization and utility computing. My own opinion is that “grid” has actually had its definition narrowed back to its roots: grid computing platforms provide resource allocation to job-based computing processes, like batch data processing, image rendering and HPC. Utility computing is the term that applies to all “computing on demand” applications, including grid applications.

Automation and going green in the data center (NetworkWorld: NewDataCenter): Someone at NetworkWorld saw the light at Next Generation Data Center in San Francisco earlier this month. I just wanted to welcome them aboard, and invite them to explore the importance of SLAuto to both automation and green practices.