Telematique, water and fire.

Enterprise Virtualization and the Problems of Management

For the most part, I've found the Toutvirtual posts by Schorshi overdone with respect to rant and vitriol directed at the "big guys" -- VMware, Microsoft and (to some degree) XenSource.  I suppose it's possible that what comes across to me as stage-managed outrage is an effective way to address the failings of the major VMEs and put ToutVirtual's offerings in a good light.  I don't usually find the posts enjoyable.  However, in catching up this afternoon with some of my reading, I picked up on this summary of the issues facing enterprise computing's management of VMEs.  If you can get past the flaming, there's substance here.

ToutVirtual Enterprise Virtualization - A Proper Virtual World

...
Defining terms for a moment, an enterprise customer, for the sake of discussion is one that has more than 100 virtual servers and more than 1500 virtual instances. However, the issues to be discussed do cause real pain to customers below that level, even if someone only has 10 virtual servers and maybe 100 virtual instances, it is ugly. Virtualization was supposed to, at least in part, make management of virtual instances easier, if you listen to the sale teams, the term easy is used, not easier, which is arguably somewhat more accurate. This is misleading, because management of virtualization is complex, and creates its own set of issues. I have already discussed these issues in the past, so I will not do so now, but the short list is:
* Pre-provisioning
* Appropriate charge-back or costing
* Configuration Management
* Monitoring and Alerting
* Trending and Analysis

Anyone familiar with virtualization at a practical level, beyond a simple lab/test environment, will see these pain points as valid, and I am sure many of you will or do have more to add. However, to illustrate why, Microsoft and VMware have both missed the entire enterprise customer view of virtualization, continue reading. ...

Powered by ScribeFire.

The Missing Piece in Cloud Computing: Middleware Virtualization

