Showing posts with label SaaS. Show all posts
Showing posts with label SaaS. Show all posts

Monday, May 20, 2019

XXXX-as-a-Service aaS

The context of the utility to an as-a-Service capability in IT relies heavily on where the demarcation of use resolves.

It's much easier to see it in a graphical depiction.

In general, Infrastructure and a portion of the virtualization/abstraction are what will be acted upon by nearly all use cases (if we forgo the licensing issues with respect to those things more appropriately economical on bare metal).

On top of that you'd build out the as-a-Service for Infrastructure, which at the base level is virtualization/abstraction/operating system automation and management. 

Then you walk up the technology chain, including the management of constructs necessary for applications to be automated in build / test and delivery.

The last step on the technology chain is the delivery of what should be the most important element (though even today, we've people worried about HOW the underlying physical elements are doing), the Application delivery.

Delivery, SaaS, IaaS, PaaS, aaS
Tiers of 'as-a-Service' delivery

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.

Friday, February 24, 2017

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:

VPC Networking AWS NetBond AT&T Amazon Availability Zone
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:

Amazon, Azure, ExpressRoute, DirectRoute, Route, AWS
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:

Azure MS NetBond SaaS Salesforce
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.