Virtualization networking strategies…

I was asked a question on LinkedIn about the different virtualization networking strategies from a host point of view. The question came from someone who recently had 10GbE infrastructure introduced in to his data center and the way the network originally was architected was with 6 x 1 Gbps carved up in three bundles of 2 x 1Gbps. Three types of traffic use their own pair of NICs: Management, vMotion and VM. 10GbE was added to the current infrastructure and the question which came up was: should I use 10GbE while keeping my 1Gbps links for things like management for instance? The classic model has a nice separation of network traffic right?

Well I guess from a visual point of view the classic model is nice as it provides a lot of clarity around which type of traffic uses which NIC and which physical switch port. However in the end you typically still end up leveraging VLANs and on top of the physical separation you also provide a logical separation. This logical separation is the most important part if you ask me. Especially when you leverages Distributed Switches and Network IO Control you can create a great simple architecture which is fairly easy to maintain and implement both from a physical and virtual point of view, yes from a visual perspective it may be bit more complex but I think the flexibility and simplicity that you get in return definitely outweighs that. I definitely would recommend, in almost all cases, to keep it simple. Converge physically, separate logically.

Operational Efficiency (You’re not Facebook/Google/Netflix)

In previous roles, also before I joined VMware, I was a system administrator and a consultant. The tweets below reminded me of the kind of work I did in the past and triggered a train of thought that I wanted to share…

Howard has a great point here. For some reason many people started using Google, Facebook or Netflix as the prime example of operational efficiency. Startups use it in their pitches to describe what they can bring and how they can simplify your life, and yes I’ve also seen companies like VMware use it in their presentations.When I look back at when I managed these systems my pain was not the infrastructure (servers / network / storage)… Even though the environment I was managing was based on what many refer to as legacy: EMC Clariion, NetApp FAS or HP EVA. The servers were never really the problem to manage either, sure updating firmware was a pain but not my biggest pain point. Provisioning virtual machines was never a huge deal… My pain was caused by the application landscape many of my customers had.

At companies like Facebook and Google the ratio of Application to Admin is different as Howard points out. I would also argue that in many cases the applications are developed in-house and are designed around agility, availability and efficiency… Unfortunately for most of you this is not the case. Most applications are provided by vendors which don’t really seem to care about your requirements, they don’t design for agility and availability. No, instead they do what is easiest for them. In the majority of cases these are legacy monolithic (cr)applications with a simple database which all needs to be hosted on a single VM and when you get an update that is where the real pain begins. At one of the companies I worked for we had a single department using over 80 different applications to calculate mortgages for the different banks and offerings out there, believe me when I say that that is not easy to manage and that is where I would spent most of my time.

I do appreciate the whole DevOps movement and I do see the value in optimizing your operations to align with your business needs, but we also need to be realistic. Expecting your IT org to run as efficient as Google/Facebook/Netflix is just not realistic and is not going to happen. Unless of course you invest deep and develop the majority of your applications in-house, and do so using the same design principles these companies use. Even then I doubt you would reach the same efficiency, as most simply won’t have the scale to reach it. This does not mean you should not aim to optimize your operations though! Everyone can benefit from optimizing operations, from re-aligning the IT department to the demands of todays world, from revising procedures… Everyone should go through this motion, constantly, but at the same time stay realistic. Set your expectations based on what lands on the infrastructure as that is where a lot of the complexity comes in.

We are DevOps

devopsOver the last couple of months I have started running in to more and more customers who are wondering what that DevOps thing is they keep hearing about. They want to know if they need to start hiring DevOps engineers and which software they need to procure for DevOps. I more or less already alluded to what I think it really is or means in my blog post about The Phoenix Project, let me re-use a quote from the review that I wrote for that book:

After reading the book I am actually left wondering if DevOps is the right term, as it is more BizDevOps then anything else. All of IT enabling the development of business through operational efficiency / simplicity.

DevOps is not something you buy, it is not about specific tools you use, it is a state-of-mind … an operational model, a certain level of maturity. I would argue that it is just a new fancy way of describing IT maturity. At VMware we have had this professional services engagement called Operational Readiness where IT (Ops and Dev) and business owners would be interviewed to identify the shortcomings in terms of the IT offerings and agility, the outcome would a set of recommendations that would allow an organization to align better with the business demands. (This engagement has been around for at least 6 years now to my knowledge.)

