Neptune DXP on Kubernetes

A typical deployment arrangement for Neptune DXP workloads is in a containerised setting using Docker images. Docker is a lightweight, standalone, executable package of software that includes everything needed to run an application: code, runtime, system tools, system libraries and settings. Neptune DXP provides as part of its installation package a docker image. This allows its deployment to various container orchestration platforms such as Kubernetes or Amazon ECS (Elastic Container Service). Kubernetes is a solution further propelled into a preferred platform status by the provision of managed services from multiple cloud providers, such as:

In this case study, we evaluate a typical Neptune DXP deployment in a Kubernetes cluster.

You can deploy Neptune DXP as runtime inside a container with multiple containers residing inside a single pod. A more realistic deployment would involve one Neptune DXP containerised instance per pod so that if a pod fails only one Neptune DXP runtime is lost.

However, deploying Neptune DXP in the container alone is not valuable unless we can integrate it to our wider technical landscape and have the ability to auto-scale it based on flexible thresholds.

In the architecture below we now have access to our Neptune DXP microservice runtime filtering API invocations through an API gateway and balancing traffic through an application load balancer using path-based routing to distinguish between microservice using their domain name. In addition, a replica set contains the scaling rules that allow Kubernetes to automatically scale up and down our Neptune DXP instances based on usage-based criteria.

Going a step further in the next iteration of our architecture we need to introduce the ability to containerise a full Neptune DXP stack deployment operating a mix of auto-scaling microservices and application servers:

In our final iteration, we have deployed both our autoscaling Neptune DXP app servers and microservices in the same Kubernetes cluster across multiple nodes for redundancy. A new addition is the use of namespaces to segregate access between the two. The load balancer routes traffic effectively to both workloads after the necessary routing adaptations. Finally, the Neptune DXP app server traffic (authentication, server script executions) is routed directly to the cluster via a firewall as there is no need for an API gateway.