Welcome!

@CloudExpo Authors: Zakia Bouachraoui, Yeshim Deniz, Liz McMillan, Pat Romanski, Jason Bloomberg

Related Topics: @CloudExpo, Java IoT, Microservices Expo, Containers Expo Blog, @DXWorldExpo, SDN Journal

@CloudExpo: Blog Feed Post

Short Ts

There's been a lot of hullaboo in the last few years about the current cycle of disruption in IT

There's been a lot of hullaboo in the last few years about the current cycle of disruption in IT:  Public Cloud, Private Cloud, SDN, DevOps, Everything-as-a-Service… the list goes on and on and every vertical, every field, and every niche is feeling the churn.  Every day there is no shortage of opinions "for" and "against" something in tech that is emerging, in decline, or re-emerging.  There is one aspect to all of it though that is largely ignored:  "The Short 't'."

Every System in Summary

Figure 1.  A summary of any given system.

Figure 1. A summary of any given system.

Let's have a look at Figure 1.  It represents any given system:  A car, an MP3 player, a network, or a cloud-service.  Policy-Set "1" in implementation consists of some input state, configured or ephemeral, that allows the consumer of this system (be it human or another system) to express to the system some desired behavior or outcome the system should exhibit.  This expression happens in the context of a policy-framework which provides some set of policy "constructs."  In networking, this would be things like prefix-lists, ACLs, route-maps, affinity groups, affinity links, etc.  In the case of an MP3 player, this would be some set of menu selections leading the MP3 player to play music.  In the case of Amazon's cloud services, it could be a deployed CloudFormation template.

This set of constructs is then rendered (that would be the "r") by the system into some aggregate system state which exhibits the desired behavior or outcome that the consumer originally tried to express using the policy framework.  This rendering consists of a process in which the total set of policy constructs is deconstructed and turned, ultimately, into system state.

So what can we say about "r" in this diagram?  Well, not much actually.  We have to add something to the diagram to put "r" into meaningful context.  This is the something that is largely ignored in much of the discussion and, frankly, in much of the systems engineering and development work being done in IT.

Crossing your Ts

Figure 2.  System Summary with a measure of User Experience.

Figure 2. System Summary with a measure of User Experience.

Imagine you have two devices, both providing equivalent functionality.  For instance, you have two top-of-rack ethernet switches.  You actually own, and have installed vendor A's switch.  You have purchased vendor B's switch, and you are about to replace vendor A's switch with it.  Before you can do this, you must configure vendor B's switch.  You must "transform" vendor A's configuration (policy-set 0) to vendor B's configuration (policy-set 1).  If "t" is very long in this process, that means a lot of work must go into deconstructing vendor A's policy, and reconstructing them using vendor B's available policy constructs.  If "t" is very short, then the conversion is relatively easy (for instance, both vendors happen to use a Cisco IOS-like user interface).  Following me so far?  Good… now let's get a little more cerebral!

What we can say about "r" and "t" is a little clearer now.  The distance between "p0" and "s" is fixed and is a measure of user experience.  You can not shorten or lengthen "t" without impacting the length of "r", and vice versa.  If "r" is very short, then "t" must be long.  If "t" is very short, then "r" is very long.  In other words, the closer the policy constructs represent the design choices of the underlying system, the more difficult it is for a consumer to express their desired intent to the system.  A short "r" will manifest as many different "knobs" in the policy-framework.  In complex systems, a short "r" means innumerable potential outcome states, and therefore greater fragility.  A short "r" also means the level of abstraction relative to the overall system is low….  still here?  Let's get even more cerebral…

What if policy-set 0 is actually what's in your mind?  It's what you naturally intuit you want the system to do.   Now imagine the system is actually a "system of systems" popularly known as a network.  In legacy networking, "t" is very long between human intuition and the idioms native to the system. In fact, it's so long that you need to hire specialists to make the journey.  What is the CCIE exam except a test of "t?"  You must transform a confusing set of overlapping broken-english requirements into a set of router configs!

It would seem a natural conclusion, then, that SDN represents a new level of abstraction that shortens "t," making the network as a whole easier to interact with.  However, we've learned a lot in the last couple of years.  SDN, much like it's more popular sub-topic OpenFlow, isn't as practical as much as it is a great starting point for asking questions about what we really want out of the network.

