Case Study

TimberFire Technologies is a Software and Platform as a Service provider. They will like to incorporate Kubernetes as a Service (KaaS) solutions for their customers. For this purpose, they have brought in Red Hat to help determine the technology stack. They have worked with Red Hat before and have been exposed to OpenShift. However, this time they have new requirements and are not sure OpenStack by itself will help them. After interviewing their customers, TimberFire Technologies have compiled their top requirements.

  • Their customers will like to be able to use matured cloud services with established SLAs from reputable cloud providers. The top services required by their customers are SQL and NoSQL databases, Object Stores, and Message Brokers.

  • Their customer will like to be able to run tests in multiple environments before deploying to production. These environments will be short lived and sometimes even ephemeral. It is important that each customer's test environment can be provisioned and configured quickly.

  • They will like to be efficient with their infrastructure and are therefore looking to set up their platform to be multi-tenant.

  • They will like to allow their customers to provision their services on-demand or have them available in a service pool ready to be consumed by their application.

After analysing TimberFire’s requirements, Red Hat has determined that a Pipeline using OpenShift will be a good baseline for TimberFire KaaS offering. In addition to OpenShift, Red Hat has determined that given their cloud service requirements, a new product, currently under development, called Primaza is a good candidate to be evaluated by TimberFire.

RedHat PoC

TimberFire will like to work on a PoC with Red Hat and one of their customers: Sapiens Inc.

Sapiens is building an online retail application that specifically requires a NoSQL database, a PostgreSQL Database and a Queue.

image

Before the PoC work starts Red Hat will like to show TimberFire and Sapiens Engineering Leadership a Demo of their Primaza v0.1 release to gauge whether there are any missing requirements that can be addressed in parallel while the PoC is being run.

Tenants

TimberFire creates a Primaza Tenant for each isolated environment a customer asks for. Two Primaza Tenants would not share information among them.

TimberFire usually configure a Tenant to be spread across two different clusters, called for simplicity main and worker.

image

Practically, they provide a default configuration composed by three namespaces:

  • primaza-mytenant on main: where the Primaza's Control Plane is installed
  • services on worker: a (Service) namespace in which Primaza's Service Discovery is configured
  • applications on worker: an (Application) namespace in which Primaza's Binding feature is configured

Personas

TimberFire provides to each customer credentials to work on their Tenant.

image

More in details, TimeberFire provides by default the following accounts:

  • Tenant Administrator: has full control over all the Tenant namespaces
  • Service Administrator:
    • Access to manage Discovery Resources life-cycle in Primaza's Control Plane namespace and Service namespace
    • Access to setting up 3rd-party integration in Primaza's Control Plane
  • Application Developer: has full control over the Application Namespace

Environments

In each Tenant can live multiple Environments. Environments related data are stored in the same Control Plane, so isolation can not be guaranteed. However, it is very easy and quick to create an Environment and services in the same Tenant can be shared across multiple environments.

This feature can be very valuable for creating short-lived or ephemeral environments for running tests.

image

An Environment is handled in Primaza as a soft-tag. To instantiate a connection to a target cluster, you create a ClusterEnvironment resource. Each ClusterEnvironment has an environmentName field. That's all you need for creating or joining an Environment.

Primaza Multi Cluster Environment Setup

When Sapiens is successfully on-boarded, a pipeline is run for creating and setting up their tenant.

The Automation makes use of primazactl for creating the new Tenant. primazactl is a command line tool, developed for making the Tenant management as easy as possible.

image

Demo Output

❯ ./bin/main --env-setup
Create Multi-Cluster environment with Kind
==========================================

# Create a Primaza Tenant on cluster 'main' [1/4]:

> ./bin/primazactl create tenant primaza-mytenant --version latest --context kind-main
Primaza main installed

# Join a worker cluster to Tenant 'primaza-mytenant' [2/4]:

> ./bin/primazactl join cluster  \
    --version latest \
    --tenant primaza-mytenant \
    --cluster-environment worker \
    --environment demo \
    --context kind-worker \
    --tenant-context kind-main
Install and configure worker completed

