User defined UX

When looking at all of the different ways that we can interact with the systems that exist within the realm  of IT today, we’ve all stopped at some point in time and realized how painful it was to use a product that is being sold by X vendor. We have different ideas and ways that we think the user experience of this product should flow and we’re disappointed that we can’t use it in the logical order in which we’ve interpreted for this particular operation. Whether it be CLI, API, GUI, etc. – we’re always upset that the experience just isn’t there. It doesn’t meet _our_ needs.

Stepping back and taking a look at the world around us, we’re not at all thrilled with the overall user experience of anything that we use today. We’re constantly complaining about where button Y is located, or why knob Z isn’t in the location that we consider logical. A good example is the location of the unlock door button in my Chevy Cruze that I bought last year. I’ve been programmed, over the last 15 years, in understanding that the door unlock button was located ON THE DOOR, and in the case of the Cruze (and other new makes and models)  –  they’ve relocated the door unlock button to the center console. Now, every time I go to lock and unlock the doors of my vehicle, I’m reaching to the wrong place at the wrong time. This is what I would call bad user experience. I would also call this a terrible example of first world problems, but I will use the illustration none the less. It doesn’t fit the logic that I have been accustomed to over the past decade and a half.

Something as simple as the location of a button has caused a small amount of grief for me when operating my vehicle. Can I still use the vehicle? Sure, but its going to take some getting used to and modifying my ‘unlock car door’ workflow. Stepping back and looking at the bigger picture, and understanding that the next generation of kids who inherit these cars as their first modes of transportation, this will be the way they understand the location of that single button within the referential space of the vehicle. Not on the door like our generation understands it. We both have different interpretations, either preconceived or unbiased through the use of the product.

UX is a fluid concept, not something that’s etched in stone. It’s entirely subjective to the individual who is actually using the product. And that subjectiveness is usually driven by some sort of perspective that the user has built, over time, on how something should look, feel and operate within the logical constraints of how they, personally, view the system.

We’re not concentrating on the fact that everyone interprets UX differently. We’ve talked before about how the network world is largely workflow driven, but we haven’t taken the time to understand that everyone has small nuances to how they perform a certain workflow. There are a certain set of atomic constructs that we use to accomplish a certain task, and we all string them together a bit differently throughout the execution of our workflow. This is why we think that UX sucks on every product out there. It isn’t entirely customized to our logical interpretation of how that task should be accomplished.

When talking about defining the workflows that we need to with respect to administrating an IT infrastructure, the same atomic elements are used when creating that workflow. VLAN X needs to propagate throughout Y infrastructure and connect Z nodes to comprise whatever system it is that we’re building. Now the nuances of that particular workflow come into play. We may see it fit to ensure that the VLAN has been created through a sort of show command or log parse before moving on to step 2, or we may not. We may want to publish that information to another system other than validating it through the platform that we’re working with currently. And that’s just service instantiation, that doesn’t include validation, troubleshooting, tearing a service down, etc.

Everyone interacts with these systems in a different manner and we all bring certain nuances, and history, to the table through those interactions. It would be best to be able to provide a user defined UX that fits, precisely, the workflow that a particular user is looking for. A workflow modeling tool that allows you to manipulate the atomic tasks that are well defined, but allow you to define how, when, and where, and in what order to use them. This will provide you with the user experience that everyone is craving within IT today.


One CLI to rule them all? It’s more than that.

Previous to the Tail-f Networking Field Day presentation, I had done some research on who Tail-f were and generally understood how their NCS product worked, but after sitting with Carl Moberg and his team and listening to what this device can offer, I was immediately drawn in. It would seem they’ve developed an appliance that can effectively, as Nick Buraglio wrote in his post here, the Rosetta Stone for all of the vendor NOSes that exist today.

Carl started the presentation with the phrase “hopefully we’ll show you something that will make you really upset, in a very good way”. And I think he did just that. He proceeded to tell us how Tail-f was founded and what they were up to for the first few years of their existence. There is a good chance that if you’ve used any current generation networking kit from the large names we all know and love, you’ve used Tail-f software and just haven’t been told you’re doing so. He then pointed out the pain point of configuring multiple OSes within an environment and handling the operational load of configuration management, service provisioning, revision control, etc.

It’s cumbersome to have to configure a mixed vendor environment between all of the syntax that most vendors pride themselves in maintaining. This has always been a pain point for operators and running a few mixed vendor networks in the past has always been a pain point for me. Especially jumping quickly between devices and having to switch gears into either OS. Even in the network I’m in today jumping between IOS-XR, IOS-XE, IOS, and now Junos, I find myself mixing up syntax all the time.

