Self-Managed Commerce Infrastructure Options

Infrastructure Options

The first step of a Self-Managed Commerce project is evaluating and choosing from various infrastructure options. Elastic Path does not define specific infrastructure requirements. You can select the following infrastructure options that meet your needs.

• Existing infrastructure you may have that is suitable for building and running an enterprise Java solution like Self-Managed Commerce.
• New infrastructure you might prefer to create for building and running an enterprise Java solution like Self-Managed Commerce.
• CloudOps for Kubernetes, which is a set of tools to provision and configure Kubernetes clusters using Amazon Elastic Kubernetes Service (EKS).

All infrastructure options require investing time and resources. There will be an initial effort required to select and implement your infrastructure, and there will be ongoing effort required to maintain, troubleshoot and support the infrastructure. This ongoing effort will last for the duration of your Self-Managed Commerce system.

note

For all infrastructure solutions, it is your responsibility to own, operate, maintain, and support the infrastructure.

Supported Technologies

Elastic Path provides support if Self-Managed Commerce is deployed on supported platforms, such as certified and compatible platforms. For more information, see Supported Technologies.

Manual Install

Self-Managed Commerce supports manual installation and deployment on bare-metal or virtual servers. For more information, see the manual installation documentation.

Containerized

Any Infrastructure suitable for running containerized enterprise applications can be used to run Self-Managed Commerce containers. Elastic Path provides tooling for building Self-Managed Commerce Docker-style containers. For more information about the containerization tooling, see Containerization.

CloudOps for Kubernetes

CloudOps for Kubernetes is a set of tools to provision and configure a Kubernetes cluster using Amazon Elastic Kubernetes Service (EKS). The resulting Kubernetes cluster contains tools to build and test Self-Managed Commerce code, tools to deploy Self-Managed Commerce applications, and tools to run those applications in a secure, scalable and resilient manner. CloudOps for Kubernetes supports and requires Amazon Web Services (AWS) and uses a very specific architecture with a prescribed set of third-party tools and technologies.

There are advantages and disadvantages of using CloudOps for Kubernetes for your infrastructure. The main advantage is that it can allow you to have infrastructure up and running relatively quickly, provided you are willing to accept the architecture and technology choices inherent in the tooling. Disadvantages include:

• There is a steep learning curve.
• The technologies, solutions and architecture are prescribed for you.
• You must regularly upgrade as described in CloudOps for Kubernetes Support Lifecycle.

Some Self-Managed Commerce customers find that CloudOps for Kubernetes sufficiently aligns with their goals and requirements, and they are able to commit to the requirements of using it. Other customers find that it does not sufficiently align with their goals or technology strategies and they choose a different solution.

For more information, see the CloudOps for Kubernetes documentation.

tip

CloudOps for Kubernetes includes continuous integration (CI) tooling for building and testing Self-Managed Commerce. Self-Managed Commerce container images built using the CloudOps for Kubernetes CI tooling can be run on any infrastructure that supports Docker-style containers. Even if you do not use CloudOps for Kubernetes for your production infrastructure, it may still be a suitable way to quickly provide CI tooling for your Self-Managed Commerce implementation team.

Quick Comparison

The following matrix provides a quick comparison between two infrastructure options.

Characteristic	CloudOps for Kubernetes	Containerized
Deployment model	AWS Public Cloud (self-managed)	Selected by Customer’s Team
Technology choices	Prescribed by Elastic Path	Selected by Customer’s Team
Technical architecture	Prescribed by Elastic Path	Selected by Customer’s Team
Skill requirements	Prescribed by Elastic Path	Resulting from Customer’s Design
Upgrade cycle	Annually or sooner	Resulting from Customer’s Design
Container orchestrator	Amazon EKS	Selected by Customer’s Team
Cluster configuration	eksctl	Selected by Customer’s Team
Infrastructure-as-Code Tooling	Terraform	Selected by Customer’s Team
Continuous Integration (CI) Tooling	Jenkins and Nexus 2	Selected by Customer’s Team
Application Deploy Tooling	Terraform	Selected by Customer’s Team
Production database	Amazon RDS or Aurora	Selected by Customer’s Team
Application Performance Monitoring (APM)	Selected by Customer’s Team	Selected by Customer’s Team
Logging integration	Selected by Customer’s Team	Selected by Customer’s Team
Alerting & monitoring	Selected by Customer’s Team	Selected by Customer’s Team