Description:FIELD OF THE INVENTION

[001] The present invention relates to the field of information transmission in distributed computing environments, and more particularly, to a method and system for dynamic microservice version management and routing that enables efficient and scalable delivery of microservices to tenants in a multi-tenant cloud infrastructure.

BACKGROUND OF THE INVENTION

[002] In recent years, the rapid growth of cloud computing and software-as-a-service (SaaS) platforms has transformed how software is delivered and consumed. Unlike traditional software distribution models, where clients install software on local infrastructure, SaaS platforms operate in cloud environments where software is deployed, managed, and updated centrally by service providers. Traditional models offer significant advantages, including cost efficiency, scalability, and reduced maintenance burdens for clients.
[003] However, the centralized nature of cloud-based software delivery presents unique challenges when it comes to managing software versions across diverse client bases. Clients often have varying requirements for software functionality, compatibility, and regulatory compliance. Each client often has unique requirements based on their existing integrations, business workflows, and adoption timelines such as:
[004] Customization Requirements: Different clients may require access to specific versions of a service to maintain compatibility with their existing systems. Some clients may require specific software customizations or integrations, necessitating the use of particular versions or configurations. For example, client A may depend on Version 1 (v1) of a service due to their established integration, while client B, an early adopter of new features, may require access to Version 2 (v2). A static or universal versioning approach can disrupt operations for certain clients or hinder feature adoption by others.
[005] Backward Compatibility: Clients may rely on legacy systems or workflows that are only compatible with older software versions. Rolling out new features to existing customers can be a complex process, especially when clients are using diverse systems that may not immediately support the latest updates. Updating to newer versions could disrupt their operations.
[006] Compliance and Certification: Certain industries, such as healthcare or finance, may impose regulatory requirements mandating the use of certified or validated software versions.
[007] Performance Optimization: Different clients may operate in varying environments (e.g., different geographic regions, hardware configurations, or network conditions) that perform better with specific software versions.
[008] Balancing Innovation with Stability: Organizations face a dual challenge: delivering innovation to clients who demand cutting-edge features while maintaining stability for clients who prioritize operational continuity.
[009] Eliminating Manual Efforts and Errors in Version Management: Without an automated solution, managing service versions for multiple tenants often requires significant manual effort, increasing the likelihood of errors and inefficiencies.
[010] However, the existing systems fail to manage these diverse requirements. The existing solutions are complex, particularly in multi-tenant cloud environments where resources are shared among clients. Service providers must balance the need for frequent updates and feature rollouts with ensuring stability and compatibility for all clients. The existing approaches to version management in cloud infrastructures often rely on monolithic update models, where all clients are updated to the latest version simultaneously, or on basic segmentation strategies that assign versions to broad groups of clients. These approaches have significant drawbacks.
[011] Operational Disruption: Updating all clients to a new version may lead to downtime, compatibility issues, or performance degradation for clients unprepared for the changes.
[012] Resource Inefficiency: Running multiple software versions simultaneously for broad client segments can lead to underutilization of cloud resources.
[013] Scalability Challenges: As the client base grows, managing version assignments manually or through ad hoc rules becomes increasingly infeasible.
[014] Inflexibility: Broad segmentation fails to account for the nuanced needs of individual clients, leading to a suboptimal user experience.
[015] Lack of granular control: All tenants are forced onto a single version or requires completely separate environments for each tenant resulting in higher infrastructure costs and poor scalability. Lack of flexibility to allow/restrict a particular version of the service for a tenant.
[016] The existing solutions fail to efficiently assign and manage specific software versions for different clients in cloud infrastructures hampering service providers’ ability to deliver customized, reliable, and compliant solutions. These challenges need to be addressed to dynamically adapt to client needs while optimizing resource utilization in the cloud environment.

OBJECTIVES OF THE INVENTION

[017] The prime objective of the present invention is to provide a method and system for seamlessly routing a tenant to a correct version of a microservice in multi-tenant cloud infrastructure.
[018] Another objective of the present invention is to eliminate manual configurations and rigid hardcoding for enforcing the mapping of a tenant to appropriate version of a service.
[019] Another objective of the present invention is to enable modifications to backend services in a multi-tenant environment in a manner that preserves compatibility and operational stability.
[020] Another objective of the present invention is to enable easy updates and audits of version assignments for each tenant in multi-tenant environment.
[021] Another objective of the present invention is to enable simultaneous deployment and operation of multiple service versions on the same infrastructure.
[022] Yet another objective of the present invention is to reduce operational complexity and costs associated with the cloud infrastructure, specifically by enabling zero-downtime updates and deployments of new microservice versions.
[023] These and other objectives of the present invention will be apparent from the drawings and descriptions herein. Every objective of the invention is attained by at least one embodiment of the present invention.

