Subscribe

In my last post we took a bit of a journey back through time looking at various technology waves of the past. In this entry, I want to explore how I think applications will be purchased going forward, as it’s important to understand the business model, which has a direct impact on the underlying technology.

The diagram shows how I envision applications being purchased in the future.

An IT manager decides that he/she needs a new application or needs to renew a license for an existing application. Once this decision is made, it goes for approval. This too can be automated, though that is mostly irrelevant to the story, as this technology exists today.

What is relevant is how the application license is ordered and delivered. Rather than buying a generic license, the IT manager buys a license with certain attributes. These describe things like the term of the license, the reliability requirements (e.g. software HA, DR, etc.), performance requirements (e.g. 200MB/sec IP, 100 MB/sec IO), etc.

The attributes are then used to purchase the application and decide what is the appropriate hardware for the application to be deployed on (e.g. one that can deliver on the performance and/or reliability attributes).

Taken another step further, the application may come “wrapped” in a virtual machine container, allowing it to be portable across a diverse set of hardware, though the model should work for both virtual and physical machines. The picture below gives an indication of what this might look like.

Finally, you can envision an eBay-like auction capability where buyers and sellers arbitrate over the price of the application, which automates and streamlines the selling process and in theory, drives the prices lower.

So, that’s how I see applications getting delivered. Next, I’ll be looking at how to automate the provisioning of the underlying platforms to support this model.

Would love to get some feedback, so be sure to leave a comment or send me an e-mail with your thoughts too.

The Journey Begins

In my last post I said I’d be writing a series of posts on where I think the data center is headed. This is the first in that series and it starts with my blueprint of the journey that we’re all on to simplify the data center…customers and vendors alike.

If you look back at the history of IT development, the industry typically works in major 10 year cycles, where new technologies are envisioned, developed, and deployed. About the time this new technology hits the mainstream, we as developers are already thinking about what the next big thing is.

This has been true since the early days, though the trend lines are accelerating compared to earlier trends. Some of these trends include mainframes, PCs, client/server, Internet, and now virtualization. Inside of these trends are mini-trends such as Web 2.0 or SaaS, which are actually fine tuned implementations of the macro trends.

The graphic below shows you my take on the next major trend. It’s really all about creating the Dynamic Data Center. I’d argue that virtualization isn’t really a trend (even though I called it one above) but rather a technology advancement that has enabled us to progress toward a truly Dynamic Data Center. It’s an important technology, but it’s “just” a technology…a means to the end we all are shooting for. CIOs are not screaming that they need virtualization. They are screaming about needing a lower cost, more flexible data center.

The first phase of this new trend is the Server Consolidation phase. This is where the first wave of technologies - Server Virtualization, are inserted in the data center. These are products like VMware ESX, Citrix/Xensource, Microsoft Hyper-V, etc. These products allow servers to be partitioned securely, enabling multiple applications to run in virtual containers as if they have their own underlying hardware. This technology is a takeoff on the mainframe VM capability. The innovation is applying this powerful concept to the x86 architecture. The result is that server utilization can be increased, lowering CAPex, power, and cooling. However, it often has the unfortunate side effect of making the data center more complicated, as now IT managers need to manage virtual machines in addition to physical machines. That being said, it is still very valuable and powerful technology. No question.

Phase 2 is about reducing complexity - both the complexity that is inherent in the data center today as well as that introduced by Phase 1 technologies. Key to this phase are technologies such as IO virtualization and enhanced management software. If phase 1 was all about virtualizing the server, phase 2 is about virtualizing and simplifying what surrounds the server.

One thing I think that will be critical to phase 2 success are common standards. Phase 1 was for early adopters and companies could deploy their technology with little regard for interoperability. In phase 2, simplification means that applications and virtual machines must work in a heterogeneous environment. This is at all levels, not just the server level. For example, there must be a path for virtual machines that run on VMware to migrate to a Xen environment and vice versa. There must also be common management interfaces. This is key to starting the next, and final phase of this wave, the Business Agility Phase.

