Sure, I'll send out the slides later today before our call.
Original Mail
Sender: ParvizYegani <[email protected]>
To: zhaohuabing10201488;Christopher Donley(Chris)
<[email protected]>
CC: [email protected]
<[email protected]>[email protected]
<[email protected]>Manoj K Nair <[email protected]>'Vul,
Alex' <[email protected]>
Date: 2018/03/19 14:59
Subject: RE: Some thoughts about ONAP Microservice Architecture for Casablanca
and beyond: Service Mesh, Centralized Authentication and unified API standards
Hi Huabing,
Thanks for launching the discussions on ONAP Microservices architecture. Right
timing! This is a very important topic that we need to consider for the ONAP
target architecture (R3+)!
I added the following item to the agenda for today’s tiger team call:
- ONAP Microservices Architecture for Casablanca and beyond
Please share your slides prior to the call. I hope Manoj, Alex, Manish and
other folks who have been quite active in driving this work in ONAP can join
the call as well.
Thank you
Parviz
-------
PARVIZ YEGANI, PhD
Chief SDN/NFV Architect
CTO Office, Cloud Network Solutions
FutureWei Technologies, Inc.
2330 Central Express Way
Santa Clara, CA 95050, USA
Phone: +1 (408) 330-4668
Mobile : +1 (408) 759-1973
[email protected]
From: [email protected] [mailto:[email protected]]
Sent: Wednesday, March 14, 2018 4:01 AM
To: Parviz Yegani <[email protected]>; Christopher Donley (Chris)
<[email protected]>
Cc: [email protected]; [email protected]
Subject: Some thoughts about ONAP Microservice Architecture for Casablanca and
beyond: Service Mesh, Centralized Authentication and unified API standards
Hi all,
I'd like to share some of my thoughts about ONAP Microservice Architecture for
Casablanca and beyond
1. Service Mesh
Service Mesh is the next generation of Microservice approach, which can bring
lots of benefits to ONAP and its users at both the development and operation
sides. Such as
· the separation of business logic and Microservice
infrastructure(communication, security, metrics etc)
· allowing free choice of development tech stack
· flexible route rules to enable traffic steering and canary release
· monitoring and tracing visibility
· fault injection for resiliency testing, etc
We should take service mesh into consideration. There are multiple choices on
the table right now, given its tight relationship with kubernetes which is used
for ONAP deployment, I suggest we give Istio a shot in Casablanca. MSB project
is investigating the possibility of integration of Istio and ONAP right now.
2. Centralized Authentication
ONAP is a huge system consisting of many services. Currently, different
services such as AAI, SDC, Policy etc. have their own authentication process,
which makes ONAP difficult to use and adds burden to the individual project to
enforce the cross-project authentication logic. We need to consider
implementing some kind of centralized authentication, which means user login
once and can access all the services. We also need to consider how to secure
the access of 3-party systems by using API token or OAuth.
3. Unified API standard
Most of the projects produce RESTFul APIs for consuming, but in a
none-consistent way. we need to define some unified standards/best practices on
the REST API definition across the ONAP projects such as versioning, url, error
code. There is a draft in the wiki page:
https://wiki.onap.org/display/DW/RESTful+API+Design+Specification
BR,
Huabing
_______________________________________________
onap-discuss mailing list
[email protected]
https://lists.onap.org/mailman/listinfo/onap-discuss
