ONUG Working Groups: The Philosophy for 2019 is “Less is More”

The second round of ONUG Working Group calls took place last week, with each group engaged in the process of identifying pressing use cases that need to be addressed with the goal of articulating a clear set of requirements that are unambiguous and actionable.

The philosophy for 2019 is “less is more.” Each group is bounding use cases to a straightforward hybrid multi-cloud environment with sufficient diversity to flesh out critical requirements but not so complex that the exercise turns into “boiling the ocean.” Well-bounded use cases will help each group develop a reference solution architecture that defines key functions at a level of specificity that enables solutions integrators to build test environments in which vendor products can be integrated for validation and demonstration purposes.

The following is a summary of last week’s calls for the Monitoring & Analytics, SD-WAN 2.0, Software-Defined Security Services and Hybrid Multi-Cloud Working Groups.

IT executives are encouraged to join these calls every two weeks and to join the online discussion via each working group’s Slack channel.

The next round of working group calls will be next week on Tuesday, Feb. 5th and Thursday, 7th. Watch your email for invites and hope you are able to participate.

Stephen Collins

ONUG Working Group CTO

On last Tuesday’s M&A Working Group call, the discussion spanned many requirements for monitoring microservices running in containers in hybrid multi-cloud environments.

The group identified these requirements:

  • Visibility into container-specific performance
  • Methods for extracting container-specific metrics
  • Monitoring virtual network connections for containers
  • Mapping the topology of microservices in the underlying infrastructure
  • Tracking changes to this topology in real-time

The group also discussed the need to monitor other cloud-based, 3rd-party services that microservices utilize, for example, DNS. Active monitoring of these services would allow operators to determine if performance anomalies are related to the application itself or the 3rd-party service.

Continuous testing is integral to the DevOps methodology, including unit testing, integration testing (including with 3rd-party services) and post-deployment testing. Synthetic monitoring tools play a key role in this area.

There is also the significant challenge of scaling the monitoring infrastructure itself to collect, process and store the huge volume of metrics aggregated from many different sources (the “full stack” of hybrid multi-cloud infrastructure). A critical step in this process is properly tagging metrics before storing so that it is possible to quickly correlate metrics spanning many different sources to speed root cause analysis.

The working group’s goal is to define a concise set of requirements for architecting a reference solution that can be implemented in a testbed environment to validate the various products and services that could be deployed to meet these requirements.

On last Tuesday’s SD-WAN 2.0 Working Group call, participating IT executives discussed a wide range of problems organizations are dealing with in SD-WAN deployments, including:

  • Migrating from one vendor’s SD-WAN technology to another’s
  • Hybrid environments operating an SD-WAN in parallel with an MPLS network
  • Providing connectivity via a mix of both MPLS and the Internet
  • A wide range of security issues related to SD-WAN deployments
  • Security issues related to SD-WANs in hybrid multi-cloud environments
  • SD-WAN compliance issues related to data sovereignty and geolocation
  • Application policies for different types of traffic, end points and users
  • Monitoring of cloud security services and performance

The focus of the call then shifted to identifying a set of best practices and methods for integrating or interworking between SD-WANs based on different products or services. This will become an increasingly common need as the number of SD-WAN deployments increases and companies scale-out or end up merged with or acquired by another company.

The discussion included:

  • Using vanilla, non-proprietary IPSec for secure connectivity
  • Running BGP everywhere and exchanging routes via BGP peering
  • Utilizing third-party orchestration software to integrate multiple SD-WANs
  • Higher layer software that ensures uniform SD-WAN management and orchestration
  • Monitoring performance via vendor-specific APIs for telemetry data
  • Vendor-specific APIs for policy definition and enforcement
  • Addressing security and compliance issues using cloud security providers
  • Defining a set of best practices, pre and post deployment
  • Address requirements for both data centers and remote sites
  • Call out potential security gaps and pitfalls, particularly those related to the cloud

The call concluded with a brief discussion of defining a reference architecture for SD-WAN integration that a solution integrator could implement in a test environment for bake-offs focusing on integration testing and product validation.

Last Thursday’s SDSS Working Group call picked up where the previous meeting left off, with the discussion centered on clearly articulating the top three use cases and requirements identified in the document titled “ONUG User Group Software-Defined Security Services Framework 2.2 – April 2018 Revision,” which are:

#1 Policies should be bound to workloads, such as virtual machines, containers, applications, services or microservices

#2 Write security policy in one place and deploy in multiple places, where workload policy would then be enforced

#3 Must be able to measure the ability of network workloads to ensure the confidentiality, integrity, and availability (the Security Triad) of the services they are delivering

The group agreed that it is critical to clearly define terms and use precise vocabulary to describe the use case requirements. This will provide a foundation for mapping these requirements into a reference solution architecture that will guide vendors and solution integrators as they deploy various products in a testbed environment for validating that use case requirements are satisfied. It is important to unambiguously articulate the requirements so that each is actionable and measurable.

The goal is to use the same ONUG WikiMedia reference workload that the M&A Working Group is planning to use as the basis for the reference solution architecture and the solutions integration testbed environment. This should yield additional synergies downstream as monitoring and analytics is integral to software-defined security, particularly for use cases such as SIEM, DDoS and IDS/IPS, among others.

The plan is to continue this work on Slack between now and the next meeting, further fleshing out the detailed requirements for each use case. The working group is also looking to to recruit additional IT executives who can dedicate some time to reviewing these requirements and provide feedback to the group.

On last Thursday’s HMC Working Group call it was agreed that a good way to kick off 2019 is to revisit the “Hybrid Cloud Program Guidelines Taxonomy,” which identifies the key pillars and associated topics that the group is chartered to address. The goal is to refresh the set of pillars and topics with respect to the current state of the market and alignment with the top priorities and needs of the ONUG user community. With the hybrid multi-cloud world rapidly developing, priorities may have shifted so the group agrees it’s important to start here.

A lengthy discussion then followed centered on a wide range of unresolved issues related to hybrid multi-cloud application development, deployment, orchestration and operations, most falling under the DevOps umbrella. There was discussion of taking the temperature of the user community relative to these issues but also recruiting other users with proven DevOps experience that could share knowledge and best practices with the community. Certainly, a potential topic for presentation at an upcoming ONUG Conference but this might also merit forming another work group to focus in this area.

The next step is for the working group to refresh the key pillars and sanity check priorities with the ONUG Community.

Author's Bio

Guest Author