This is an interesting piece about the role of middleware (the "classic" tiers and APIs) and of virtualization in attaining the real benefits of utility computing and Cloud Computing (though I'm still hardpressed to distinguish the two terms in a meaningful way). 

What caught my eye particularly is the approach they've taken at Gigaspaces to virtualization for the application container. This notion of bundling and consolidating the logic needed to enforce SLAs and simultaneously meet the requirements of the application architects is an approach for which I have great respect, and which we're employing in our efforts regarding network virtualization at Replicate Technologies.

Nati Shalom's Blog: The Missing Piece in Cloud Computing: Middleware Virtualiztion

...
In the current server-centric world we use middleware to provide common infrastructure services, such as application containers, data and messaging. To make that same model work in a cloud environment we need to virtualize all of those components. That is, we need to virtualize the container, the data and messaging. By doing so we abstract the application from the fact that it is running on a "cloud" and make the transition from a server-centric model to cloud computing relatively seamless. How do we achieve that?
...
The SLA-driven container takes an application bundle and manages the deployment of that bundle over a set of containers based on Service-Level Agreements. The SLAs define the clustering topology (e.g., partitioning, size of the application pool, scalability, fail-over policies, etc.). It is used to map the available physical compute resources to the application needs. It is also used to provide self-healing capabilities to our application. For example, we can set an SLA to ensure that at any point in time we always have primary and backup instances for each node in our environment - and that each node's primary and backup must run on separate physical machines. In case a primary fails, the system will dynamically set the backup as the new primary, and will launch another backup on another machine.

Powered by ScribeFire.

The new challenges for your network management software

Peter Williams of Bloor Research does a nice job of describing the issues facing IT's management of networks as well as the vendor's challenges in delivering the right network management systems.  The piece then goes on to be a plug for Entuity's 'Eye of the Storm' network management suite, but it's done in this context. The advertizing not withstanding, I liked the staging and premise on which it was written.

Stormy times for your networks? Time to re-assess your network...

Those who provide network fault and performance management software have been experiencing new challenges as technologies advance and new software emerges. Enterprises using network management software unchanged for only two years will be behind the curve; in fact the vendors themselves are struggling to keep up.

Think of the challenges. There is virtualisation—of the servers, storage pools and the networks—which builds in extra (hidden) layers of complexity in continually mapping the virtual to the physical. Various trends include a shift towards more server-based shared applications and content management, service-oriented architecture (SOA) and software as a service (SaaS). Conversely, there is also peer-to-peer networking, as well as converged data and voice sharing the same wire, and wireless networking for both.

Powered by ScribeFire.

Yankee Group gets religion about Virtual Appliances from ISVs

Given the amount of web-space that's been dedicated to virtualization, soft appliances in general, and virtual appliances, this seems a bit of a let-down.  The point is, of course, that they're correct.

What few people seem to be talking about, however, is the role virtual appliances will play as the delivery mechanism of choice for network appliances.  Think about this for a bit.  I've been spending a lot of time on it lately. The results are some startlingly different ways to think about network function and the OAM&P (operation, administrative, management and provisioning) functions.

Yankee Group Says ISVs and Customers Will Reap Tremendous Benefits from Virtual Appliances : VMblog.com - Virtualization Information

As virtualization progresses and the concept gains acceptance, virtual appliances may become the predominant and only platform for ISVs. Some of the benefits of virtual appliances for ISVs and customers are:

• Lower support costs: Supporting a myriad of customer OSs, all with different versions, patch levels, and configurations is becoming a support nightmare.
• Better quality software: By removing the variables of customer-installed and -configured operating systems, ISVs can have complete control of their software operating environment.
• Easy scalability: Virtual appliances can easily be moved to a faster machine.
• Quick deployment: Virtual appliances plug into existing virtual infrastructure and come pre-installed, pre-configured and ready to start.

Powered by ScribeFire.

Componentizing IOS!! But ... when?

Cisco's reorganization of the development group is truly significant.  If the company can actually commit to this self-administered genetic engineering ... no mean feat ... they have my admiration.   I spent a day or two this past week thinking about it, and wondered what I would consider a clear indicator of commitment to the new path.  Well, folks, this is it... opening up IOS.

This is a game-changing move for the company, but only if it's a timely move.  How quickly will they do it? How quickly can it be done?

Cisco opening up IOS - Network World

... "It's a significant step forward for us," said Don Proctor, senior vice president of Cisco's newly formed Software Group, at last week's C-Scape 2007 analyst conference. "Software turns out to be a key way that we can do what [we've] been talking about for some time, which is link business architecture to technology architecture in a meaningful way."

Cisco plans to "componentize" IOS – developing only one implementation of a specific function instead of several, depending on the image – dynamically link IOS services and move the software onto a Unix-based kernel. Cisco then plans to open up interfaces on IOS to allow third-party and customer-developed applications to access IOS services.

However, no timeframe for doing so was provided.
...

Powered by ScribeFire.

Fluidity, integrity and security

James Urquhart points out an interesting aspect of the conversation I've had with Greg Ness about network security and network integrity in a virtualized environment.  I got on my soapbox about network integrity, primarily to call attention to the issue, and (as James correctly assumes) not without a healthy dose of respect for the importance and role of application architectures.

As we (at Replicate Technologies) drilled into the issues of application safety in the virtualized environment, we've had the opportunity to speak with a number of application architects, VME administrators, and a few (just a few) IT managers responsible for network operations.   What's striking is the fact that even though VMware goes out of its way to simplify virtualized network issues (by limiting the power / complexity of the virtual switch that you'll find in every ESX box), many of the application folks tend to use only the most simple approaches.  They work, but with some severe limitations on the safety and scalability of the VME installation. 

So, to James' observation about my over-emphasis, I'd say: You're correct. I don't believe that one relies on infrastructure to keep the whole application running as the VMs comprising that application are moved around the network. My emphasis comes from the realization that network integrity -- getting the infrastructure "right" -- is a necessary requirement, and one that the application architects seem often to ignore when considering applications living an a virtual machine environment.  It's necessary, but certainly not sufficient.

In a conversation this week with my co-conspirators at Replicate, Rich Pelavin recalled Saul Steinberg's famous New Yorker magazine cover of the world as seen from Ninth Avenue.  If you ask the application architect to map out the implementation, there are lots of servers, multiple interacting processes, each with exposed ports and interfaces, and they all connect with one another (and the rest of the 'net) by connecting to an undifferentiated network represented as "the cloud."  Treating the network as a dumb pipe is not just counter-productive in a virtualized environment... it's dangerous. 

(To be fair... the network architect and IT guy responsible for network management sees the world as a lot of network appliances and elements interconnected at specific ports.  They may not even recognize the existence of the server hardware, much less the applications!! )

As for James' request to hear about what Replicate Technologies advises its customers about application architectures ... stay tuned.   We're focused on delivering network integrity -- that is, network integrity that applies to the combined virtual and the physical networks. That necessarily implies that we employ a means of considering applications as "VM flocks" and providing the means of operating on them as a unit.  I'll leave it at that for now.


Service Level Automation in the Datacenter: Software fluidity and system security

... Here is exactly where I believe application architectures are suddenly critical to the problem of software fluidity. In a well contained multi-tier application (a very turn-of-the-millennium concept) it is valid to consider the migration of the "flock" as a network integrity problem. However, when it comes to the modern world of SOA, BPM and application virtualization, suddenly application integrity becomes a dynamic discovery issue which is only partly dependent on network access.

In other words, I believe most modern enterprise software systems can't rely on the "infrastructure" to keep their components running when they are moved around the cloud. Its not good enough to say "gee, if I get these running on one set of VMs, I shouldn't have to worry about what happens if those VMs get moved". Rich hints strongly at understanding this, so I don't mean to accuse him of "not getting it". However, I wonder what Replicate Technologies is prepared to tell their clients about how they need to review their application architectures to work in such a highly dynamic environment. I'd love to hear it from Rich.  ...

Powered by ScribeFire.

Security 3.0 and the Perimeter Myth

Greg Ness regarding the myth of security at the perimeter.  Continuing the story about how we really need to concern ourselves with VirtSec and  "the soft middle", and not just the perimeter.

Security 3.0 and the Perimeter Myth | AlwaysOn

Over the last few weeks I’ve been talking to analysts and security pros about virtualization, security and the evolution of netsec to virtsec. Last week I was in Los Angeles on a virtualization panel at the InformationWeek Virtualization Summit and then in NYC on a MISTI panel on virtsec.

As a result of several discussions, I’ve come to the conclusion that for many organizations their network really doesn’t have a perimeter, at least in the classic sense of defense. The idea of a strategic point of defense that protects what is inside has become a legacy myth, an anachronism from the early days of netsec and fame-seeking hackers.

...

THEN WHAT'S NEXT FOR NETSEC?

In the short term the netsec hardware vendors MUST announce a virtsec product in 2008. Being late to the party will cost them substantial vision and revenue growth points. As I commented before, these 2008 virtsec announcements will likely be vapor ware because of the substantial difficulties in moving from signature processing (usually ASIC) “architecture crunch” to massive hypervisor footprints. Maybe these products will be broken into multiple parts in order to lessen the load on individual servers and avoid massive processing burdens. Maybe they’ll find a creative way to exploit the hypervisor layer from afar? Either way, they are in a world of computational disadvantage until they understand the nature and weaknesses of the applications they are defending. ...

Powered by ScribeFire.