In the BAP, applications are delivered wrapped in virtual machine templates and can be deployed on any server at any time. In fact, the deployment rules are based on business SLAs managed by automation engines (more on this in my next blog).

So that is the journey as I see it today. From static, inflexible data centers to fully automated, dynamic data centers. All the fun will be in how we get there! Stay tuned for more on that.

iSCSI’s Bad Luck!

As Ethernet speeds reached Fibre Channel’s 1Gb/s and IP became a defacto global protocol for small and large enterprises alike, it became clear that wrapping SCSI commands in TCP/IP packets may be the next standard for block transfer over networks. Even more exciting was that iSCSI would run on everyone’s favorite data center network, Ethernet. So with that promise, iSCSI became a full fledged IETF standard in 2002.

iSCSI has surely gained steady momentum and market share, but not at a pace in line with earlier expectations. Certainly, it has not taken foothold in the large enterprise SAN market which has continued to deploy Fibre Channel. Of course, it did not help that Fibre channel speeds also got upgraded to 2 and then 4 Gb/s while Ethernet remained at 1 Gb/s.

iSCSI also saw several technical challenges running over Ethernet. Block transfer protocols are highly susceptible to latency and loss. Ethernet networks being a best effort datagram service do not have delivery guarantees. Ethernet switches with rather shallow buffers have a nasty habit of dropping packet when there is congestion. Worse yet, the iSCSI storage array becomes the congestion point in a switched Ethernet network since all clients (or iSCSI initiators) want to simultaneously access it.

Another issue is that TCP/IP’s congestion management is really optimized for long haul networks (with large round trip delays). If you want high performance iSCSI on a LAN, initiator and target TCP stacks must be modified and tuned for operation on lower bandwidth-delay product networks. Finally, high performance iSCSI really wants to use Jumbo Ethernet packets with larger I/O sizes (like 64KB) to reduce the per-packet processing overhead on end-nodes. Well, running Jumbo packets on Ethernet switches with only a couple of MB of packet memory can result in, yep you guessed it, more drops if the network is not purposely designed.

Enter 10 Gb/s Ethernet and a new generation of Ethernet NICs with Transport Offload Engines (TOE) and iSCSI protocol offload in HW. This gave iSCSI the long awaited boost it needed to hit the main street. A multitude of start-up companies now offer compelling iSCSI 10G NICs with TCP and protocol acceleration capabilities. Also carrier class features like Weighted Random Early Discard (WRED) and traffic shaping have made their way into LAN switches that allow high performance TCP on LANs.

The recent Data Center Ethernet (DCE) congestion management initiative proposed by IEEE8021au/az has also opened doors for FC vendors to bring their beloved Fibre Channel packets and run it over 10 Gb/s Ethernet networks. Cisco has been leading the effort for Fibre Channel over Ethernet standard (FCoE) and already has products in the market. All these new DCE features also help iSCSI performance over Ethernet just as well but I do not hear anyone talking about that!

Ethernet has proven time and time again that it is the Borg that assimilates all other competing LAN transports. So, what does the FC community do? If you cannot beat it, embrace it. FC switch vendors like Brocade can offer new switches that have FC and FCoE Ethernet ports. FC HBA vendors like Qlogic and Emulex now get to play in the perceived to be enormous 10 Gb/s Ethernet NIC market. Furthermore, they will claim that their “trusted” drivers and Fibre channel “secret sauce” on THEIR Ethernet NICs will be better than traditional Ethernet NIC vendors’ FCoE offering since they have no FC experience. Brilliant!

Just when you might think that things are finally start looking brighter for high performance iSCSI as the storage protocol of choice over 10 Gb/s Ethernet LAN, it is again faced with stiff competition. The good old Fibre Channel is back in new clothes playing in iSCSI’s backyard. Perhaps the most compelling positive that FCoE has going it for it is that the standard provisioning and management tools can manage FCoE infrastructure like they do FC SANs. iSCSI has going for it a year or so of lead to prove itself on 10 GigE before NIC vendors offer FCoE.