SUMMARY OF THE INVENTION
[024] The present invention addresses the challenges of managing and deploying microservices in a multi-tenant cloud environment, particularly the complexities associated with versioning and routing. Existing solutions often struggle to maintain compatibility, ensure operational stability, and minimize downtime during updates. Present invention provides a method and system for dynamic microservice version management and routing. It enables tenants to access specific versions of microservices, selected based on tenant information and compatibility rules, without requiring modifications to the core backend services that compromise compatibility or stability. By dynamically associating tenants with appropriate microservice versions, the invention facilitates efficient resource utilization and allows for seamless updates and rollbacks.
[025] One aspect of the present invention is a method comprising initiating (102) a request by the tenant for accessing a microservice of a platform providing plurality of microservices, the platform storing plurality of version of each microservice operating independently of each other; extracting (104) tenant information from the request; querying (106) a repository of data to retrieve a specific version of the microservice accessible to the tenant; appending (108) the retrieved version of microservice to an endpoint of the request; and updating (110) a request path to route the request to the specific version of the microservice.

BRIEF DESCRIPTION OF THE DRAWINGS

[026] The accompanying drawings illustrate one or more embodiments of the present invention and features and benefits thereof, and together with the written description, serve to explain the principles of the present invention. Wherever possible, the same reference numbers are used throughout the drawings to refer to the same or like elements of an embodiment.
[027] Fig. 1 discloses a flow chart of the method as disclosed in the present invention.
[028] Fig. 2 discloses architecture diagram of the system as disclosed in the present invention.
[029] Fig. 3 discloses block diagram of an embodiment of the system of present invention.
[030] Further, the areas of applicability of the present invention will become apparent from the detailed description provided hereinafter. It should be understood that the detailed description of exemplary embodiments of the present invention is intended for disclosing the invention and is, therefore, not intended to necessarily limit the scope of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

[031] The embodiments herein and the various features and advantageous details thereof are explained more comprehensively with reference to the non-limiting embodiments that are detailed in the following description. Descriptions of well-known components and processing techniques are omitted so as to not unnecessarily obscure the embodiments herein.
[032] The following description includes the preferred best mode of one embodiment of the present invention. It will be clear from this description of the invention that the invention is not limited to these illustrated embodiments but that the invention also includes a variety of modifications and embodiments thereto. Therefore, the present description should be seen as illustrative and not limiting.
[033] Unless otherwise specified, all terms used in disclosing the invention, including technical and specific terms, have the meaning as commonly understood by one of ordinary skill in the art to which this invention belongs. By means of further guidance, term definition may be included to better appreciate the teaching of the present invention.
[034] As used in the description herein, the meaning of “a”, “an”, and “the” includes plural refence unless the context clearly dictates otherwise. Also, as used in the description herein, the meaning of “in” includes “in” and “on” unless the context clearly dictates otherwise.
[035] As used herein, the terms "comprising," "including," "carrying," "having," “containing,” “involving,” and the like are to be understood to be open-ended, i.e., to mean including but not limited to.
[036] As used herein, the term ‘computer’ or ‘device’ or ‘system’ means “any electronic, magnetic, optical or other high-speed data processing device or system, configured with required software, which performs logical, arithmetic, and memory functions by manipulations of electronic, magnetic or optical impulses, and includes all input, output, processing, storage, computer software, or communication facilities which are connected or related to the computer in a computer system or computer network.
[037] A tenant may communicate a request for a specific service to a host providing software service to multiple clients. Referring to Fig. 1 that discloses a flow chart of a method (100) for providing microservice to a tenant in a multi-tenant cloud infrastructure, the method comprising steps of: initiating (102) a request by the tenant for accessing a microservice of a platform providing plurality of microservices, the platform storing plurality of version of each microservice operating independently of each other; extracting (104) tenant information from the request; querying (106) a repository of data to retrieve a specific version of the microservice accessible to the tenant wherein the specific version of the microservice is selected from the plurality of version of the microservice based on the tenant information; appending (108) the retrieved version of microservice to an endpoint of the request; and updating (110) a request path to route the request to the specific version of the microservice by modifying routing rules and data protocols based on compatibility between the plurality of versions of the microservice and the specific version of the microservice accessible to the tenant.
[038] In an embodiment, compatibility between the plurality of versions of the microservice and the specific version of the microservice accessible to the tenant is checked by applying compatibility rules in accordance with the request.
[039] In an embodiment, the applied compatibility rules enable to serve requests from the specific version of the microservice to another version of the microservice.
[040] In an embodiment, the applied compatibility rules enable to serve requests from the specific version of a microservice to a version of another microservice.
[041] In an embodiment, an appropriate backend version for processing the tenant request is determined based on the specific version of the microservice.
[042] In an embodiment, a response from the specific version of the service is sent back to the API gateway to be relayed to the tenant.
[043] In an embodiment, backend service processes the request by version-specific logic.
[044] In an embodiment, the repository is modifiable and auditable by an administrator, manually or automatically.
[045] In an embodiment, updated routing rules are applied in accordance with the request.
[046] In an exemplary embodiment, the method is implemented by a SaaS platform serving plurality of clients hosted in a cloud network. The plurality of clients rely on different versions of an application for document management. Different clients may require access to specific versions of a microservice to maintain compatibility with the existing system. If Tenant A initiates a request in HTTP format to the platform. The request including TenantID in the request header is sent to the API gateway. The API Gateway extracts tenant information from the request (e.g., Tenant-ID from request header) to identify the tenant and intercepts the request to pass it to the Custom Filter for further processing. The API gateway also delegates responsibility for routing decisions to the custom filter. The gateway queries a repository of data to retrieve the version of the microservice assigned to the tenant. The repository of data may be an SQL database that stores details of the tenants and the service versions the tenants are authorized to use. Each version operates independently, ensuring backward compatibility. In an exemplary embodiment, the repository of data may store the following data:
Tenant A ? Microservice A - Version 1, Microservice B - Version 3, Microservice C - Version 2
Tenant B ? Microservice A - Version 2, Microservice B - Version 2, Microservice C - Version 2
Tenant C ? Microservice A - Version 2, Microservice B - Version 2, Microservice C - Version 1.
Table 1 represents an exemplary primary table that maps tenants to available microservices on the platform and the respective versions.
TenantID ServiceName ServiceVersion
Tenant A Microservice A v1
Tenant A Microservice B v3
Tenant B Microservice A v2
Tenant B Microservice B v2
Tenant C Microservice C v2
Table 1

