Intent Based Orchestration for Applications

Slides:



Advertisements
Similar presentations
Ganesh Subramanian 22/12/2010
Advertisements

Plan Introduction What is Cloud Computing?
TOSCA Topology and Orchestration Specification for Cloud Applications International Cloud Symposium October 10-12, 2012 Paul Lipton, VP Industry Standards,
IT AIN’T WHAT YOU DO TO DATA… IT’S WHAT YOU DO WITH IT Edd svds.com/StrataUK2015.
Intelligent Cargo in Efficient and Sustainable Global Logistics Operations WP5 – Open End-to-End Pilots Implementation Jose Gato Luis –
1 Introduction to Middleware. 2 Outline What is middleware? Purpose and origin Why use it? What Middleware does? Technical details Middleware services.
Plan  Introduction  What is Cloud Computing?  Why is it called ‘’Cloud Computing’’?  Characteristics of Cloud Computing  Advantages of Cloud Computing.
What is the cloud ? IT as a service Cloud allows access to services without user technical knowledge or control of supporting infrastructure Best described.
Objective: Enable portability and semi-automatic management of applications across clouds regardless of provider platform or infrastructure thus expanding.
Independent Insight for Service Oriented Practice Summary: Service Reference Architecture and Planning David Sprott.
1 ALCATEL-LUCENT — PROPRIETARY AND CONFIDENTIAL COPYRIGHT © 2015 ALCATEL-LUCENT. ALL RIGHTS RESERVED. NFV transforms the way service providers architect.
Discussion on oneM2M and OSGi Interworking Group Name: ARC Source: Jessie, Huawei, Meeting Date: Agenda Item:
Communication Needs in Agile Computing Environments Michael Ernst, BNL ATLAS Distributed Computing Technical Interchange Meeting University of Tokyo May.
Digital Solutions Extension Framework Mark Myers Director, Global Solutions Go-To-Market July 12, 2016 Solution Partner Forum.
JBossWS beyond JAX-WS Heiko Braun Senior Software Engineer
READ ME FIRST Use this template to create your Partner datasheet for Azure Stack Foundation. The intent is that this document can be saved to PDF and provided.
ONAP and MEF LSO External API Framework Functional Reference Architecture 12 July 2017 Andy Mayer, Ph.D. © 2016 AT&T Intellectual Property. All rights.
Rationalizing ONAP Architecture for R2 and Beyond Vimal Begwani – AT&T
Euro17 LSO Hackathon Open LSO Analytics
ONAP layering/MEF alignment
MEF Modeling Activities
Service Assurance in the Age of Virtualization
VCL Virtual Computing Laboratory An Opportunity to Lead
Business System Development
Lifecycle Service Orchestration (LSO) Models in context
Applications Modernization Services
Unlock the Business Value of Virtualization with Analytics
MEF Common Information Model Overview
Service Delivery and Governance
ONAP Interface to External Controllers
ARC: Definitions and requirements for SO/APP-C/VF-C discussion Chris Donley Date , 2017.
OPEN-O Modeling Directions (DRAFT 0)
MEF Modeling Activities
LSO Hackathon Kickoff Charles Eckel.
MEF Q2, April Frankfurt, Germany
Goals and Objectives Project(s): Technical Specification for SD-WAN Service Definition Purpose of the contribution: To describe the proposal and have an.
MEF LSO Legato SDK 24 October 2017 Andy Mayer, Ph.D. Tara Cummings.
Presented by Munezero Immaculee Joselyne PhD in Software Engineering
Intelligent Agent Solution
Service Delivery and Governance
ATIS’ Cloud Services Activity
LSO Hackathon Summary Charles Eckel, Cisco DevNet.
Goals and Objectives Project(s): Technical Specification for SD-WAN Service Definition Purpose of the contribution: To describe the proposal and have an.
Using the MEF Core Model in ONAP John Strassner, Ph. D. Andy Mayer, Ph
Use Cases and Requirements for I2NSF_
ONAP – Centralised Parser Distribution Atul Purohit - Vodafone
Hyper-V Cloud Proof of Concept Kickoff Meeting <Customer Name>
ONAP APIs Andrew Mayer, AT&T
Cloud Computing.
Week 01 Comp 7780 – Class Overview.
MEF 3.0.
ONAP Amsterdam Architecture
Your Business Opportunity
Cloud Application Marketplaces
Cloud Application Marketplaces
Service Model Monitoring Cloud Application Marketplaces
Cloud Application Marketplaces
Cloud Application Marketplaces
Cloud Application Marketplaces
Service Delivery and Governance
TDL: The ETSI Test Description Language
Cloud Application Marketplaces
Modern data architecture at scale in the cloud : Best practices of Serverless, lambda and microservices architecture Prakriteswar Santikary, PhD Vice President.
Cloud Application Marketplaces
Salesforce.com Salesforce.com is the world leader in on-demand customer relationship management (CRM) services Manages sales, marketing, customer service,
7.3 Example Use Cases Spirent Automation Platform Technologies.
IT Management Services Infrastructure Services
János Farkas, Balázs Varga, Rodney Cummings, Jiang Yuanlong
ONAP Architecture Principle Review
Applying CIM to SD-WAN Weiqiang Cheng, Feng Yang(CMCC)
Presentation transcript:

Intent Based Orchestration for Applications Dave Lenrow dlenrow@gmail.com