Typically these types of engagements would revolve around people and process and focus less on the actual tools used. The theme of the recommendations generally was around breaking down the silos in IT (between the various teams in an IT department: dev / ops / security / networking / storage), and of course reviewing processes / procedures. It is strange how even today we still encounter the same types of problems we encountered years ago. You can deploy a new virtual machine in literally minutes, you can configure physical servers in about 10 minutes (when the installation is fully automated)… yet it takes 3 weeks to get a networking port configured, 2 weeks to get additional LUNs, 4 days to prepare that test/dev environment or even worse the standard change process from start to finish takes 6 weeks.

What is probably most striking is that we live in an ever changing world, the pace at which this happens is unbelievably fast and we happen to work in the industry which enables this… Yet, when you look at IT (in most cases) we forget to review our processes (or design) and do not challenge the way we are doing things today. We (no not you I know, but that guy sitting next to you) take what was described 5 years ago and blindly automate that. We use the processes we developed for the physical world in a virtualized world, and we apply the same security policies and regulations to a virtual machine as to a physical machine. In many cases, unfortunately, from a people perspective things are even far worse… no communication whatsoever between the silos besides through an ancient helpdesk ticketing tool probably, sadly enough.

In todays world, if you want to stay relevant, it is important that you can anticipate as fast as possible to the (ever changing) demands of your business / customers. IT has the power to enable this. This is what this so-called “Operational Readiness” was there for, identify the operational and organizational pain-points, solve them and break down those silos to cater for the business needs. In todays world the expected level of operational maturity is a couple of levels higher even, and that level is what people (to a certain extent) refer to when they talk about DevOps in my opinion.

So the question then remains, what can you do to ensure you stay relevant? Lets make it clear that DevOps is not something you buy, it is not a role in your organization, and it is not a specific product, it is an IT mindset… hence the title: we are DevOps. Joe Baguley’s keynote at the UK VMUG was recorded, and although he did not drop the word DevOps he does talk about staying relevant, what it is IT does (provide applications), how you can help your company to beat the competition and what your focus should be. (On top of that, he does look DevOps with his beard and t-shirt!) I highly recommend watching this thought provoking keynote. Make sure to sit down afterwards, do nothing for 30 to 60 minutes besides reflecting back on what you have done the last 12 months and then think about what it is you can do to improve business development, whether new or existing markets, for your company.

Sharing VMUG presentation “vSphere futures”

Last week I presented at the UK VMUG, Nordic VMUG and VMUG Belgium. My topic was vSphere futures… I figured I would share the deck publicly. The deck is based on this blog post and essentially is a collection of what has been revealed at last VMworld. Considering the number of announcements I am guessing that this deck is a nice summary of what is coming, feel free to use it / share it / comment etc.

Once again, I would like to thank the folks of the VMUG organizations throughout EMEA for inviting me, three great events last week with very passionate people. One thing I want to call out in particular that struck me last week: Erik from the VMUG in Belgium has created this charity program where he asks sponsors (and attendees) to contribute to charity. Last event he collected over 8000 euros which went to a local charity, it was the biggest donation that this particular charity received in a long time and you can imagine they were very thankful… all of this while keeping the event free for attendees, great work Erik! Thanks for giving back to the community in various ways.

See you next time.

Project Fargo aka VMFork and TPS?

I received some questions this week around how VMFork will work when TPS is disabled in the future, already answered some questions in comments but figured this would be easier to google. First of all, I would like to point out that in future versions TPS will not be globally disabled, but rather it will disabled for inter-VM page collapsing. Within the VM though pages will be collapsed as normal and the way it works is that each virtual machine configuration will contain a salt and all virtual machines with the same salt will share pages… However, each virtual machine by default will have a unique salt. Now this is where a VMFork’ed virtual machine will differ in the future.

VMFork’ed virtual machines in the future will share the salt, which means that “VMFork groups” can be considered a security domain and pages will be shared between all of these VMs. In other words, the parent and all of its children have the same salt and will share pages (see sched.mem.pshare.salt). If you have a different parent then pages between those VMFork Groups (both parents and its children) will not be shared.