[047] The repository of data may include a secondary table that defines compatibility between microservices and their versions.
SourceServiceName SourceVersion TargetServiceName CompatibleVersions
Microservice A v2 Microservice B v2
Microservice A v2 Microservice B v3
Microservice A v1 Microservice B v1

Based on the repository lookup results, the Custom Filter dynamically modifies the request path and the API gateway appends the version to the endpoint accordingly. For example, if Tenant A requests access to Microservice B, the path is updated to route the request to /api/v3 of Microservice B. The API gateway applies the updated routing rules and forwards the request to an appropriate service version hosted on the Kubernetes cluster. Thus, request for Microservice B by Tenant A is routed to /v3 of Microservice B. While routing the request, compatibility checks apply between Service A and Service B. For instance, Service A (v1) communicating with Service B (v1) must adhere to any specific data formats or protocols defined by the version. If Service A (v2) is introduced, the compatibility rules must ensure that Service B (v1) and Service B (v3) handle requests from both Service A (v1) and Service A (v2) correctly, possibly requiring data transformations or version-specific routes. Once the data is transformed, backend service processes the request using version-specific logic and the processed response is returned to the tenant via the gateway. For example, if Tenant A is mapped to version 1 (v1) of a microservice, the request is processed using the version-specific logic of version 1 of the microservice. The processed response is returned to the tenant via the API gateway.
[048] The repository of data is utilized for maintaining tenants and specific versions of software service accessible to the tenant. The tenant-version mapping repository of data stores a mapping of the tenant with the specific version in a specific format. In an example, the format may be:
• Tenant A ? v1
• Tenant B ? v2
• Tenant C ? v1, v3

[049] The repository of data acts as definitive source for version control, ensuring consistent mappings across all system components. The tenants can access new functionalities at their own pace without impacting their current integration or workflows, thereby reducing downtime and client dissatisfaction
[050] In an embodiment, the repository is modifiable and auditable by an administrator to allow the administrator to manage tenant-version mappings dynamically. The administrator can update, audit, or query tenant-version mappings through a user-friendly interface or programmatically via APIs. The method is implemented using a relational database, NoSQL database, or distributed ledger, depending on scalability and performance requirements.
[051] Referring to Fig. 2 that discloses architecture diagram of the system (200) for providing microservice to a tenant in a multi-tenant cloud infrastructure. The system comprises: a repository of data for storing tenant information and versions of the service accessible to the tenant; an application programming interface (API) gateway for: receiving a request by the tenant for accessing a microservice of a platform providing plurality of microservices, the platform storing plurality of version of each microservice operating independently of each other; a custom filter for: extracting the tenant information from the request; querying the repository of data to retrieve a specific version of the microservice accessible to the tenant wherein the specific version of the microservice is selected from the plurality of version of the microservice based on the tenant information; appending the retrieved version of microservice to an endpoint of the request; updating a request path to route the request to the specific version of the microservice by modifying routing rules and data protocols based on compatibility between the plurality of versions of the microservice and the specific version of the microservice accessible to the tenant. The system manages and route requests seamlessly based on tenant requirements. The repository of data stores a tenant information and the versions of the service they are allowed to access and acts as a central source of truth for version control, enabling administrators to update or audit mappings easily. The API gateway handles incoming requests from client devices and identifies the tenant based on request headers, authentication tokens, or other metadata. The API gateway performs a database lookup to determine the appropriate service version for the tenant and dynamically routes requests to the correct backend version endpoint, such as /api/v1 or /api/v2. In an embodiment, the API gateway applies updated routing rules and forwards the request to an appropriate version of the microservice. The backend services expose versioned APIs, such as /api/v1/endpoint or /api/v2/endpoint, corresponding to different service versions. In an embodiment, the appropriate backend version for processing the tenant request is determined based on the specific version of the microservice.
[052] The system supports single-version and multi-version access for tenants, enabling tailored solutions based on client requirements. Each version of the microservice operates independently of each other. Further, each version of the microservice encapsulates the functionality of the version, ensuring compatibility and isolation between different versions of the microservice.
[053] In an embodiment, a response from the specific version of the microservice is sent back to the API gateway to be relayed to the tenant. A centralized configuration layer manages tenant-to-version mappings, ensuring consistency across deployments and environments and allows updates to tenant configurations without requiring code changes or redeployment.
[054] In the best mode of working of the present invention, the present invention discloses a method and a system for providing microservice to a tenant in a multi-tenant cloud infrastructure where Tenant A requires legacy features in v1, Tenant B needs access to enhanced features in v2. The present invention enables the API Gateway to route Tenant A’s requests to /api/v1 and Tenant B’s requests to /api/v2 based on the mappings in the database and administrators seamlessly onboard Tenant C to v3 without impacting A or B.
[055] Referring to Fig. 3, the system (300) includes one or more host devices (302) being coupled via one or more networks 304 to one or more client devices (306). Networks (304) broadly represent one or more LANs, WANs, cellular networks (e.g., LTE, HSPA, 3G, and other cellular technologies), and/or networks using any of wired, wireless, terrestrial microwave, or satellite
[056] A host device (302) may be involved, directly or indirectly, in processing requests received from a client device (306). links, and may include the public internet. The host devices (302) may broadly include any number of computers, virtual machine instances, and/or data centers that are configured to host or execute one or more instances of host applications. Each host device (302) may comprise, for example, one or more of a network device, a web server, an application server, a database server, etc.
[057] A client device may be a user device including but not limited to a laptop, desktop, mobile phone, server. The client devices (306) communicate with one or more host applications to exchange information. The communication between a client device (306) and a host application (308) may, for example, be based on the Hypertext Transfer Protocol (HTTP) or any other network protocol. The communication between a client device 306 and host application (308) may include sending various requests and receiving data packets. For example, in general, a client device (306) or application running on a client device may initiate communication with a host application by making a request for a specific resource (e.g., based on an HTTP request), and an application server may respond with the requested resource stored in one or more response packets.
[058] A collection of host devices (302) may be configured to implement a network-based service (308). For example, a provider of a network-based service may configure one or more host devices (302) and host applications (e.g., one or more web servers, application servers, database servers, etc.) to collectively implement the network-based application. In an embodiment, the method may be implemented by a plurality of host devices that work together in one or more clusters to store and manage information and computations within a cloud environment. Each host device may include one or more memories that store instructions for implementing the various components described herein, one or more hardware processors configured to execute the instructions stored in the one or more memories, and various data repositories in the one or more memories for storing data structures utilized and manipulated by the various components. The system includes built-in auditing and logging mechanisms for compliance and traceability. The version of the microservices that will be available for an application is configurable during the application registration process.
[059] A static or universal versioning approach can disrupt operations for certain tenants or hinder feature adoption by others. The present invention has following technical advantages:
• ensures that tenants can access new functionalities at their own pace without impacting their current integration or workflows, thereby reducing downtime and client dissatisfaction.
• automates the process of tenant-specific version routing, improving accuracy and reducing operational overhead.
• deploys and manages multiple service versions concurrently on the same hardware.
• accelerates the time-to-market for new updates
• allows onboarding to the latest version incrementally, ensuring rapid deployment without a complete overhaul of the system.
• allows to restrict a particular version of the service for a tenant
• avoids forcing all tenants onto a single version or requiring completely separate environments for each tenant.
[001] The foregoing description of the exemplary embodiments of the disclosure has been presented only for the purposes of illustration and description and is not intended to be exhaustive or to limit the disclosure to the precise forms disclosed. Many modifications and variations are possible in light of the above teaching.
[002] The embodiments may be chosen and described in order to explain the principles of the disclosure and their practical application so as to enable others skilled in the art to utilize the disclosure and various embodiments and with various modifications as are suited to the particular use contemplated. Alternative embodiments will become apparent to those skilled in the art to which the present disclosure pertains without departing from its spirit and scope. Accordingly, the scope of the present disclosure is defined by the appended claims rather than the foregoing description and the exemplary embodiments described therein.
, Claims:1. A method for providing microservice to a tenant in a multi-tenant cloud infrastructure, the method comprising steps of:
initiating (102) a request by the tenant for accessing a microservice of a platform providing plurality of microservices, the platform storing plurality of version of each microservice operating independently of each other;
extracting (104) tenant information from the request;
querying (106) a repository of data to retrieve a specific version of the microservice accessible to the tenant wherein the specific version of the microservice is selected from the plurality of version of the microservice based on the tenant information;
appending (108) the retrieved version of microservice to an endpoint of the request; and
updating (110) a request path to route the request to the specific version of the microservice by modifying routing rules and data protocols based on compatibility between the plurality of versions of the microservice and the specific version of the microservice accessible to the tenant.

2. The method as claimed in claim 1 wherein compatibility between the plurality of versions of the microservice and the specific version of the microservice accessible to the tenant is checked by applying compatibility rules in accordance with the request.

3. The method as claimed in claim 2 wherein the applied compatibility rules enable to serve requests from the specific version of the microservice to another version of the microservice.

4. The method as claimed in claim 2 wherein the applied compatibility rules enable to serve requests from the specific version of a microservice to a version of another microservice.

5. The method as claimed in claim 1 wherein an appropriate backend version for processing the tenant request is determined based on the specific version of the microservice.

6. The method as claimed in claim 1 wherein a response from the specific version of the service is sent back to the API gateway to be relayed to the tenant.

7. The method as claimed in claim 1 wherein backend service processes the request by version-specific logic.

8. The method as claimed in claim 1 wherein the repository is modifiable and auditable by an administrator, manually or automatically.

9. The method as claimed in claim 1 wherein the updated routing rules are applied in accordance with the request.

10. A system for providing microservice to a tenant in a multi-tenant cloud infrastructure, the system comprising:
a repository of data for storing tenant information and versions of the service accessible to the tenant;
an application programming interface (API) gateway for:
receiving a request by the tenant for accessing a microservice of a platform providing plurality of microservices, the platform storing plurality of version of each microservice operating independently of each other;
a custom filter for:
extracting the tenant information from the request;
querying the repository of data to retrieve a specific version of the microservice accessible to the tenant wherein the specific version of the microservice is selected from the plurality of version of the microservice based on the tenant information;
appending the retrieved version of microservice to an endpoint of the request;
updating a request path to route the request to the specific version of the microservice by modifying routing rules and data protocols based on compatibility between the plurality of versions of the microservice and the specific version of the microservice accessible to the tenant.

11. The system as claimed in claim 10 wherein compatibility between the plurality of versions of the microservice and the specific version of the microservice accessible to the tenant is checked by applying compatibility rules in accordance with the request.

12. The system as claimed in claim 11 wherein the applied compatibility rules enable to serve requests from the specific version of the microservice to another version of the microservice.

13. The system as claimed in claim 11 wherein the applied compatibility rules enable to serve requests from the specific version of a microservice to a version of another microservice.

14. The system as claimed in claim 10 wherein the API gateway applies updated routing rules and forwards the request to an appropriate version of the microservice.

15. The system as claimed in claim 10 wherein the appropriate backend version for processing the tenant request is determined based on the specific version of the microservice.

16. The system as claimed in claim 10 wherein a response from the specific version of the microservice is sent back to the API gateway to be relayed to the tenant.

17. The system as claimed in claim 10 wherein backend service processes the request by version-specific logic.