With 2 Ethernet based SAN protocols, I would be willing wager a bet that enterprise SAN is slowly but surely moving to Ethernet. Who wants to bet?

One Point of View

Summer time is great for vacation, especially in the North East where we get about 6 good weeks of weather all year! It’s also a great time to reflect and think about where we as an IT community are heading.

I’m going to post a series of blogs on where I think the industry is going, from applications down to infrastructure. Some of this is pretty far out there, but it’s good to stretch a bit and see where it takes you.

I’m hoping the readers of my blog will get engaged. Agree, disagree, but don’t ignore, as I think we are in the midst of a revolutionary change in how applications are sold, delivered, deployed and managed. This change is happening rapidly. We’ll make a lot of mistakes along the way, but I’m convinced we’ll get it right and change the way we look at IT forever.

So, stay tuned for the first entry, coming soon….

On my mind…

I’ve finally put my virtual pen to paper to contribute to our growing blog! I’m Vern Brownell, the founder of Egenera. I was an IT infrastructure customer eight years ago when I decided to create Egenera.
The inspiration for our technology was the frustration that I had with the complexity and brittleness of the computing infrastructure that had been built up in our data centers. The incumbent vendors seemed to lack interest in reducing complexity and were quite happy to sell more servers and infrastructure to exacerbate the problem. A light bulb went off for me and I decided that there was an opportunity to build a company around an architecture that would use virtualization and abstraction to simplify and dramatically improve the agility of data center infrastructure.
My view was that the server environment and the associated infrastructure needed to be simplified first. We took a clean sheet of paper design approach and set out to build the PAN Manager architecture that our customers use today.

I’ve been following the news from LA regarding the Chino Hills earthquake story. Events like this remind of how fragile our lives are. And how fragile our systems and infrastructure can be. Thankfully, this earthquake seems to have been of limited impact, but our thoughts and prayers go out to those who have been effected.

Last month I was in China and was impressed by the universal support and sympathy that poured out from around the world for the victims in Wenchuan, southwest China. Compared to the tragic loss of over 69,000 lives, the loss of infrastructure and systems seems trivial. Nonetheless, it was another stark reminder of what can happen.
I recall that in data center threat analysis that I participated in years ago, earthquakes always seemed to rank as one of the most probable disaster events in earthquake prone areas followed by floods, fires and terrorist events. USGS reports that so far for 2008, there have been 269 earthquakes per month measuring 2.0-5.9 in magnitude in the US. Worldwide, there have been 2261 per month of the same magnitude.
As a former customer, I found providing adequate Disaster Recovery and Business Continuity Planning to prepare for events like earthquakes to be one of the hardest parts of running an enterprise IT shop. There are, of course, many issues which are not technology related, but technology is always an important part of business continuance planning. The classic rapid recovery method that most people seem to use is to provide duplicate hardware at two geographically diverse with some sort of data mirroring between sites. This method can work very effectively, albeit at significant cost and complexity. The lesson that I learned is the frequent testing is absolutely necessary and in fact in many or perhaps even in most cases the tests will not complete flawlessly.
Many of my friends and colleagues in IT in NYC and DC had to exercise their BCP plans with the terrorist attacks of 9/11. Although I was no longer in the IT business in NYC and I did not experience this tragedy first hand, I’ve heard that most firms that had this style of DR did quite well with their recoveries. So what’s the problem? It really comes down to expense, complexity and power.
The classic method requires a significant duplication of hardware, furthermore each time a system is changed in the slightest way, the backup system must also be updated. This is error prone. Most of the failures that I have seen were the result of misconfiguration of infrastructure or applications. It takes tremendous effort to keep two systems in complete sync. It’s always a tough investment to prepare for something that hopefully will never happen. And given the nature of the costs and effort, this type of backup is almost certainly only done for the most critical of applications.
Imagine a solution that would allow for automated synchronization of hardware, network and application changes. Imagine a solution that would allow for the backup of multiple sites with one set of backup hardware. Imagine a solution that could provide this type of automated recovery for applications which are both physical and virtual (running with or without a hypervisor). Egenera PAN customers can do this today and are able to test their recovery with frequencies that provide a much better guarantee that things will work in the event of a real disaster.
Some of our customers back up all of their applications regardless of their criticality, just because they find it can be a small incremental cost to add full DR to a broader spectrum of apps. It’s really the PAN architecture that makes this a simpler, faster and more reliable process.
On a totally unrelated note, I’d like to make a quick comment on Diane Green’s departure from VMware. I think Diane and her team have done a fabulous job of building a great software company in record time. She has been an inspiration to many of us in the technology business and I wish her the best of luck in whatever she decides to do next. I’m a big fan of hers and I look forward to seeing what’s next for her.
Thanks for listening. In further posts, I’d like to explore some of the data center trends and challenges that I hear from our customers and partners all the time. I’d also love to know what’s on your mind!

