Planning

Considerations when planning a WellLine deployment.

Introduction

When an organization wants to install and manage their own WellLine environment on their own infrastructure, we refer to this as a self-hosted deployment. This document describes the things you must think about in preparation for self-hosting a WellLine Environment.

Maana is actively working to provide alternatives to self-hosting. We have plans for a public SaaS offering (e.g. https://cloud.wellline.com/myorg) as well as private hosted and managed WellLine deployments (e.g. https://myorg.wellline.com). Contact us to discuss these if you want to avoid the need to deploy and manage your own WellLine environment.

Overview

WellLine is a relatively simple application when compared to many enterprise applications. But as a modern cloud based application, it integrates with existing authentication and data services and makes use of multiple infrastructure components provided by Azure.

As such, the installation of WellLine needs planning to ensure the services and resources it uses are available, and that the appropriately authorized people within your organization have been included in the installation process to create or provide access to those services and resources.

Before attempting to install WellLine, you must review this document and complete the appropriate preparation to make sure you have met the requirements.

Experience implementing WellLine across multiple organizations has shown that while the actual installation of WellLine itself takes less than an hour. The planning and preparation of permissions and prerequisites can take days or weeks depending on the complexity of the organizations IT and security processes.

What is WellLine Core?

WellLine Core is the name used to refer to the core set of capabilities that are at the heart of the WellLine solution and user experience. WellLine Core includes:

  • The WellLine Knowledge Application which provides the user interface through which users search and explore timelines of events related to assets (like wells, rigs, and other equipment) and concepts (like problems and actions) as well as view and edit the details of events.

  • The TimeLine Service, which exposes a GraphQL API, which is the main entry point for querying and publishing entities and events. The WellLine Knowledge Application uses this service, as does the TimeLine CLI. Developers can also use the TimeLine Service to integrate event and timeline data into their own applications.

  • The infrastructure required to store and index the entities and events published to the TimeLine Service. This is currently provided using the Elastic Stack.

What Isn't Included in WellLine Core

WellLine Core excludes the infrastructure necessary to support very large scale streaming event ingestions as well as the capability to analyze and enrich events through WellLine hosted event processors. These capabilities are available in an extension to WellLine Core called the Event Engineering Pipeline.

In WellLine Core, the customer must engineer fully formed and enriched events outside the WellLine product using external tools and then push these fully-formed into WellLine through the TimeLine Service GraphQL API. Maana has a standard Event Engineering approach and toolset that we are happy to share with customers. This situation is usually acceptable to customers during POC/Pilot projects but sometimes also to licensed customers that already have mature analytics capabilities or specialist / proprietary requirements and want to use their own Event Engineering approaches.

WellLine Core Use Cases

WellLine Core is suitable for a wide range of WellLine engagements including:

  • Demonstration environments that make use of a preconfigured datasets such as the sample Equinor or BOEM datasets.

  • Small scale POC or Pilot projects where the customer wants to explore their own data in WellLine and is willing to work with Maana to do a one-off data load.

  • Production deployments that can support large numbers of users and high volumes of events but where the customer is willing to do their Event Engineering external to WellLine even in production.

Decide Where to Host WellLine

WellLine software is delivered as a collection of docker images intended to run on Kubernetes. We provide HELM charts that automate the deployment, configuration, and management of the WellLine images to a Kubernetes cluster. But you need to decide which Kubernetes environment you will use to host WellLine. There are many options from cloud providers (e.g. Azure, AWS, and Google Cloud) as well as on-premis offerings (e.g. OpenShift)

The environment we have most experience with is Azure Kubernetes Services (AKS), and we provide detailed instructions and supporting scripts on how to deploy and configure your entire WellLine environment if you decide to host it in Azure. Details of how to deploy Welline to Azure are available here.

We are actively working to provide a similar level of information for OpenShift. But that support is still in active development here.

However, if you use a different Kubernetes offering, as long as you have the skills within your organization to setup and manage the infrastructure, you should be able to use the HELM scripts and images we provide to get WellLine up and running fairly quickly.

Decide on Identity and AuthN/AuthZ Provider

WellLine can integrate with the following IdAM providers:

  • Azure Active Directory (AAD)

  • Windows Active Directory (AD) via Active Directory Federation Services (ADFS)

Azure Active Directory is the preferred option. You should decide which option you want to use before you start the installation process because it does change some of the settings you need to provide.

It is possible to switch IdAM providers after installation without re-installing WellLine.

Decide on DNS Names and Obtaining TLS Certificates

WellLine Core exposes two accessible endpoints:

  • The WellLine Knowledge Application

  • The TimeLine Service GraphQL API

These endpoints must have registered DNS names that are resolvable by the users who need to access WellLine as well as the WellLine services themselves. For example:

  • WellLine Knowledge App --> wellline.myorg.com

  • TimeLine Service --> timeline.wellline.myorg.com

Both of these DNS names will need to resolve to the same static IP address. This IP address is created during the installation process. But you need to know what DNS names you are going to use for WellLine before you start the installation.

The following installation process describes two options to manage TLS termination for: using LetsEncrypt to automatically issue and manage free TLS certificates, or installing your own certificates.

If you obtain your own SSL certificates, we will need base 64 encoded copies of the certificates and secrets as described here https://kubernetes.io/docs/concepts/services-networking/ingress/#tls.

Providing Access to an Elasticsearch Cluster

Access to an Elasticsearch cluster is the main technical dependency of any WellLine installation. You can read more about it on this page.