The IM Account Server

Introduction

The Informatics Matters Account Server (AS) is an early prototype service designed to manage and administer Product Subscriptions required by our IM-related Merchants, which include the Data Manager. It allows services to query products, authorise billable Actions (like running Jobs or storing files) and then bill for those actions. The AS also has the capacity to monitor and enforce Product-defined work and file-system quotas.

The AS is one component in a larger monetization solution.

In our design, monetization of billable services consists of software that falls into three broad functional areas, as illustrated in the following diagram: -

  1. Billable Services

  2. Account Management (including the Account Server)

  3. A Payment Infrastructure

_images/im-as-diagrams.001.png

Today…

We have one Billable Service/Merchant (the Data Manager) and a working prototype for the Account Management solution (the Account Server). The AS permits the creation of Product Subscriptions and has a private (merchant-facing) API to allow merchants make calls into the AS to claim, authorise, and charge for billable activities.

The AS also exposes a public (customer-facing) API that lets users create and delete Products and view their current and predicted billing costs.

We’ll discuss these working aspects of the solution later.

At the moment: -

  • We have a limited customer-facing GUI for the management of Products, Organisations, and Units

  • The AS Swagger API provides better control of these AS objects

  • There is no Payment Infrastructure. No money changes hands through the AS

The AS is currently at a stage where it can function as an authorisation and billing mechanism for our services - the Payment Infrastructure, for now, is not required.

Realisation

The AS is a container image that’s deployed into a Kubernetes cluster using an associated Ansible Role that can be found in our account-server-ansible peer project.

It offers two independent REST interfaces - one interface that’s attached to a public Ingress (intended to be used by customers) and one that’s private, attached to a Service (that’s only available to services co-located in the same cluster).

It consists of three Pods: -

  • as-api - running the AS logic behind the public API, managed by a kubernetes StatefulSet

  • as-internal - the AS logic behind the private API, managed by a kubernetes StatefulSet

  • as-cashier - running scheduled (regular processes) for accounting, managed by a kubernetes Deployment

The AS depends on a PostgreSQL database and RabbitMQ message bus that are typically deployed to an infrastructure Namespace as illustrated below: -

_images/im-as-diagrams.002.png

The public API provides Users (and IM Administrators) with the ability to: -

  • Create Organisations (Admin users only)

  • Create Units (these are groups within an Organisation)

  • Manage (create and delete) Users within Organisations and Units

  • Manage (create and delete) Product Subscriptions (that belong to Units)

  • Manage Assets (text-based material)

  • View Billing

The private API provides merchants with the ability to: -

  • Claim claimable subscriptions (given a product)

  • Release claimable subscriptions (given a product)

  • Pre-authorise billable actions (against a unit or product)

  • Charge for billable actions (using a unit or product)

  • Acquire assets to use within the services of the merchant

Contents: