Summary

The main purpose of managed service is to provide end users an easy way to use a popular software product inside their cloud infrastructure. A database or Kubernetes cluster could be examples of such services. The management of the underlying resources is done by the platform and administrators.

Pricing for a particular service may depend on the amount of resources it utilises (such as CPU, RAM and disks), have a fixed fee or both.

Participants

Managed Services within the Warren ecosystem are organised through third parties. This means that the Managed Service provider can be the local infrastructure provider themselves or any other company that offers a service that can be fully automated and managed. Managed services can be offered across all Warren deployments and therefore are great for the service providers to reach a large audience, but also infrastructure providers to cover a wider range of services on their infrastructure.

Business model

From the end-user perspective, they pay for the service according to prices and pricing model, just like for any other resource. From Warren platform point of view, the service price consists of three different costs: infrastructure cost, Warren’s cost, and service cost.

Pricing

Managed service has a price multiplier, usually 3, but this can be configured per service. All prices of resources that are created for the service are calculated as usual and then multiplied by the multiplier. So, if a regular VM with 1 CPU, 1 GB RAM and 30 GB disk costs 13 € per month then a database with one node with same parameters will cost 39 € per month.

Managed database example

DBaaS are often priced at 3 times the underlying infrastructure cost. Let’s say Managed PostgreSQL with one failover node (2 vCPU, 4 GB RAM = 15 € / mo., multiplied by 3 for the service and by 2 for having two nodes) costs 90 € for the end-user. That would be split the following way: Warren (20%) gets 18 €, managed service provider (2/3) 48 €, and infrastructure provider 1/3) 24 €. In this example, the price ratio between parties would stay the same as larger end-users are buying bigger machines.

End-user payments are collected by the infrastructure provider. Warren will collect its own share and Managed Service provider share from all deployments. Managed Service providers will then collect from Warren. The exception is when infrastructure provider offers the service themselves as then there is no point in moving it back and forth.

Responsibilities

End-user experience example – managed DB

Managed service can be created by users from the “services” menu. The process is similar to creating a Compute resource, aka Virtual Machine.

Once the service is created, the user can view all related details on a dedicated page:

Open

Database service launched

Among other information, connection details and credentials relevant to the service can be obtained from this page.

Currently, the service cannot be stopped or suspended, only removed (discarding related resources and data as well).

Open

The service can be used either from the public Internet or from its assigned private network. For example, another VM can be created in the same VPC “My Network”, it can then access the DB service using connection details shown on the service page:

Backups

For every VM instance associated with the service, a backup is created daily and up to 7 most recent backups are kept.

For automated fail-over services, backups are created but they cannot be restored from the UI.

Restricting access to service instances with addresses whitelist

Each running service is assigned a whitelist of addresses or networks that are allowed to connect to service host or hosts.

• An empty list means all incoming connections from any source are allowed, this is the default.

• IPv4 addresses are supported. Single IP address is just 176.112.157.203, for instance.

• Network (a block of IP addresses) can be specified using a CIDR notation, e.g. 10.33.67.0/24

Automatic fail-over

A managed Database service can be created with a fail-over node. In this case, a service with two nodes (virtual machines) is created and in case of the main node failure, the backup node is used.

A virtual IP is used for the service. It is automatically assigned to the backup node on failure.

Data has replicated automatically between the nodes

The feature is currently available for PostgreSQL only.

To create the service with a fail-over “1 node” has to be selected in the “Fail-over nodes” dropdown.

As two Virtual Machines are created the created service has a double price compared to the same service without automatic fail-over nodes.

Both nodes are visible on the metrics page

Features planned on the road map

Following improvements and changes are subject to further development:

• make the number of backups kept configurable;

• easily grow disk size (currently possible by a request to the support team);

Service management (managed DB example)

Managed databases are pre-configured VM images that auto-configure themselves upon service start. The first two example service images were provided by Warren and afterward, all the updates & new services should be created by the Service Provider. Provided MariaDB is a single node simple database. Postgres has two modes, a simple single node and a redundant setup with a failover (master-slave replication). Postgres failover is achieved with Postgres replication, Pacemaker, and Corosync services. The pacemaker has a health check on both Postgres instances and if the current "master" node fails then virtual IP is switched to the failover node and Postgres master-slave roles are switched (failover node becomes fully capable master node).

When a customer creates a Managed Database they don't get access to virtual machines providing the service but only to the service itself (as described above). The service provider is responsible for all the operations needed to maintain, upgrade and support the provided service. Service Provider has admin access to all the service-related virtual machines serial consoles. If a managed database service provider needs more features from the Warren platform to use a specific tool (like Gardener in the case of Kubernetes) then the Warren team is happy to develop these integrations.

Managing DB service

A list of all created services is available to administrators, navigate through “Admin” → “Services”.

For each service instance, there are one or more virtual machines running associated with it. These VMs are only visible and accessible to admin users. One way to locate VMs of a service is to use the “View” button in the services list:

The service with automated fail-over is shown with 2 VMs in the Admin Services' list

Service VMs can also be found in the common VMs list.

Accessing the machine using a virtual console

In the VMs table the last column has an “actions” button, that allows to control and manage VM:

From this menu, a virtual console can be started as well. An OS in use by service VM is created with a random password for admin user, this password can be reset at the virtual console:

A random password for user “admin” will be generated and shown. It will be shown here only as long the tab is open, so you might want to write it down.

Resizing the provisioned resources

Another action available from the VM list is VM Details, it takes to the page where VM resources can be scaled (vCPU, memory) and disk size can be increased. These actions are only available with a stopped state of VM.

Currently imposed limitations

• The VMs have only a private network interface enabled, and as a side-effect, there is no access to the internet (neither in nor out).

How Services should be managed

Every Managed Service provider has its own tools and best practices to offer the service. Warren will carry out the work needed to make the service seamlessly available on the platform from API and infrastructure management to UI and billing etc.

Managed Kubernetes example (not publicly released yet)

Managed Kubernetes is offered using Gardener. The technical setup is that the service provider has its own user account in the infrastructure provider’s console (end-user account). Under their account Gardener is deployed to manage other end-users Kubernetes clusters (under this account also master nodes are run). Warren will carry out all work necessary to accommodate the service and make it available in the UI and API as part of the general user experience. When the end-user purchases a new Kubernetes cluster then this Gardener will get notified and given access to specific VMs to deploy Kubernetes. Through the same workflow and technical means also the updates are carried out for the end-user clusters (if they have so selected in their Kubernetes service configuration).