Telematique, water and fire.

AWS EC2 gets more real(world)

The Amazon Web Services blog has announced some additions to Amazon EC2 that make it all that more viable for real world, production operations.

We just added three important new features to Amazon EC2: Elastic IP Addresses, Availability Zones, and User Selectable Kernels. The documentation, the WSDL, the AMI tools, and the command line tools have been revised to match and there's a release note as well.

...

The Elastic IP Addresses feature gives you more control of the IP addresses associated with your EC2 instances.

...

Availability Zones give you additional control of where your EC2 instances are run. We use a two level model which consists of geographic regions broken down into logical zones. Each zone is designed in such a way that it is insulated from failures which might affect other zones within the region.

...

Finally, the User Selectable Kernels feature allows users to run a kernel other than the default EC2 kernel. Anyone can run a non-default kernel, but the ability to create new kernels is currently restricted to Amazon and select vendors.

EC2 becomes more viable as a commercial grade, virtual data center utility with each new feature. I'll be interested to see what this does to the service's adoption by both corporate IT and SaaS players with SLAs to maintain.

HP's Data Center Transformation ... don't forget the network.

Reading through some of the articles commenting about HP's announcement of the their Data Center Transformation initiative, I came across this rather odd bit from Arthur Cole at IT Business Edge. He mentions that he's had the opportunity to speak with John Bennett, WW Director of Data Center Transformation Solutions at HP. After setting the stage for the conversation, he makes the point that, too often, data center refurbishments are done to meet short-term goals, and distinguishes HP's approach as being a good deal more strategic.

“Rather than think of it as one massive project, we’ll develop a strategic view first, and then use individual projects over time to build out the next-generation data center,” Bennett said. “You’ll achieve your tactical objectives on particular projects, but you’ll also lay out the foundation for years of compounded returns.”

Sounds right, and then Cole points out what, to him, seems problematic.

... About the only flaw in the plan that I can see is a lack of network support. With server, storage and virtualization as part of the mix, I was a bit surprised when Bennett said he hasn’t had many dealings with HP’s networking unit. It seems unlikely that a series of ProCurve switches couldn’t be brought in should the need arise, although that need could be substantial given the level of virtualization and consolidation that uses are likely to require. It might make sense to make networking a more integral part of the strategy.

(.... pregnant pause..... raised eyebrow.)

VMware: All (ok, some) your access network are belong to us.

Colin McNamara and Scott Lowe, two bloggers from Eplus Technology, have been doing an excellent job of pointing out the network gap created by VMware. McNamara, in a recent post, sets out the problem very well:

... Your access layer is no longer a top of rack Cisco switch, or end of row aggregation chassis. It is now a virtual bridge that exists logically within your VMware ESX server.

This causes an interesting question to come up in many customers - Who is responsible for the configuration and maintenance of this Vswitch?

...

We no longer have this well defined edge at the access layer. The access layer now exists virtually inside a server. More specifically, it is a logical devices running in a Linux server. This presents a challenge because it requires cross over knowledge. Whoever is responsible for this integration has to be fluent in Linux systems administration , and also fluent in network design and operations. Frankly this is a rare skill set to come across, as it requires and engineer who has attained high proficiency in both systems and network engineering.

I see this fuzzy line of demarcation often as a failing point for many VMware integrations. Many times I see network operations teams not involved in ESX cluster design because its a “server” , and systems operations teams generally don’t have the networking skills necessary to design and implement an fully functional system.. The solution to this problem is education and collaboration. ...

I'm not convinced that the solution to the problem lies only in "education and collaboration". It's the central, defining issue around which Replicate's products are being created.

HP and IaaS

Somewhere behind the shock of JPMorgan Chase buying Bear Stearns for $2 a share, there's the HP launch of a well considered Infrastructure as a Service (IaaS) offering.... a virtual data center for enterprise class computing. Larry Dignan and Dan Kusnetzky do a nice job of summarizing the announcements.

As for the competition, what caught my attention is Dignan's reference to the Forrester Research list of players. With the exception of Amazon's AWS (which has some heft but appeals to a long-tail part of the market), that list of Cloud Providers looks terribly thin... not exactly what I'd call competition for enterprise computing offers. Sorry... this is a not yet a competitive market ... not by a long shot. HP's stolen a march on everyone, with the possible exception of those parts of the ecosystem we rarely hear about ... the big services outfits like T-Systems and their Dynamic Services for SAP Applications. That's the competition.

