VMworld 2016 Roundup: Day 4

Day 4 at VMworld. Phew. Feels like the end of the week already. We have a few sleeps left to go, so let’s carry on.

Solutions Exchange Sessions

I spent the morning in the Solutions Exchange, chatting with vendors and sitting in on a few vendor booth sessions. I stopped in on a SolarWinds talk, where they were giving an overview of how their products could be used to monitor vSphere. Palo Alto was giving a talk on integration with NSX, which was quite interesting, but unfortunately it’s not something I’m likely to touch for a while. NSX that is.

The presentation that peaked my interest most was a vExpert focused demonstration of Docker put on by Docker themselves. I had only just used Docker for the first time during the VMware{code} Hackathon earlier in the week. Having VMs vs. Docker explained using the metaphor of houses vs. apartments really helped make containers click for me. The walk thru of the deployment, modification, and build of a container illustrated for me the ways in which Docker can be used. It certainly wasn’t an exhaustive overview, as we only had so much time. However, now armed with more information about Docker and, even more importantly, a thirst to learn more about it, I think I’ll going to tinker with the project idea that team Ohhhh Snap! had striven to realize. Hopefully I’ll have something to share soon.

An Architect’s Guide to Designing Risk: The VCDX Methodology [INF9048]

Fellow Canuck Daemon Behr delivered a well designed session about designing for risk. He first explained what a framework is. A framework is a method of doing things that has structure, is repeatable, can be applied to many situations and is a guide, rather that a set of laws. A framework is actually most useful not for when things go right, but for when things go bad. When you have multiple critical failures, or you find yourself with no budget, no resources, or no staff, your framework will help guide you to what to do.

The VCDX methodology, which is espoused by the VCDX program in support of the VCDX defense itself, is, in fact, a framework. It covers areas such as availability, manageability, performance, recoverability, and security. As part of this method you need to consider all assumptions, requirements, risks and constraints. These will inform the design as you put it together. Sometimes in subtle ways, sometimes in very impactful ways.

One of the ways to deal with risk is with a survivability analysis. Daemon looked outside of the tech industry for examples, and came across the Kaplan–Meier survival curve, most commonly used in the medical field. Essentially it’s used to plot the survivability of something over its lifetime. Typically as things age, their chances of survivability decreases. This pattern holds true for technology, both hardware as well as software that is not maintained or upgraded.

Daemon advises to plan for failure. He proposed a defense in-depth approach, similar in concept to that used by security professionals. In this case, the layers are:

• a fail fast application architecture,
• fault tolerance components,
• high availability in software,
• ingress and egress load balancers, and
• application level clustering.

If you’re able to implement a solution that incorporates all of these layers you should end up with a solution that is well defended against risk. You should also strive to design your solution for graceful degradation, so that if a portion of the solution is impacted, the entire solution isn’t made unavailable, but instead may be running in some form of a lesser state.

Risk mitigation is like a rain jacket in a hurricane.
– Daemon Behr

Daemon cautions that risk mitigation strategies are flawed approaches. They will often prevent the worst scenarios from occurring, but can only prevent what’s known. Root cause analysis, a common approach within risk mitigation, is designed only to look backwards at what was, and doesn’t give a sufficiently forward-looking model. In order for risk mitigation to be successful, it needs failures to learn from, and these failures need to iterate quickly and frequently. This often is at odds with the needs of the business as they have a pressing need to keep services available to get their work done.

Another approach to consider is fault tree analysis. Fault tree analysis effectively tries to answer the question, how can I break my solution? You map out all the possible outcomes that can occur when each permutation of component failures occur. This allows you to find critical path divergence, which may point out which component is most vulnerable as it is most likely to contribute to solution failure.

Technical disobedience, another things to look out for, is when technologies are being used in ways they weren’t intended. This makes it difficult to predict risk and plan around it appropriately. An example given of technical disobedience was when, around 1991 after the fall of the Soviet Union, Cuba found itself with the derelict left overs. In particular, it was very common for Cuban households to have a single washer/dryer combination unit, where the wash and dryer were engineered as two separate services sharing one housing. One of the two would inevitably break down, leaving the behemoth appliance with a fraction of its original usefulness while taking up the same large footprint. Innovative Cubans took it upon themselves to break down the washer/dryer combos and use the motor within in different applications that it wasn’t originally intended for, such as: household fan, belt sanders, lawn mowers, key copiers, shoe repair tools, etc.

The concept of decomposing technology is the breaking down of technology into its parts. An understanding of the parts and how they come together to form larger components or sub-systems will give valuable insight and drive an ability to more accurately work with these parts and avoid risk. It’s key to understand the mapping of these components to their business requirements. This will allow you to make sub-system decisions, as you will be better able to determine whether only a part needs to be updated, removed or replaced and not the entire service.

What is indestructible? Nothing is truly indestructible, however a solution with resiliency, availability, redundancy, business continuity and recoverability stands a good change of maintaining its availability then most. Finally, note that there is a difference between robustness and anti-fragility. It’s a juxtaposition of technologies, and you’ll find that it applies in different measures to traditional applications versus cloud/container-based applications.

VMware Party

The VMware Customer Appreciation Party was held at the Las Vegas Motor Speedway this year. There was some food, lots of (competing) music, a bunch of arcade machines and really long lineups to take a lap around the track in a pace car. It really wasn’t my speed, so after about an hour and a half of wandering about I decided to call it a night early and retire. It didn’t help that it was quite hot, even after the sun set. It’s already been confirmed that VMworld will be returning to the Mandalay Bay in Las Vegas next year, however I’m holding out a shred of hope that the Customer Appreciation Party will find a new and interesting venue for 2017.

Last Sleep

This is the last sleep of the conference. The Solutions Exchange has already packed up and started their journey home. Some vendors and attendees have started heading home if they’re done delivering or watching their sessions. Thursday’s a half day, kicked off by a usually very interesting General Session followed by a final burst of sessions. Stay tuned for a live blogging of the general session and one last round up. Stay classy VMworld.

PS – As I write this, VMworld has actually finished. In a departure from earlier VMworlds, I’m instituting a No Post Left Behind directive. Once I’ve traveled back home I will be following up with the VMworld 2016 Roundup: Day 5. In that vein I’ll also be dredging up my old notes and you will get not just one Day 5 roundup, but three, count ’em three Day 5 roundups. One for the past three VMworlds including this one. Why, you might ask, would you want to read about old VMworlds? I don’t have a great answer besides the fact that I’d like to round out the post collections, and clear out the old, old drafts I’ve had half-queued up ‘lo these many, many, many months. Because, No Post Left Behind.