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
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.
