Abstract: Methods and systems may be associated with an Open Service Broker (“OSB”) Application Programming Interface (“API”) computing environment. A persistent finite state machine may be associated with an OSB API service broker, and a database may store a current state of the service broker. A computer processor of a state machine executor may retrieve the current state of the service broker from the database, and (based on the current state) use the persistent finite state machine to coordinate a distributed transaction workflow for the service broker, the distributed transaction workflow including asynchronous instance OSB API lifecycle operations that span multiple entities. The state machine may then update the database with state outputs for the service broker.

Abstract: According to some embodiments, methods and systems may manage a fleet of multi-tenant logical databases in Relational Database Management System (“RDBMS”) servers for a cloud computing environment. The system may include a pool of physical RDBMS servers (e.g., Postgre-Structured Query Language (“SQL”) servers) and a tenant-aware Application Programming Interface (“API”) that is accessed by tenants. A computer processor of a database allocation engine may receive, from the tenant-aware API, a request to provision a logical database including a tenant identifier associated with a requesting tenant. The database allocation may then select an eligible physical RDBMS server in the pool of physical RDBMS servers and allocate a logical database for the requesting tenant via the selected physical RDBMS server (e.g., using the tenant identifier).

Abstract: According to some embodiments, methods and systems may manage a fleet of multi-tenant logical databases in Relational Database Management System (“RDBMS”) servers for a cloud computing environment. The system may include a pool of physical RDBMS servers (e.g., Postgre-Structured Query Language (“SQL”) servers) and a tenant-aware Application Programming Interface (“API”) that is accessed by tenants. A computer processor of a database allocation engine may receive, from the tenant-aware API, a request to provision a logical database including a tenant identifier associated with a requesting tenant. The database allocation may then select an eligible physical RDBMS server in the pool of physical RDBMS servers and allocate a logical database for the requesting tenant via the selected physical RDBMS server (e.g., using the tenant identifier).

Abstract: Methods and systems may be associated with an Open Service Broker (“OSB”) Application Programming Interface (“API”) computing environment. A serverless runtime may receive an OSB request trigger from an API gateway. A serverless deployment mechanism may, responsive to the OSB request trigger, arrange for compute resources to handle the OSB request trigger be provisioned on-demand. The system may then instantiate an instance of a serverless function with OSB service bindings. The OSB API computing environment might, for example, be associated with a cloud infrastructure provider or an on-premises deployment. Such an approach may provide for on-demand execution, better resource constraints, and/or domain-oriented development.

Abstract: Methods and systems may be associated with an Open Service Broker (“OSB”) Application Programming Interface (“API”) computing environment. A persistent finite state machine may be associated with an OSB API service broker, and a database may store a current state of the service broker. A computer processor of a state machine executor may retrieve the current state of the service broker from the database, and (based on the current state) use the persistent finite state machine to coordinate a distributed transaction workflow for the service broker, the distributed transaction workflow including asynchronous instance OSB API lifecycle operations that span multiple entities. The state machine may then update the database with state outputs for the service broker.