Technical Considerations for Distributed Micro Services Communication

Micro Service Connection, Communication and Collaboration In the context of cloud native, applications are often no longer provided in the form of monolithic services, but are decomposed into a series of cloud native services deployed in distributed clusters, with inter-connections and joint provision to the outer side. Relevant scenarios was discussed in with the introduction of a Hybrid Function Chain (HFC) framework. Technical considerations and brief designs in the previous work would also be applicable in a Distributed Micro Service Communication (DMSC) circumstance. Thus, similar perceptions mentioned are stated in this draft for further discussion and review. Existing schemes, for which especially applied in cloud and cluster infrastructure, traffic lanes, for instance, have emerged to be a typical scenario for DMSC and been commonly used for environmental isolation and traffic control of the entire request chain of services for grayscale publishing scenarios, would be reckoned as a typical example for DMSC. In fact, assuming Istio and Kubernetes as the typical infrastructure for Cloud Native Services, the creation of traffic lanes is still executed by various existing network API configurations of the cluster. The service routes are always configured in the cluster and identified endpoints under a service name to implement various scheduling strategies and perform load balancing schemes among multiple optional instances. With another aspect, edge computing, as a distributed computing paradigm, the core idea is to make computing, storage and service processing as close to the clients and customers as possible to reduce latency, improve response speed and enhance data security. When applications are further deconstructed into atomic services as analyzed previously, service inter-connections MAY not only exist in adjacent clusters deployed in a same edge, but also happen with network paths connecting remote edge data centers. Thus, incremental requirements would be raised correspondingly. Relevant use cases and requirements are discussed in and . Therefore, requirements from development of IT/CT applications, infrastructure and patterns give rise to the promising furture of DMSC. Significant features of both distributed paradigm and application deconstruction also bring updated challenges and problems. Correspondingly, this draft proposes technical considerations and primary designs about DMSC. Compared to conventional schemes and patterns, Distributed Micro Service Communication, Collaboration and Association is granted with multiple features and connotations.

Distributed Micro Service Connection and Communication across Multi-edges |Pod 4| ) Hyper Edge ( +-----+ ) \ / ( +-----+ ) Clouds +------------+ \ / +------------+ Cloud/Cluster 1 \ / Cloud/Cluster 3 \ +-----+ / \ ++-----+) / ->|Pod 2|-+ ( +-----+ ) ( | ^ ) ( v | ) ( +-----+ ) Edge ( |Pod 3| ) Clouds ( +-----+ ) +------------+ Cloud/Cluster 2 +-------+ ( ) ( ) ( +----+ ) Central ( |Pods| ) Clouds ( +----+ ) ( +----+ +----+ ) ( |Pods| |Pods| ) ( +----+ +----+ ) +--------------+ ]]>

Micro services would be deployed within various forms, providing functionality for different applications: Considering the deployment phase, services and application functions can be deployed in one or multiple clusters in the form of containers, or deployed based on virtual machines. Service instances can be deployed with multiple instances with dynamic implementation and released based on a Serverless framework. Based on the run-time state, micro services and atomic functions form a diverse set of external services, and correspondingly, often raise various requirements for the resources and network capabilities. Compared to conventional Service Function Chain (SFC), the service functions targeted and discussed in DMSC contains functions from both underlay network and application (L7) services.
Hybrid inter-connections and relations MAY exist between service instances of micro services: The inter-connection, interaction, and collaboration schemes between upstream and downstream micro services are always allocated and implemented within various forms. For instance, upstream functions MAY propose unidirectional notifications. Bidirectional requests and responses MAY also be observed between upstream function and single or multiple downstream functions. Multiple inter-connection forms MAY be implemented simultaneously in an overall DMSC process.
Techniques for hybrid areas and protocal stack layers are required for DMSC: For conventional SFC in which Firewalls and Accelerators MAY be included, service functions are not tended and deployed to terminate data packets. However, for micro services composing L7 applications in DMSC scenarios, packets and payloads are always terminated at endpoints and payloads would be reorganized and regenerated. The provisioning of micro services inter-connection requires collaboration among multiple techniques and extends across TCP/IP stacks.

Based on the considerations above, this draft further analyzes a possible and primary framework and deconstructs it into several planes with incremental functions and features based on conventional network and service mesh techniques.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Terminology

DMSC: Distributed Micro Service Communication.
SFC: Service Function Chain.
QoE: Quality of Experience.
SLA: Service Level Agreement.
OAM: Operation, Administration and Maintenance.
APM: Application Performance Management.

Distributed Micro Service Communication Technical Considerations Technical considerations for DMSC would generally includes administration plane, control plane and forwarding plane. Based on conventional framework of network and cloud native practices, several incremental functions and features are added and deployed.

DMSC Technical Considerations within Hierarchical Patterns

Administration Plane Service Analysis and Operation: The increasingly complex and diverse applications and services would be granted with different characteristics and features for outer users. In terms of orchestration for distributed micro-services, Service Analysis and Operation interprets the external and internal forms of overall applications and services as corresponding deconstruction patterns.

Deep learning: The overall deep learning process would be decomposed into several successive or related phases and steps, data pre-processing, model training, prediction and estimation, model evaluation based on rewards functions, data storage and API interactions for instance.
Live Broadcast: Relevant micro-services MAY include user authentication, live stream administration, live recording, online payment and data migration.

The above deconstructed micro services have serial, parallel, unidirectional, and bidirectional relationships, and their interconnection and collaboration are comprehensively presented as user and outer oriented applications. Service Evaluation and Modeling: There are different and various resource requirements raised by multiple services, including but not limited to:

Computing resources and network capabilities: Computing-related services MAY be sensitive to computing resources, related indicators include CPU cores, available memories, floating number calculation. On the other hand, large amount of data transmission MAY be implemented between upstream and downstream services. Thus, the network connecting them would have to reserve sufficient bandwidth and provide abilities of low packet loss rate.
Constraints for inter-connection patterns: the inter-connection patterns between upstream and downstream services and functions MAY be classified as unidirectional, bidirectional, one-to-one and one-to-many. Furthermore, due to security concerns for instance, relevant services MAY be deployed at adjacent endpoints or a same edge center geographically.

Inter-Connection Patterns between Services and Functions ( ( ) ) ( ( ) )<------------->( ( ) ) ( -- ) ( -- ) ( -- ) ( -- ) -------- -------- -------- -------- 2. One-to-one Or One-to-many ---- ---- ---- ---- ( -- ) ( -- ) ( -- ) ( -- ) ( ( ) )-------------->( ( ) ) ( ( ) )-------------> ( ( ) ) ( -- ) ( -- ) ( -- ) \ ( -- ) -------- -------- -------- \ -------- \ \ ---- \ ( -- ) --->( ( ) ) ( -- ) -------- 3. Successive services MUST be deployed adjacently Or could be deployed distributedly in multiple clouds/clusters +---+ ( ) +-- + ( ) ( -- -- ) ( ( )-->( ) ) ( -- -- ) ( ) +------------+ ---- ---- ( -- ) ( -- ) ( ( ) )-------------->( ( ) ) ( -- ) ( -- ) -------- -------- ]]> Service Orchestration and Scheduling: Service administration would customize strategies or specific algorithms depending on circumstances of infrastructure and required proposals. Providing low-latency experiences or achieving load balance among available instances and resources for instance, SHOULD be selected as specific inclinations for further scheduling.

Control Plane It would be observed in Figure 2 that the components and facilities would reuse and enhance the current Service Mesh (Istio for instance) and network infrastructures. It is also relevantly described in , specific devices would possibly include existing Kubernetes and Istio APIs, network controllers and enhanced distributed Service Gateways and Routers. The control plane would be deployed in distributed, centralized or hybrid patterns. Service Registration and Administration: Based on the results and conclusions analyzed by Service Analysis and Operation, the overall service and included micro services MAY be represented and administered by a series of corresponding identifications. Appropriate identifications would facilitate indicating the service traffic of the workflow in the process of DMSC.

Service Administration by Identification Service 2<->Service 3-->Service 4) (Micro Service Chain with Chain id x) ---- ( -- ) -----------> ( ( ) ) ( -- ) Micro Service Chain with id x, -------- \ Service 1(Pre) Service 1 \ Service 2(Next) \ \ ---- ---- \ ( -- ) ( -- ) v ( ( ) ) ( ( ) ) ( -- )<--------->( -- ) / -------- -------- / Service 2 Service 3 / / ---- / Same Micro Service Chain with id x, ( -- ) / Service 2(Pre) <----------- ( ( ) )v Service 4(Next) ( -- ) -------- Service 4 ]]> Service Discovery and Publication: Depending on existing and mature control plane protocols and interfaces, distributed services and capabilities of infrastructures SHOULD be able to be collected. Relevant schemes include extended protocols, IGP, BGP, BGP-LS, RESTful and Telemetry for instance. The information learned in the control plane MAY include:

Computing resources related to services of specific instances.
Deployment of service instances or possible and scheduled resources utilization.
Network topology information and corresponding TE capabilities.

Service Routes Calculation and Generation: Based on the information collected in Service Discovery and Publication, service routes would be calculated to determine appropriate instances and forwarding paths. Service Routes Calculation and Generation SHOULD follow the intentions identified in Service Orchestration and Scheduling. According to Service Registration and Administration, service routes could be distributed and indexed by appropriate service identifications. Service Inter-connection Configuration: Within conventional schemes for services inter-connection, configurations would be disposed for each relevant endpoints distributed in multiple clusters. Istio, for instance, relys APIs including ServiceEntry, VirtualService and DestinationRules to describe inter-connections and relevant principles. Considering the framework discussed above, service routes would be translated into corresponding configurations issued to clusters for configuring and revising API files.

Forwarding Plane Service Identification Administration: Traffic would be able to be steered according to identifications distributed from the control plane. Also, the service identifications which indicate the target in DMSC would inherit and re-generate from the previous ones in the workflow. Proxies, sidecars or gateways SHOULD be able to administer the inheritance and renewal relationship. Suppose an application includes Service 1, 2 and 3, an identifier of {DMSC process and workflow, Service 2} implies that the successive function is expected to be Service 3. Correspondingly, the identifier would be modified as {the identical DMSC process and workflow, (Next) Service 3}. Service Aware Forwarding: Service routes entries would be distributed from the control plane and involved entities and devices would perform traffic forwarding accordingly. Relevant entries include:

Service aware forwarding entries for edges routers in which forwarding paths are indexed by specific service and DMSC workflow and process.
Service identification administration entries for sidecars, proxies and gateways in which inheritance and correlations in specific DMSC workflows and processes would be specified.

Service provisioning and observability: By implementing and performing OAM or APM schemes, forwarding plane would monitor the circumstances and performance of traffic flows in DMSC workflows. With detections of failures and possible degradations, forwarding plane would be able to support recovering, enhancing and provisioning for traffic flows.

Security Considerations TBA.

Acknowledgements TBA.

IANA Considerations TBA.