This page serves as the working document for the Use Case as it is developed. All contributors are asked to add contributions to the project on this page. The table below may be modified in anyway to fit the needs of the project. Meeting notes along with meeting recording links are captured at the bottom of the page.
Use Case Name: | Application Centric Connectivity |
|---|---|
Use Case Description: | Deploy containerized and distributed applications to bare Linux and Kubernetes endpoints in any location in conjunction with a dedicated network overlay and any needed infrastructure (software-defined). And when various components of that application are moved to a new environment or locations, move the connectivity along with it without any downtime. The configuration of the application and corresponding connectivity should be represented by declarative intent. |
-Epic -Problem Statement | Separate teams currently manage network access and overlays, and application deployments. This approach removes barriers and empowers those deploying applications to also specify, provision, and stand up the connectivity within provided guardrails. |
Industry Use Cases Descriptions | Use Cases from existing demo
|
Users Stories |
|
Business Justications | |
Interaction with other open source projects and components |
|
Resources -people | Resources (people) to execute on the blueprint:
|
| Steps to Realization |
|
High-level architecture diagram | |
High level lab topology diagram | |
Dependencies - list of any dependencies that rely of future releases of a specfic component. |
or
|
High-level timeline |
|
Upstreaming Opportunities |
|
Blueprint Outputs (Suggested. Not all may apply) | check all that apply:
|
Links to existing documentation (Build Guide, Slideware, etc), if available. | |
Links to existing demo/video, if available. |
|
Links to existing code/repos, if available. |
- Separate industry Use Cases (Muddasar)
- Muddasar Ahmed to look at the demo video and extract some industry use cases
- Create User Stories:
- Create a Lab for HW infrastructure
- Bring in 2-3 components (Data Lake for example)
- Build component BOM open source and proprietary/commercial
- What can we do as far as demo for ONE Summit in Nov?
- Next Steps and Action Items:
- Muddasar Ahmed to look at the demo video and extract some industry use cases.
- Extract business justications from Use Cases
- @Mark Davidson (AnyLog) provide Whitepaper written for AnyLog
- AnyLog working with Cisco to integrate with there 5G solutions. Explore what we can do with Cisco. Frank Brockner is LFN resource.
- Muddasar Ahmed to look at the demo video and extract some industry use cases.
- Identify other open source components that can be used to glue the pieces together.
- Next Meeting?
Meeting Recording and Next Steps:
- Build the business justification
- Define requirements
- Validate among the group
- Reference Open Horizon project
- Identify other open source components that can be used to glue the pieces together.
- Relevant to Edgelake Project (Moshe Shadmon (AnyLog))
- Where can LFN projects play a role and enrich this Use Case?
- What are the standards that we would use for the data models for the interfaces, and so on.
- Insights into applicable existing standards that should be followed
- Next steps from 05/21 (below)
- Is previous Whitepaper available? 5G and Telco whitepaper available (Mark). written around AnyLog
- Ask Frank Brockner (Cisco) to particiapte Muddasar Ahmed to reach out.
- What can we do as far as demo for ONE Summit in Nov?
- Next Meeting is 1600 UTC
Project summation from Joe Pearson 05/21:
Within the open horizon project we had been working together with Red Hat's scupper open source software
to deploy network infrastructure software components. And the reason why we're doing this is because we believed
we were trying to implement something I would describe as application, centric connectivity.
Day 1: So rather than the traditional approach which is, you have one group of people in an enterprise that may be responsible for setting up, let's say, a network underlay managing that, creating the policies. And then potentially, another group might create network overlays on top of that, and then the developers would jump in and create and deploy their applications and somehow work together with these other teams
to then somehow get the connectivity working with their applications. So in this case, when I'm talking about applications, I'm making a couple of assumptions, I'm assuming number one that the applications may be containerized because we're using a a cloud native approach. That means we may be deploying to a bare Linux host or a Kubernetes cluster somewhere. So the idea is, can we use a cloud native or edge native application centric approach that empowers developers to define the connectivity between components in a modern distributed application and then to automatically deploy those components so that when they reach their destination they're also automatically stood up with the appropriate connectivity as an overlay on top of whatever network exists and that would then necessarily require
any software based infrastructure, or maybe even hardware based infrastructure to also be deployed if it needs to traverse various network segments, let's say, to go from the edge to the cloud to a specific provider.
So in a nutshell when an application is deployed to bare Linux or Kubernetes how can we also create a dedicated overlay connecting the distributed application components? So that would be the primary goal that I would like to achieve.
Day 2: when that application's components need to be moved to a different environment for any reason, whether that's cloud or to a physical location on premises or whatever.
Let's also move the connectivity with the components that get moved, and see if we can do it with little to no downtime.
So those are the 2 high level goals that we would like to achieve.
And then, third, one of the ways in which we would potentially want this implemented is to manage the configuration of the application and the connectivity
through declarative intent. So with that in mind, the second bullet point link there to application centric connectivity.
Is a very simple video demo that Jeff Lou who's on the call created, and that we showed in the open horizon booth at one summit. And what that does is that uses the open horizon as the orchestration and application deployment piece along with scupper as the application gateway and connectivity piece. And then demonstrates how you can deploy an application, deploy the infrastructure, and then connect to various pieces, so that an application can connect securely to its other remote services that it uses. So it's a very simple, Demo, but it goes by very, very quickly. We showed this at one summit as a demonstrator, to show how we could conceivably accomplish this today, using some manual configuration and mostly open source components. Now, in the case of the demo to make it as simple as possible, we also used a commercial product in there, which is Ibm hybrid cloud mesh what I would like to do for the or this particular blueprint is to see are there other open source components that we can use and put in this and glue the pieces together? Are pieces and components of this fungible or swappable?
And if so, what are the standards that we would use for the data models for the interfaces, and so on.
And lastly, who would be stakeholders, and who would want to participate in this blueprint with us.
The intent here is to encompass both edge and hybrid cloud, meaning all potential cloud providers, public and private on premise data center deployments, as well as what we would typically think of as edge computing deployments.
Notes from LFN/LFE Joint TAC F2F meeting from May 1: https://docs.google.com/document/d/146ghaxAXM8RcXFS0aSfheyYGqXDPuqqK2SYR4okYQz0/edit?usp=sharing