Yesterday marked what can perhaps be seen as an end to an era with the departure of Diane Greene from VMware. The company’s brilliant and meteoric growth, and its dominance in the “Server Virtualization” space cannot be denied. In some ways, we can all thank VMware for shining a brighter light on how customers can reap the benefits of virtualization in a broad sense. The awareness level for the word “virtualization” has never been higher or more meaningful. The next step is to expand what it means and what it will mean in the future.

As we all know though, the landscape is shifting. Not just for VMware (Hyper-V on the horizon, Red Hat embedding Xen-based hypervisor into its next distribution release, etc.) - but for every company that plays here - from the data center to the desktop. I hear more and more customers asking, “what’s next?” and “how can I extend the concepts of virtualization deeper into my organization?”

For Egenera, we answer that question by taking customers to the next phase of virtualization - allowing them to extend virtualization to their physical servers, their business and mission critical applications, and their DR processes.

I hate to speculate on “hype cycles” but perhaps as we look forward, we’ll begin to hear a louder drum beat for “what’s next?”

10 Gigabit Ethernet has brought tremendous excitement and potential for big change in the datacenter I/O infrastructure and connectivity. Everyday, we are being bombarded with new terminologies and buzzwords like DCE (Data Center Ethernet), FCoE (Fibre Channel over Ethernet), CEE (Congestion Enhanced Ethernet), CFE (Congestion Free Ethernet), Unified Wire, Converged Fabrics, etc.

So, what is so special about DCE?

DCE’s promise is use a single Ethernet interface on the server for all the types of traffic (i.e. SAN, LAN, IPC, etc.). The cost of managing and administrating multiple separate networks for LAN and SAN has already become prohibitive in large enterprise datacenters. I’ve seen data from IDC that predicts the cost of management and admin for a server will be 65% of total cost of ownership in 2010. 10G Ethernet provides enough bandwidth to converge and consolidate all of a server’s network and storage traffic out of a single spigot. Users love Ethernet’s high degree of plug-and-play and ease of use. What classical Ethernet MAC layer protocol lacks is delivery guarantees, control over jitter, and decent Layer 2 QoS. This is what DCE brings to the party.

Most, if not all, DCE changes are being standardized in 802.1 Ethernet Bridging standards body of IEEE. There is much coverage on the web on the details of Ethernet facelifts to make it DCE ready, so I will not elaborate much on those here. DCE will benefit not only data centers, but any application that relies on a reliable L2 transport. Most of the enhancements are intended to make Ethernet switches and NICs have more predictable behavior under load and congestion. It also provides a finer grain link level control over different traffic classes traversing the LAN. Ethernet is really a best effort connection-less datagram protocol. Retransmissions above L2 can be expensive and impact performance, especially when you talk about SAN protocols like Fibre Channel that rely on link level congestion management. Even high performance iSCSI which uses TCP congestion management can experience performance issues if the network and the IP stack are not properly tuned and architected.

