Microservice Identity Management Zero Downtime Upgrades
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current identity management systems in cloud environments face challenges in providing secure and unified access across diverse devices and user types, including employees, customers, and partners, while maintaining consistency in security measures and preventing unauthorized access.
Innovation Solution
The implementation of a cloud-based identity management system using a multi-tenant, microservices architecture that provides a unified Identity Cloud Service (IDCS) with features like authentication, authorization, auditing, and federation, enabling secure access across various channels and environments through microservices-based identity management, access control, and adaptive authentication.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Loss of time
If a monolithic identity management system is used, then system simplicity is maintained, but system downtime during upgrades increases
Solution Approach 1:
The identity management system is divided into multiple independent microservices (e.g., authentication service, authorization service, account management service). Each microservice can be deployed, updated, and scaled independently, allowing zero-downtime upgrades by routing traffic between different service versions.
Solution Approach 2:
A service mesh or API gateway is introduced as an intermediary layer that manages traffic routing between clients and microservice versions. This intermediary enables seamless transition between old and new service versions during upgrades, maintaining system availability while facilitating architectural complexity.
2Adaptability or versatility
If version-specific URLs are used to route to different microservice versions, then service version control is achieved, but URL management complexity increases
Solution Approach 1:
The service mesh or API gateway provides universal traffic management capabilities that work across all microservice versions. Instead of requiring clients to manage version-specific URLs, the gateway automatically routes requests to appropriate service versions based on configuration, headers, or other routing rules, eliminating the need for complex version-specific URL management.
Solution Approach 2:
The service mesh acts as an intermediary that abstracts away version management complexity from clients. It handles URL routing, version negotiation, and service discovery internally, allowing clients to interact with a simplified interface while the intermediary manages the complexity of multiple service versions.
3Productivity
If microservices architecture is implemented, then system scalability and zero-downtime upgrades are enabled, but system complexity increases
Solution Approach 1:
The system is segmented into independent microservices that can be developed, deployed, and scaled separately. This segmentation enables parallel development and deployment pipelines, allowing the system to scale horizontally by adding more service instances without increasing overall system complexity through standardized service interfaces and containerization.
Solution Approach 2:
A service mesh or API gateway serves as an intermediary that manages the complexity of microservice communication, routing, and orchestration. This intermediary layer provides standardized patterns for service interaction, reducing the complexity burden on individual services while enabling scalable architecture through centralized management of cross-cutting concerns.
Data Source
AI summary
Embodiments implement data versioning in a cloud-based identity management system. Embodiments provide a first microservice for performing an identity management service and having a corresponding first version application programming interface (“API”) that identifies the first microservice. Embodiments provide a second microservice for performing the identity management service, the second microservice comprising a new version of the first microservice and having a corresponding second version API that identifies the second microservice. Embodiments receive a request for performing the identity management service from a client of the identity management system, the request including a uniform resource locator (“URL”), where the first version API or the second version API are identified in the URL. Embodiments then perform the identity management service using either the first microservice or the second microservice based on the request and using tenant data stored in a database.