Enter NCS. Tail-f offers an appliance that can bring some simplicity to the idea of running multiple NOSes in today’s networks. But it can also do more than that. It allows you to model your services within the appliance and then deploy it throughout the network while also maintaining integrity of that service across your infrastructure through the transaction modeling done by the appliance when applying configurations to devices. This allows for change tracking and validation when rolling services out to network OSes that don’t offer any type of two phased commit process. Once a command is entered we all know there is no turning back on those platforms. This brings a certain level of sanity check to the process as well allowing the NCS to validate configuration before rolling it out to the device. Think about it like this, NCS knows about point A, the current state of the devices within your network and you describe to NCS point B, the service you want to instantiate, and NCS will handle getting you there along with making sure you don’t lose any limbs in the process.

Though NCS offers a lot of functionality through the use of their transaction process, I don’t think this is the biggest feature that NCS has to offer. The biggest thing that I have to say Tail-f offers with their NCS platform is the use of the YANG modeling language to model services within their product. YANG is a language that was written for use with modeling NETCONF. Since Tail-f utilized both NETCONF and YANG to build their service modeling platform on, along with other southbound protocols, I would say that they’re not your typical American Hustle(see what I did there Stephen?) tech company like we have here in the US, and I should add that Tail-f is a Swedish based company. Their service is built using completely open standards allowing possible future portability to other platforms, such as OpenDaylight (shameless plug). OpenDaylight’s entire Model Driven Service Abstraction Layer (MD-SAL) architecture will be operating on YANG modeling and what is built within NCS could possibly be ported into ODL. However, I’m starting to write some modules in YANG and I’m nowhere near expert in the language and still have a lot to learn, but the potential is definitely there.

The Tail-f product no doubt offers a ton of functionality in the way of faster operational application throughout the network, along with full fledged service modeling within their NCS solution. The ability to apply two phased commits is also quite the addition to the network devices today as we don’t have that functionality within the monolithic network OSes today. Being able to apply the two phased logic to something like Cisco’s IOS and IOS-XE bring a better version control along with operational flexibility to roll a change back should any problems present themselves. Along with all of this functionality is the fact that Tail-f has decided to build their solution on the use of YANG modeling. An open source modeling language developed for use with NETCONF, and that fits with the ability to possibly port service models through different products in the future. This would eliminate a HUGE operational burden to organizations that use lock-in products much like Infoblox’s NetMRI, etc.

Pay attention to Tail-f, I think you’ll see some pretty cool things come down the pipe, especially speaking with the team on their plans with ODL (shameless plug again). Pay attention to my blog as well as I saddle up my YANG Unicorn (YANGicorn?) and ride it around a while as I definitely see a future in spending the time to learn the intricacies of a language such as YANG.

The ‘Software Defined’ Policy Dilemma

Speaking with other individuals in the industry about what SDN is, specifically how we qualify and quantify it, has lead to me to quite a few conversations with people about how many people think of SDN as an NBAR / QoS on steroids solution instead of looking at it as higher level policy framework that can be applied across infrastructure. I, personally, can subscribe to the thought process there.

We got side tracked in the last Class C Block podcast I was invited to participate in, about what SDN is and how we can use it and I just recently listening to the latest Healthy Paranoia podcast where the discussion of how SDN could impact the security realm was had. And the key word that I kept hearing was policy. Policy that needs to be applied here, and policy that needs to be configured there.

I like the idea of defining a framework for our infrastructure in that we can mold the technology policies that we have within our organizations to the business. This is the fundamental reasons why IT exists. We’re here to transcribe business policy into technology solutions. That said sometimes there are very large gaps in translation from business policy into technology, and this brings me to my point.

If SDN, within the next 5 to 10 years, is going to yield us anything we need to make sure that we have not only engineers that can design, build, and deploy these next generation solutions, but they also need to understand the business side of the house a bit deeper. Right now we’re afforded the ability to understand the business logic on a lesser level as we’re living within a world of constraints defined, in majority, by the hardware and software we have deployed in house. To the point where businesses are willing to change their business policy to accommodate the limitations of their technology. The obvious constraint from the business side of the house that can be read into these new policies would be the financial impact. Being more network engineer than anything, the best I can align this with is having multiple upstream peers, all with different monetary costs and having the ability to intelligently shift flows in accordance with fiscal requirement. Right now its a lot of kludge edge policy that needs to be modified and addressed relatively regularly depending on demands within the network.

The more I think about it and the harder I examine the problems and pain points that organizations face and why so many of us are clamoring at the thought of having that panacea of flexibility that all of this hype promises to offer, we need ensure we really understand exactly what it is we’re trying to accomplish. From a business perspective, as well as technological. Otherwise, years from now we’ll look back at our next generation ‘software defined’ infrastructures and be facing the same problems we’ve been faced with over the previous decade. Except, this time we’ll be faced with unraveling a larger ball of yarn with all of the ‘code’, read pseudocode…ish…whatever you want to call it, that gets developed along the way.

Maybe I’m the only one that has seen this problem within organization but I still feel it necessary to at least bring this point to light.