Looks like vendors are mainly implementing DCE features in their second generation 10 Gb/s NIC and switch products and are not even bothering with the older 1 Gb/s technology. The IEEE802.1au/az work is starting to gel, and semiconductor and system vendors alike are feverishly trying to be first to market with their version of “almost standard” products.

For me, it has been interesting to watch all this excitement about convergence. While the rest of the world is just now learning about the economics and benefits of convergence on unified wire in data centers, we have been delivering and demonstrating the TCO benefits of converged fabric server products for over 8 years now!

Clouds are forming

I’ve been reading a lot about cloud computing lately. Seems like everyone has an opinion. One of my favorites was an interesting comparison on the buzz (measured by Google Trends) that Cloud is getting compared to Utility, Grid, etc.

Me personally… I’m still trying to grok what it all means. Seems to me that Clouds are Grids spiced with virtualization. Grids were great for serving up raw resources for clustered applications or like-minded apps that access the same storage or networking infrastructure. However, they are limited when a user wants to share the grid for dissimilar applications - e.g. ones with differing storage needs or HA needs. With a grid, you basically paid for the whole thing whether you need all the capability or not. This restricts the types of applications you can land on a grid.

Now, add a bit of virtualization to the grid and the rigid boundaries seemingly disappear. Grid hardware can be partitioned using hypervisors so smaller apps can be placed on the grid. It also allows the grid to have a heterogeneous operating system policy, something you can do on a grid but only with great effort. This makes the grid more flexible - a Cloud?

The issues with storage and network access are still there, and while server virtualization can help a bit here, the reality is that the physical connectivity is still an issue. What’s next, an I/O Cloud?

So to me, a Cloud is a Grid with virtualization. Is that your view? I’d be curious to see if someone has a good definition of a Cloud that can stand on its own.

We have just rolled out our updated blog. Please visit us at http://blog.egenera.com/ and update your feeds directly by subscribing at http://feeds.feedburner.com/EgeneraVirtualizationBlog.

Dan Kusnetzky asks an interesting question on his blog, “What is virtualization 2.0?”

Is it a catchphrase? Is it a new term that analysts can cling to? Is it a re-hash of technology from 20 years ago? Is it new?

I think the answer to all of these questions is yes!

Yes, it’s a new category that analysts (most notably IDC) have been pushing and yes, like all virtualization technologies, it’s an extension of what was delivered on the mainframe many years ago, just on commodity processors.

The interesting question, to me anyways, is “is it new?” Taken literally, even that is not that interesting. I think what Dan is asking is – is this really new technology that will have a material impact on how data centers are managed? If not, then it’s just another marketing term that will fall by the wayside in due time.

I think it is “new.” It’s really an evolutionary step in the virtualization of the data center. And yes, the technology will sound familiar to the mainframe crowd, but the data center is so much more than mainframes today. Virtualizing the data center means virtualizing servers and infrastructure across the data center, including commodity servers.

If Virtualization 1.0 is defined as virtualizing the server – think hypervisors like VMware and Xen, then Virtualization 2.0 is the natural extension to the infrastructure surrounding the server. Why does this matter?

It matters because the entire story can’t be told until all the components in the path of – pick your favorite name; utility computing, ubiquitous computing, agile IT, etc. – must be virtualized. This is critical. In order to create a truly dynamic data center, applications must be able to run on any server, at any time, with guaranteed service levels. To do this, the infrastructure must be as flexible as the servers. This is Virtualization 2.0. Creating a flexible, dynamic, fluid infrastructure to match the servers ability for the same.

Again, this is evolutionary, and it doesn’t stop at 2.0. Once the infrastructure is virtualized, we need to deal with other parts of the stack that that are inflexible. Dan writes a follow up blog examining the barriers to V2.0. He’s spot on, though I see these as Virtualization 2.0+ and the next step in the natural evolution to make the data center more dynamic.

Older Posts »