DevOps is Sensing for Platform's sake

In the previous post on the high level reference architecture for DevOps, we identified the lifecycle attributes of modern application development.

The state of the art in application delivery is in a continual state of refinement, subject to the execution of economies on the Value Chain attributes of both infrastructure and platform delivery.

This is further enriched through the use of shared development (opensource, github, etc) and recognition of "future sensing agents" within the lifecycle of application delivery, particularly the exposure and refinement of APIs for the purpose of automation.

All of this is made possible by the continuing evolution of application development and operational support of equipment infrastructure at a fundamental/foundational level.  It is an OODA loop and seems to be accelerating in direct alignment with the practice of Agile Development.

Where 2nd Platform application designs supported an abstraction of the server through virtualization, the 3rd Platform is leading to distributed, run anywhere application lifecycles that provide the means to portability of workload on pooled Infrastructure as a Service (IaaS).  See Figure 1.

Figure 1. Application Development Evolution Steps

Compelling events in the 3rd Platform include the introduction of Software Defined Networking (SDN), Software Defined Storage (SDS) and Containers that provide the enhanced abstraction of the underlying pool of equipment.

With an appropriate sensitivity to the APIs that provide abstracted functions, the Operations service is being automated at the platform level by industrializing those APIs into Cloud Native functions within the Platform.

This is the "future sensing" that creates the continuing evolution of the Platform space. #mapping

CSPs, SaaS and Network Ecosystems

Networking between Virtual Private Cloud (VPC) deployments is possible, but if you're looking to avoid some of the pitfalls of either multi-region or even multi-vendor deployments

• it may be necessary to build a substantial part of the network yourself
• you may have to trombone the traffic through your CSP to Data Center connection

      Neither of these are great options for an infrastructure that is nearly all automated and programmatic.

So, considering the alternatives, there may be some interesting possibilities as Network Ecosystem vendors enhance their services with additional automation and integration.

Consider AT&T's NetBond for instance.  In a situation where you are already using NetBond to create interconnection points for your enterprise integration and consumption of CSP services, imagine the possibility of using the NetBond headends to instrument a connection between extra-regional VPCs in a CSP, like Amazon Web Services.

The major advantage, NetBond is a programmable interface to the Direct Route AND they can pass traffic on the AT&T AVPN without having to transverse the Enterprise WAN.

Here's a high level of what that would look like:

Figure 1.  AWS VPC to VPC

At first glance, this looks remarkably similar to VPC routing, but notice that this configuration is completely EXTRA-REGIONAL, it could be used to connect a VPC in US West to a VPC in Singapore.

This could provide some really interesting availability and DR models for application designers.

A second possibility is to enhance a Hybrid Cloud service with execution in more than one vendor CSP.

Consider the following figure:

Figure 2.  Amazon VPC connecting to Azure Cloud

In this model, creating a truly vendor independent cloud deployment becomes possible.  Not only will this instrument application delivery across multiple CSPs, but it makes some of the container application deployment possibilities a lot less "sticky."  And yes, it's entirely programmatic.

There's always a question around moving data to the right place.  Considering that quite a number of enterprises use a variety of SaaS services today, it may be nice to move specific volumes of data from one place to another to act on them with some Big Data analytics (and maybe even some #AI in the future).

Consider the next figure:

Figure 3.  CSP to SaaS

As an example: with this method it would be possible in the future to send SFDC data (or even a stream) to an interactive visualization of the data in Microsoft Azure via Power BI.  Again, all done programmatically AND secure.

Ultimately, once network connecting points are made available, interesting things can start to happen with Network Ecosystems.

Update:

.@abusedbits Love it-- A realtime market opportunity feed for the @CSC + @MicrosoftR IML: http://bit.ly/2ibqZpk  #CSCTechTalk

https://twitter.com/JerryAOverton/status/835493717389754368

A compelling use of real time data feed, programmatically applied to a network integration and delivery of interactive visualization with MicrosoftR.

DevOps

I was asked to produce a high level, non-waterfall view of DevOps that included all of the associated areas, including Agile Development, Continuous Integration, Continuous Delivery, Application Development and Operations.

It's an amalgam of more than one model, showing the entire lifecycle from Backlog to Ops Incident/Change with principal areas of concern as banners on the diagram.

Figure 1.  DevOps and the Application Development Lifecycle

Please do let me know if you find this useful.

map-camp.com

If you are a fan or simply interested in Value Chain Mapping, Wardley Maps or anything else in this area of situational awareness:

Simon Wardley @swardley http://blog.gardeviance.org/ is setting up a first of a kind event in the UK.

It will be a gathering of like minds exploring the depth of Wardley Maps.

Visit map-camp.com to gain situational awareness of .. situational awareness.

     http://www.map-camp.com/

I'm a fan, and here are some of my examples:

     http://www.abusedbits.com/p/value-chain-mapping.html