Background for discussing “Intent Based” An IMPERATIVE interface explicitly prescribes the technology features, configuration and state of devices that deliver services An DECLARATIVE interface defines a desired end-state in a way that is independent of technology and device specifics Declarative interfaces deliver benefits including portability, vendor-independence, interoperability, linear scale-out, ease of use, automation of complex logic, and more.

Defining an Intent Based System Note this picture was published the ONF NBI groups principles technical recommendation. Note that mappings can come from anywhere in the system. Intent can’t refer to things unless they existin in mapping DB so they are tightly coupled. The intent engine is the imperative control point for driving imperative interfaces to infrastructure and devices The intent engine is the brain of the control system Intent based systems include a controller (the Intent Engine) with two distinct north-bound interfaces: The Intent API is declarative, describing desired system behavior The Mapping API updates state of dynamic system elements

Migrating to Intent Based Systems Today Applications include knowledge of and analytics for infrastructure devices and behaviors. They harvest proprietary infrastructure telemetry, analyze it and drive imperative changes to infrastructure elements. Imperative and Declarative interfaces are combined in a way that makes for big, complicated, non-interoperable applications and infrastructure interfaces After Intent Project Closed loop monitoring of infrastructure state and imperative control lives exclusively in the infrastructure controller layer. Applications express desired end state and behavior (they are not aware of infrastructure details) using interoperable declarative interfaces. End-user of intent can introduce new terms and grammatical constructions via the mapping interface (this requires a developer) Imperative get deprecated as control loops migrate

Application Programming Model Examples Programable Network App On Device Cloud Service Telemetry ST Data LSO Intent NBI Inference Intent Model ST App & Proxy Intent API Analytics Direct Application Intent Model Application Proxy App Intent API Analytics Programable Network App On Device Cloud Service Telemetry Application Data LSO Intent NBI DPI Intent Model DPI App & Proxy DPI Intent API Analytics Telemetry Application Data Telemetry Application Data LSO Intent NBI App On Device Cloud Service Programable Network

Mixed Imperative/Declarative Migrating to Intent Mixed Imperative/Declarative Intent Based Application/ Proxy Application/ Proxy Analytics I M P E R A T V D E C L A T I V I N T E M A P I N G S Analytics Analytics Telemetry Application Data Telemetry Data Telemetry Application Data Telemetry Data LSO NBI LSO Intent NBI Infrastructure State Talk about migrating to some intent vs migrating to all intent. Goal is consolidation of infrastructure state and analytics outside of the application layer. This means migrating the control logic and closed-loop monitoring into the intent engine and leaving only intent and mapping in the application layer. App On Device Cloud Service App On Device Cloud Service Programable Network Programable Network

Imperative out of applications layer Application Layer Application Analytics I N T E M A P I N G S Application Telemetry Data Infrastructure Demarcation Point Infrastructure Layer N Analytics Mixed Imperative & Declarative I M P E R A T V I N T E M A P I N G S Infrastructure State Point of this slide is intent may exist inside the infra stack. What matters is imperative is out of the apps. Goal is consolidation of infrastructure state and analytics outside of the application layer. This means migrating the control logic and closed-loop monitoring into the intent engine and leaving only intent and mapping in the application layer. Beneath the application layer there can be various mixtures of imperative and declarative up and down the infra stack. Infrastructure Layer N + 1 Analytics Infra Telemetry Data Infra Telemetry Data Infrastructure State Device device Programable Network

LSO Closed Loop Analytics with Application APIs MEF LSO Framework Cloud Applications Application Events and Telemetry LEGATO (BUS:SOF) AI Analytic Applications Service Orchestration Functionality Events Data Analytics Platform PRESTO (SOF:ICM) Infrastructure Control and Management ADAGIO (ICM:ECM) Observe that this picture is essentially identical to the intent migration endpoint Element Control Management & Data Aggregation Network Events Events Logs Metrics Netflow Network Telemetry Network Infrastructure

Excerpts from MEF SD-WAN proposal To meet customer demand for agile, economical end to end services and application delivery, Service Providers (SPs) need standards of inter-operator and multi-vendor interoperability. Having interoperablity and quality standards will enable the industry to capitalize on the opportunities offered by this transition while underpinning innovation. SPs who can offer a service that is certified against a recognised industry standard will have a competitive advantage. Show SD-WAN and combination of control loops with mixed i/d Show migration to segregated with consolidated analytics Talk about data lake

Intent as SD-WAN Interoperability Foundation Declarative component is inherently portable and implementation agnostic. Common API or translation between similar levels of abstraction is possible for interoperability in the declarative domain. Mapping ties declarative abstractions to the implementation details and needs a more formalized approach to agreeing on interface details per-use- case. Intent Group under MEF Application Committee will initially work on refactoring/defining SD-WAN as intent and mappings, after refining and prioritizing use cases

MEF Intent based SD-WAN Work Deliverables: 2H2018 SD-WAN intent and mapping interface definition V1.0 2H2018 Open Source POC/Reference V1.0 Need volunteers to lead work items Immediate Work Items Recruit and identify contributors Agree on use case priorities Define use cases (already done by SD-WAN project?) Identify and define intent based SD-WAN POC 1.0 Begin software development Will refine dates and deliverables as a group once up and running

Intent Based Orchestration Weekly GTM To Be Announced