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



   

2 comments: