Wikis > Hybrid Multi-Cloud > June 22, 2017 – Meeting Notes

ONUG Open Hybrid Cloud Working Group–June 22, 2017, Meeting Notes

BY BOB WYSOCKI, GE

Team reviewed proposed framework for transitioning HCWG into an Initiative as well as farming out certain portions of the framework to sister ONUG teams.  Overall feedback was positive with following distinctive points made during discussion.

Most of conversation focused on the topics of Cloud Connectivity and Cloud Abstraction.  We hypothesized that there are 4 somewhat different/somewhat overlapping approaches outlined below.  None of these are considered more correct than others – simply that there are different approaches active in industry as there always are.  We discussed that any/all of these approaches are potential areas to demo as POC’s and/or reference architectures at ONUG Fall ’17.  Having more than one approach demonstrated is a good thing and better than having fewer options. 

Team discussed that most important thing to understand first is application architecture and requirements.  None of these options should be implemented simply because they are popular or trendy.  Enterprises must understand their specific needs, and the trade-offs gained/lost by employing one approach over another.  Developers therefore have significant power in enabling (or disabling) portability in defining how the application architecture based on business requirements.  While time to develop and deploy an application can be greatly reduced by leveraging existing CSP higher-level services, this very benefit can later negatively impact portability.  Good basic application design should be of primary consideration and concern and take precedence over an otherwise tangential goal to achieve portability just to have portability.  The Team also emphasized that its highly desirable to have a tool set/approach that spans the use of private and public clouds, that can assist with both legacy and newer applications – however there is a realization that having one thing that fits all requirements is not likely realistic. 

The four approaches discussed were as follows:

1)      Cloud Abstraction can be accomplished through the use of Cloud Management Brokers. Clickr, Terraform and Cisco Cloud Suite were cited as examples by Ti/Gap and Aaron/Cisco as having some experience in this space but there are certainly others. Fugue was mentioned as being on AWS today but other CSP’s being on their near-term road map.  Brokers have the advantage of enabling portability of workloads across multiple CSP’s and some even have capability to conduct real-time analysis of workloads to identify the potential cost savings to be gained by moving the app/workload to a different CSP other than where it is running today.  Brokers work best when basic capabilities of compute, storage are needed.  Brokers are not as effective when higher-level services offered by only one CSP (eg, AWS RDS) are required by or add strong value to your specific application.  A Broker’s ability to abstract a given service capability across CSP’s by definition will lag in time from when that feature is available from the CSP’s as the Broker requires their own time to develop the abstraction mechanism. 

2)      Containers and Container Orchestration tools are maturing and gaining popularity, especially Kubernetes in the marketplace.  Containerization can provide benefit as a good mechanism to abstract the infrastructure details away from the Developer and Operations for a given application, and enable that application to be portable from one CSP to another, or to port from private to public infrastructure.  Containers will work best for modern cloud-native applications being newly developed, especially when they can be constructed in a microservice fashion. There are caveats to consider however and containers are not a silver bullet.  As stated, not all apps are suitable for containerization; they may be monolithic legacy apps.  They may not be able to take advantage of CSP higher-level specific value-added services.  They may add more value to application logic layer and less value to persistence storage/retrieval of data.  Differences in network segmentation approaches by CSP’s can be a complicating factor.

3)      Cloud Connectivity can be provided between an enterprise and multiple CSP’s from a number of maturing SD-WAN providers.  Those providers with virtual appliances that can run natively within the CSP fabric can provide an enterprise with facilitated access directly to those CSP services.  Viptela was cited as an example by Gap and GE has having experience but there are others. SD-WAN providers can provide routing optimization in real-time but in current form, represent a form of vendor lock-in on their own.

4)      Other vendors provide Cloud Connectivity brokerage services that can also facilitate an enterprise’s connection to multiple CSP’s; Equinix and Packet Fabrics were examples cited as providing value today.  Typically such providers enable an enterprise to connect virtually to multiple CSP’s and/or SaaS partners via a single direct pipe in a co-location facility available in various regions across the globe.

In summary, the team felt that POC’s in some or all of these areas for ONUG Fall may be best, and to highlight pros and cons of each for enterprises to consider which applies best to their unique needs.  The Team warned that application portability may not be truly available in a general way for ONUG Fall ’17 but for an ONUG event yet in potentially distant future. 

Actions:

Bob to publish minutes above to document discussion and socialize to broader Team for those not on the call.

Bob to discuss status offline with Nick and Carlos to gain their feedback… are we headed in positive direction, or need course correction?

Snehal to make introduction between Carlos/Bob to SD WAN Co-Chairs to discuss how to tighten collaboration between the teams under the proposed framework

Bob to reach out to Eric/451 Research to ascertain latest status of TCO Model