I'm looking forward to digging into the details of HP Insight Dynamics - VSE and Operations Orchestration, the software enhancements HP is really going to deliver. The (rhetorical ?) question continues to be asked as to whether "... business will bite on data center in the cloud?" (to use ZDNet's turn of phrase). My simpleminded analysis says that, given its current reliance on in-house data centers, enterprise IT can't and won't rely on virtual data centers / outsourced data centers until they have a technical and operational means of integrating both forms in a (dare I say it?) form of infrastructure collaboration.

The idea is that, when reallocating load for a SAP application or scaling out to meet the requirements of the end-of-month analyses, the systems which manage the application should be blind as to whether the resources are in the cloud or in the enterprise data center. This ability to span or bridge the in-house and outsourced data center operation is almost impossible today unless the data center infrastructure is purpose-built for just that kind of operation. The solution relies on interoperability of the outsourced service and in-house data center: they must both operate as utilities and have the same or compatible infrastructures.

Perhaps, if HP's offer gets adopted by enterprise for the in-house, next generation data center, they will create a demand for their IaaS . That strikes me as a limited market. Rather than a single infrastructure technology on both service side and in-house side, the necessity is one of "compatible" or communicating infrastructures. In order for collaborative data center infrastructures to come about, a piece of network virtualization infrastructure needs to come into existence.

Free ESX 3i?

Virtualization.info has a post that appeared yesterday about the alleged VI3i giveaway by Dell. They cite the article that appears in the Inquirer , which (in turn) cites Martin Niemer, senior product marketing manager at VMware. In commenting on the approach, they state

If confirmed this decision will have a serious impact on the sales channel.

On one side other OEMs that have a distribution agreement with VMware (HP, IBM, Fujitsu and other) will be almost obliged to do the same to not give Dell any competitive advantage.

On the other side the VMware distributors and resellers will see their chances to sell ESX Server in the SMB market fall down near to zero.

It was expected that over the next few years VMware would lower the price of its hypervisor to compete with Microsoft aggressive strategy (the upcoming Hyper-V will cost $28) but it certainly wasn't expected so early.

Is this the beginning of the free hypervisors era?

Virtualization Risk and the Fishtank

I missed this article in CIO (Top Ten Virtualization Risks Hiding in Your Company) when it was published about a month ago. After running through a believable list, I looked at one of the comments and couldn't help but smile:

... I think the comments above missed risk #11, the physical world outside any hypervisor host.

All hypervisors still depend on underlying physical machines being correctly connected to network and storage -- in multiple paths, to allow access for all VMs correctly.

In other words, all the above article comments apply to moving around the virtual machine "fish" inside the hypervisor OS "fishtank" -- but who moves and manages the associated fishtanks (with associated network & storage I/O plumbing etc)?

Kevin Epstein (of Scalent) then goes on to set out a number of additional problems, and although he makes sure to inform the reader that (in his opinion) Scalent solves these problems, I have to agree with the problem identification (if not completely with his solution):

1. Network connectivity matters
All hypervisor hosts in a group or "cluster" who are going to share virtual machines -must- share a LAN subnet.

2. Storage access matters
All hypervisor hosts in a group or "cluster" who are going to share virtual machines -must- share storage access.

3. Hardware failover must be anticipated
VMs will fail to another clustered hypervisor... if, and only if, one exists and has cycles! (See point 1 and 2)

4. Movement between Physical and Virtual (and back, repeatedly) is a necessity in real data centers, and is -not- usually seamless ...

5. Non-x86 Hardware
Not all hardware is x86! Sun now has LDOMs, AIX too, how to manage workloads between those and the rest of the virtual universe?

VMsafe and the Network Stack

Gabe has collected information from various sources about VMware's VMsafe API. The post makes clear VMware's approach to "opening up" access to the hypervisor for third-party security products provided by carefully vetted partners. In a comment to the post, the reader is pointed to VMCI as a the means by which VMsafe gains access to memory and other hypervisor resources. Gabe then makes this rather telling response:

I’m missing the network stack in this, because I read that the network virtual switches can also be monitored with VMsafe. I’m wondering if for example McAfee can build an appliance that does some kind of virus scanning, checkpoint builds a network inspection appliance, etc. You would then have multiple security appliances per host. Not sure if this is what is desired.

