SINCE VERSION 1.0

What is a Namespace?​

A namespace in PIPEFORCE is the unique name to access your instance and is similar to a tenant id. All services of a certain customer are hosted inside this namespace:

Whenever you want to refer / link to services inside your own instance you need to know your namespace.

For example, to access the web portal of your instance via browser, use the namespace as subdomain part of your pipeforce.net instance url:

In case you do not know your namespace yet, feel free to ask our Support team.

What is a Service?​

Inside each PIPEFORCE namespace multiple services are hosted to run your solutions. Depending on your setup, the number and type of these services could differ. Each service is encapsulated inside a (“Docker”) container and can “talk” to each other:

Public Service​

Usually these services are by default available within your namespace and can be accessed from the public internet. They are therefore called "public" services:

• Portal: A single page application which hosts the user and developer UI. Can be accessed via: https://NAMESPACE.pipeforce.net.

• Hub : This is the core service which manages and executes Commands & Pipelines. Can be accessed via: https://NAMESPACE-hub.pipeforce.net.

• Drive: A data room application to store, edit and share documents and files. Can be accessed via: https://NAMESPACE-drive.pipeforce.net.

• IAM: An identity and access management system to manage users, groups, permissions and logins. Can be accessed via: https://NAMESPACE-iam.pipeforce.net.

Private Service​

Additionally to the services accessible from the internet, there are also some default services which can be accessed only from inside the namespace, so these services can be accessed only by other services running inside the same namespace, but not from the public internet. They are called the "private" services. Examples of such public services are:

• Postgres: A PostgreSQL database which hosts application data.

• Messaging: A messaging broker which is part of the internal message bus.

• Workflow: A workflow engine in order to manage and execute BPMN workflows.

Custom Service​

Beside the default services provided by PIPEFORCE as mentioned above, there could be additional, custom services depending on your license / setup. PIPEFORCE allows to deploy a container easily as an additional custom service into your namespace. This can be a container provided by the Docker Hub or developed and built by yourself.

See the section Microservice for more information about custom services (= microservices).

Resiliency and Scalability

All services run as (“Docker”) containers inside your namespace. It is possible to run multiple such container instances of of the same service with built-in load balancers. Also features like auto-scaling and auto-healing are available here so your solutions can be scaled nearly unlimited.

For example, if you have a service for which you will expect a high load, you can run multiple instances of this service out-of-the-box in order to be able to process all incoming requests accordingly.

It is even possible to auto-scale: For example to auto-run more instances in peak situations and auto-scale down if resources are no longer needed.

The default services provided by PIPEFORCE are already optimized for scaling and will be managed by the PIPEFORCE team. For your custom microservices you have to make sure that you develop them in a way that they are able to be scaled, from the ground up.

In case you have questions how to develop resilient and scalable microservices in PIPEFORCE, feel free to ask our Support team.

What are Staging Tiers?​

Especially in case you develop your own custom microservices, you should think about a staging approach in order to increase the testability and quality of your services.

Typically, the staging process is seperated into at least three tiers: DEV, QA, PROD.

You can learn more about such environments on this Wiki page.

In case you do not write custom microservices and use low code and integration, you can implement such a staging process inside a single namespace. User groups, permissions and versioning can help you to show your solution only to a certain group depending on the deployment phases.

In case you develop custom microservices, you should think about a staging approach using multiple namespaces so each staging tier operates independently from each other.

If you need help to decide your staging approach, feel free to ask our Support team.

DEV​

In this tier the development happens. It is highly dynamically and can change frequently. It is usually part of a continuous integration and deployment process with automated build and testing steps.

QA​

Once development is finished, the solution usually gets deployed to the QA tier. Sometimes also called "Staging". This is the tier where quality assurance tests are done with the system configured as close as possible similar to the production environment. Sometimes this staging tier contains a copy of the production data so migration steps and performance can be tested here as well.

PROD​

In this last tier, the system is operated in production. Once a solution has been tested successfully on the QA tier it can be moved to the PROD tier.