# Create an Application Namespace on joined cluster 'worker' [3/4]:

> ./bin/primazactl create application-namespace applications \
    --version latest \
    --tenant primaza-mytenant \
    --cluster-environment worker \
    --context kind-worker \
    --tenant-context kind-main
application namespace primaza-application was successfully created

# Create a Service Namespace on joined cluster 'worker' [4/4]:

> ./bin/primazactl create service-namespace services \
    --version latest \
    --tenant primaza-mytenant \
    --cluster-environment worker \
    --context kind-worker \
    --tenant-context kind-main
service namespace primaza-service was successfully created

As a result, among the other resources, the following deployment are created:

> kubectl get deployment --context kind-main --namespace primaza-mytenant
NAME                                         READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/primaza-controller-manager   1/1     1            1           18m

❯ kubectl get deployment --context kind-worker --namespace applications
NAME                               READY   UP-TO-DATE   AVAILABLE   AGE
argocd-applicationset-controller   1/1     1            1           18m
argocd-dex-server                  1/1     1            1           18m
argocd-notifications-controller    1/1     1            1           18m
argocd-redis                       1/1     1            1           18m
argocd-repo-server                 1/1     1            1           18m
argocd-server                      1/1     1            1           18m
ingress-nginx-controller           1/1     1            1           18m
primaza-app-agent                  1/1     1            1           9m

❯ kubectl get deployment --context kind-worker --namespace services
NAME                           READY   UP-TO-DATE   AVAILABLE   AGE
ack-sqs-controller-sqs-chart   1/1     1            1           18m
primaza-svc-agent              1/1     1            1           10m

Services

Sapiens wants their Application Developer to publish their simple e-commerce webapp:

image

So the Service Administrator is asked to provision the following services:

  • An AWS RDS DBInstance
  • An SQS Queue
  • A DynamoDB that sends its events via DynamoStreams and a Lambda function to the SQS Queue

Service Administrator: Manual registration

The Service Administrator knows that they had already deployed but never used an RDS Postgres Database. They thinks the Application Developer may use this unused database.

As they got all the information needed by the Application Developer to connect to the database, they manually creates a RegisteredService for the RDS Database.

Service Administrator: Service Discovery

For provisioning and managing the SQS Queue, the Service Administrator wants to use the AWS Controllers for Kubernetes (ACK) he already installed in the Service Namespace.

Then, the Service Administrator will rely on the Primaza's Discovery mechanism to discover the SQS Queue and create automatically the RegisteredService.

Service Administrator: 3rd party integration

For the DynamoDB instance as it is a more complex infrastructure the Service Administrator would like to rely on CloudFormation templates and the AWS Service Catalog. They already has a AWS Service Catalog configured and he created the Product for the DynamoDB, DynamoStreams and Lambda.

Also, they has configured an integration with Primaza. The integration is make by a Simple Notification Service (SNS) that forwards AWS Service Catalog events to a Lambda function. The Lambda then uses the event to create a Registered Service into Primaza's Tenant.

image

Claiming

Sapiens has an e-commerce application they are developing for a customer. It's fairly simple as of now: it's still in development. It's composed of 3 different microservices, one for the front-end, one for managing orders, and one for managing the catalog.

You can select an object from the store and buy some units. No need for payment or other complex stuff; the order will be stored and the catalog updated taking track of the total units bought for each object.

More in details, when an order is accepted, data in DynamoDB is updated and the corresponding DynamoStreams' event is fetched and placed in the SQS Queue. The catalog microservice is constantly monitoring the SQS queue and updating its own database.

Leveraging on Primaza's Claiming and Binding functionalities, Sapiens can now just publish the application and claim the services they need, without any need of managing Secrets.

Application Developer: Publish the application

The Sapiens Application Developer is responsible for the whole demo-app application.

image

They use the ArgoCD instance TimberFire is providing by default in the Application Namespace.

Demo Output

image

Work in Progress Features

Primaza's Authors are working on creating a vibrant and engaging community around Primaza.

Most of the new features are planned and discussed on:

Main feature the Primaza community is discussing are:

Credits

Contributors

Reviewers

Architects

Tools