Friday, March 31, 2017

Enterprise WAN is evolving!

Enterprise WAN Reference Architecture
Figure 1.  Enterprise WAN Reference Architecture
Figure 1 represents the high level Enterprise WAN Reference Architecture that current network capabilities seem to be indicating for the support of enterprise services. 

The MPLS network will be extended and enhanced utilizing gateway functions like VPN (which we currently do), CSP access that enables direct connectivity via the MPLS network and SD-WAN that will allow the extension of the MPLS via the Internet to small and medium size locations (maybe even large locations).

SD-WAN will extend the capability of MPLS network to locations not natively available with individual carriers.  It avoids the need to NNI carriers unless it is absolutely necessary. The carriage mechanism is tunneling over the internet and can support vendor/protocol specific optimizations for some quality of service (an abstraction of the underlying IP connectivity).
     Where SD-WAN cannot be on an MPLS gateway, the internet direct to DC will be able to support this functionality.

This model also represents the dissection and reduction of networks that must be "carried twice", ingressing and egressing the Data Center perimeter security controls. These controls will eventually be migrated to the Carrier Cloud WAN Services.  They will be provisioned for specificity in the enterprise application usage model or virtualized per application within the workload execution model.
     Traffic destined for CSPs and SaaS can use a more direct path via the Internet if allowed by the Enterprise.

The CSPs, connected to the Internet, a CSP gateway to MPLS and Ecosystem networks connected directly to Data Centers will extend the Enterprise Network to support enhanced consumption of those types of services like SAS, IoT as well as the various Cloud Service Providers.

Individuals will come in over a variety of connectivity mechanisms including broadband and telco wireless.

Providing the cost structure is competitive, backup paths for many of these networks are likely to shift toward future implementations of Telco 5G.

Thursday, March 16, 2017

Is Agile about brain chemistry

agile neuron
DevOps on Neuron
Is there a correlation between brain chemistry and development using the Continuous Integration mechanism of the DevOps model?

This relates to Agile in a couple of interesting ways.  The first being goal-setting, where the Agile Development process introduces changes to the Application Lifecycle in easily manageable increments.  

     Agile coaches recommend two week cycles, which are easily understood goal timeframes by the Agile team.  Too long and procrastination takes hold.  Too short and the development becomes daunting. 

The second is a relative randomness of action vs reward.  This has quite a lot to do with human brain chemistry, but essentially means that the Agile development corresponds roughly to an illusion of progress, if not outright progress.  

     It puts the developer into the position of a firefighter, being allowed a quick win in the form of an application enhancement or fix that corresponds directly to a goal that must pass strenuous test and validation.  

Success, much like the firefighter extinguishing a fire, is a buildup of doubt, fear and any number of negative emotions, followed by a release of endorphins.

     The chance of success is interwoven in the complexity of the solution requirements and the random nature of fast fails.

Ultimately, DevOps is about behavior.  If the sense of creation within a relatively small window and the struggle of creation do not tarnish the motivating growth or momentum (seem too difficult), the Agile development process is easier to continue than stop.

     This reinforces the behaviors of Agile methods as well as the ancillary benefits of the entire team participating in the successes.

In this way, it is possible that Agile is a means to change application development in a way that relates more to human brain chemistry than simply developing code.

Saturday, March 11, 2017

What does Watson think about you 

Follow the link, free and no registration (though, they will get your twitter handle out of the deal).

     Choose Content type Radio Button "Twitter"

     Enter your twitter name.

     Select Search (It'll find your tweets automagically)

     Press Analyze and await the results.

Figure 1.  Watson inputs to Personality Insights

Here's what Watson said about me:  (guess Watson didn't see my cartoon blog)

Your Personality*

You are shrewd and unconventional.

You are philosophical: you are open to and intrigued by new ideas and love to explore them. You are authority-challenging: you prefer to challenge authority and traditional values to help bring about positive changes. And you are solemn: you are generally serious and do not joke much.

Your choices are driven by a desire for discovery.

You are relatively unconcerned with both tradition and taking pleasure in life. You care more about making your own path than following what others have done. And you prefer activities with a purpose greater than just personal enjoyment.

*Compared to most people who participated in our surveys.

Wednesday, March 8, 2017

Creation and destruction without remorse

Recent announcements by network vendors (AristaJuniper, Cisco) specifically taking aim at containers as part of their strategy indicate that the evolution of the platform continues.

When I say The Platform, I mean specifically the Value Chain of workload execution that exists as separate entities within the Enterprise and the Public Cloud.

Adoption of methods that provide 'like' services in both the Enterprise and Public Cloud pose an interesting point of view in the direction the network industry will take.  In this view of the world, there is a history of expectation that supporting capabilities within the Enterprise will resemble the capabilities in the Public Cloud and vice-versa.

The two service areas are advancing, often with differing goals in mind, for use of their virtualization service.  Enhancement of the capabilities are happening on different trajectories, where the example of AWS moving their Platform-as-a-Service toward Serverless functions and Enterprise services as Virtual Infrastructure Managers that are starting to tie into container capabilities.

The "least common denominator" capabilities that allow meaningful ubiquity in an all encompassing service model of today may very well disappear over time.  This to be replaced by the service chaining of decoupled application functions.

Based on some of these recent announcements, the network vendors mean to enter this brave new world in their areas of strength.

     Arista is pursuing the support of complex workflows execution, where its network code can be spun up or down as workloads change, with the same code on hardware, in virtualization and within containers.

     Juniper's Contrail similarly supports virtual services like their vRouter that interacts directly with the virtual infrastructure management for automation (service chaining).

     Cisco's Project Contiv may be the most ambitious, applying policies (and networking) that characterize the 'intent' of an application's deployment.

Some of the key things about DevOps that will play a role in how this all works out, and that the network vendors should take to heart:

  •      Application development is not an isolated activity.  When one finds a useful capability, they will share it.
  •      Because containers can be easily shared, applications are unlikely to be created from scratch.  Making sure developers can share useful capability is vital.
  •      Network methods used to support applications must be easily created and destroyed.

Or, as posed to me by Rick Wilhelm, "Containers allow creation and destruction of application environments without drama or remorse."  -- so must it be for the network.

remorseless creation and destruction