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]<mailto:[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