Is this the case? Does VMsafe offer up access of this kind to the vswitch? Does that mean that the as-yet-unannounced, but rumored third-party virtual distributed switch would offer up the same access through VMsafe?

Adjusting the risk/reward dial.

Running a small (... OK, Oren... tiny) startup means that during the week I run windsprints.  On Saturday mornings, catching up on Google Reader (1000+), I get to stroll leisurely through the RSS, while (in the background) all my machines backup to the NAS.

Reading this reminds me of the times I've thrown my lot in with a bare-metal startup. The post mentions serendipitous moments, and I can attest to the fact that you'll never encounter more of them than while doing a startup. It's one of the great pleasures. 

All stages of a company have benefits.  I continue to be most thrilled, enjoyably challenged, and most engaged at this stage.  This is the phase in which I learn most, and for which I have the warmest memories.  Wecome, Oren.

Link: Ontic Oren � Modifying my own risk/reward.

Virtsec - Looking up from Layer 4

Greg Ness recaps VMworld Europe's VMsafe announcement, and relates it to the future of virtualization security (virtsec). As a bit of imagery, he links the future of the virtualized production data center to the "upstack (layer 7) server" and its overshadowing the "operationally-intensive layer 4 world of deep packet inspection, signatures and tuning." Nice turns of phrase. They set me thinking about how to characterize those aspects of the virtualized data center which must provide visibility into and the reduce complexity of layers 3 and 2 (... notice the ordering sequence based on the point of view). My initial take is that they deserve a different set of metrics and viewpoints that, as well as Greg's when considering security. More as I tease these out.

VMworld Cannes: Au Revoir Layer 4 - Seeking Alpha

When VMware announced VMsafe at Cannes it marked a major data center security milestone on many levels: 1) it was the first major public statement on virtsec by any virtualization platform vendor; 2) it represented the first glimpse of how virtsec will change the netsec game; and 3) it articulated the key differences between what VMware will protect and what its partners will protect.

That combination of vision and clarity against a backdrop of 20 enlisted security vendors was the equivalent of a high level declaration of independence from the hardware-centric network security appliance model that took off with the emergence of fame-seeking hackers in the late 90s and early 00s. It was also a critical launch component of VMware’s push into the data center. Among the leading security players teaming up with VMware: CheckPoint, McAfee and Symantec.

...

The faster that VMware virtualizes the production data center, the faster the virtsec industry will accelerate. Given VMware’s momentum and now its high profile position on security (and the positive reaction of VMworld attendees), it seems likely that upstack (layer 7) server and VM security are about to rock and roll the tired, operationally-intensive layer 4 world of deep packet inspection, signatures and tuning. VMsafe has set in motion a security revolution that will indeed advance the cause of data center security beyond the common expectations of older generation architectures.

More on VMsafe from Chris Hoff

Chris Hoff has a very good (and entertaining) post about the impact of VMsafe on the providers of "Firewalls, IDS/IPSs, UTM, NAC, DLP" ... a sector that he considers as being on life-support and suffering from a severe case of consolidation.

To his point about VMware's willingness to sign on new partners, I'm still at some pains to find out just how open/public the VMsafe API will be and on what time frame. Does anyone out there have definitive information on this? Any of the existing VMsafe partners willing to talk about it?


Rational Survivability: VMWare's VMSafe: Security Industry Defibrilator....Making Dying Muscle Twitch Again.

... VMSafe represents a huge opportunity for these vendors to claw their way back to life, making their solutions relevant once more, and perhaps even more so.

Most of the companies who have so far signed on to VMsafe will, as I mentioned previously, need to align roadmaps and release new or modified versions of their product lines to work with the new API's and management planes.

This is obviously a big deal, but one that is unavoidable for these companies -- most of which are clumbsy and generally not agile or responsive to third parites.  However, you don't get 20 of some of the biggest "monoliths" of the security world scrambling to sign up for a program like VMsafe just for giggles -- and the reality is that the platform version of VMware's virtualization products that will support this technology aren't even available yet.

I am willing to wager that you will, in extremely short time given VMware's willingness to sign on new partners, see many more vendors flock to the program.  I further maintain that despite their vehement denial, NAC vendors (with pressure already from the oncoming tidal wave of Microsoft's NAP) will also adapt their wares to take advantage of this technology for reasons I've outlined here. ...