It's not about the network, it's about everything surrounding the network

policyscale

What we've learned about network automation is that it's impossible to automate the network, or associated network functions, without reference to the systems surrounding the network.  As soon as you accept this inevitable fact, then the "system" becomes the data center.  See Figure 3. In this context, the interface to the network should present network-wide behaviors in an orchestration friendly way.  In fact, all constituent components of the data center should represent domain-wide behaviors that are highly automatable. In the next article, we'll go further down the rabbit hole, discussing the implication here for APIs and the data and policy constructs they represent.  We'll further enhance Figure 3, as well, as we discuss the primary importance of "deconstruction" along the path from human intent to system state.

For now, the take away here is this:  KEEP "T" SHORT! Burn it into your mind, customer and vendor alike.  Don't expose the contours of the underlying system to the user, because user experience matters.  This is true for data-center wide policy as well as for the constituent systems of the data center.

The post Short T’s appeared first on Plexxi.

Read the original blog entry...

More Stories By Michael Bushong

The best marketing efforts leverage deep technology understanding with a highly-approachable means of communicating. Plexxi's Vice President of Marketing Michael Bushong has acquired these skills having spent 12 years at Juniper Networks where he led product management, product strategy and product marketing organizations for Juniper's flagship operating system, Junos. Michael spent the last several years at Juniper leading their SDN efforts across both service provider and enterprise markets. Prior to Juniper, Michael spent time at database supplier Sybase, and ASIC design tool companies Synopsis and Magma Design Automation. Michael's undergraduate work at the University of California Berkeley in advanced fluid mechanics and heat transfer lend new meaning to the marketing phrase "This isn't rocket science."

CloudEXPO Stories
All in Mobile is a place where we continually maximize their impact by fostering understanding, empathy, insights, creativity and joy. They believe that a truly useful and desirable mobile app doesn't need the brightest idea or the most advanced technology. A great product begins with understanding people. It's easy to think that customers will love your app, but can you justify it? They make sure your final app is something that users truly want and need. The only way to do this is by researching target group and involving users in the designing process.
Digital Transformation and Disruption, Amazon Style - What You Can Learn. Chris Kocher is a co-founder of Grey Heron, a management and strategic marketing consulting firm. He has 25+ years in both strategic and hands-on operating experience helping executives and investors build revenues and shareholder value. He has consulted with over 130 companies on innovating with new business models, product strategies and monetization. Chris has held management positions at HP and Symantec in addition to advisory roles at startups. He has worked extensively on monetization, SAAS, IoT, ecosystems, partnerships and accelerating growth in new business initiatives.
Whenever a new technology hits the high points of hype, everyone starts talking about it like it will solve all their business problems. Blockchain is one of those technologies. According to Gartner's latest report on the hype cycle of emerging technologies, blockchain has just passed the peak of their hype cycle curve. If you read the news articles about it, one would think it has taken over the technology world. No disruptive technology is without its challenges and potential impediments that frequently get lost in the hype. The panel will discuss their perspective on what they see as they key challenges and/or impediments to adoption, and how they see those issues could be resolved or mitigated.
Lori MacVittie is a subject matter expert on emerging technology responsible for outbound evangelism across F5's entire product suite. MacVittie has extensive development and technical architecture experience in both high-tech and enterprise organizations, in addition to network and systems administration expertise. Prior to joining F5, MacVittie was an award-winning technology editor at Network Computing Magazine where she evaluated and tested application-focused technologies including app security and encryption-related solutions. She holds a B.S. in Information and Computing Science from the University of Wisconsin at Green Bay, and an M.S. in Computer Science from Nova Southeastern University, and is an O'Reilly author.
Dynatrace is an application performance management software company with products for the information technology departments and digital business owners of medium and large businesses. Building the Future of Monitoring with Artificial Intelligence. Today we can collect lots and lots of performance data. We build beautiful dashboards and even have fancy query languages to access and transform the data. Still performance data is a secret language only a couple of people understand. The more business becomes digital the more stakeholders are interested in this data including how it relates to business. Some of these people have never used a monitoring tool before. They have a question on their mind like "How is my application doing" but no idea how to get a proper answer.