This week I was able to attend the Wisconsin VMUG UserCon. In the past I was always hesitant to go to these as I assumed that I wouldn’t be able to learn anything new. I always figured I know what I need to know technically, what am I possible going to encounter that will increase my technical knowledge. In other words, rightly or wrongly I was focused on only my technical growth. This year I was excited about the UserCon, partly because I got a bit of recognition in front of the crowd from none other than Pat Gelsinger, but mostly for the opportunity to sit through a couple of sessions or have conversations with people to gain insight on the challenges and struggles they are facing and trying to figure out how to take that perspective to my benefit.
During the VMUG UserCon there were several take aways from the day that I found extremely useful and wanted to share.
Brian Kirsch did a fantastic session about architecture questions you should think about, but probably haven’t. In that session he detailed a lot of things that at first glance appear to be counter intuitive: running production VMs on the same hosts as non-production VMs, to allow for a reduced potential impact during host failures (amonth other reasons). The average HA load is lower if you divide 375 (250 prod, 125 non-prod) VMs among 15 hosts, instead of 10 and 5 hosts – you have less VMs being restarted per host. I got the impression from Brian’s session that he brought a lot of experience to the table when it comes to squeezing extra value out of the things you have, which is a great lesson we can all take and benefit from. Budgets are tight, timelines are tight, being creative may allow you to do things you didn’t expect to.
It Doesn’t Have To Be Flashy
At lunch I had two great conversations, one of them was with an Architect with a Fortune 500 company, and it was surprising to see the simplicity with which he was approaching his environment. During the conversation it came out that the environment he supported didn’t include self-service function, he didn’t see it coming, no Kubernetes, no public cloud footprint, etc. It’s easy to go through these conversations and think – “This place is either backwards, or this person is out of the loop.” and discount the entire discussion. When in fact it’s just as likely to be the opposite, it’s an IT organization that understands their business needs and focuses on meeting those instead of driving the business to technologies and capabilities it does not need. When you dissect that conversation with that perspective, it becomes a lot more valuable and you can grow from it by freeing yourself to ask probing questions about their needs and the decisions they have made and that they plan to make.
Small things make big differences
My other lunch conversation was with a systems administrator for a medium-sized municipality. The topic of salting and/or Transparant Page Sharing came up, which was something he was completely unaware of the potential memory savings from it. Turns out he was working on building/delivering a 400 seat VDI environment, and was struggling with memory subscription concerns. While TPS is a big topic, he was incredibly excited about the potential to alleviate some of his capacity issues without dipping into an already taxed budget.
You may be missing information
This stems not from the UserCon, but personal real life experience this week. Often we face decisions that affect us and have the potential to trigger an emotional reaction. Rather then let the reaction overtake us, it’s important to take a step back and dig for details, context, and perspective before rushing to judgement and letting reactions get the best of you. It’s easy to ask questions, but it’s difficult to roll back reactions.
Prototype, then ask
This observation was from the fireside chat I was able attend between Pat Gelsinger, VMware CEO and Tom Hardin, Harley-Davidson CTO and it amounted to that we live in a day and age that it’s incredibly easy to build a prototype of an idea, which coupled to the adage of a picture is worth a thousand words; don’t walk into a meeting with a leader with a proposal. Walk in with a prototype, show what you would like to do and prove that it’s something you can do.