DuploCloud Plans

When you create an Infrastructure in DuploCloud, a Plan is automatically generated. A Plan is a placeholder or a template for configurations. These configurations are consistently applied to all Tenants within the Plan (or Infrastructure). Examples of such configurations are:

• Certificates available to be attached to Load Balancers in the Plan's Tenants

• Machine images

• WAF web ACLs

• Common IAM policies and SG rules to be applied to all resources in the Plan's Tenants

• Unique or shared DNS domain names where applications provisioned in the Plan's Tenants can have a unique DNS name in the domain

• Resource Quota that is enforced in each of the Plan's Tenants

• DB Parameter Groups

• Policies and feature flags applied at the Infrastructure level on the Plan's Tenants

The figure below shows a screenshot of the plan constructs:

DuploCloud Plans and DNS Considerations

When creating DuploCloud Plans and DNS names, consider the following to prevent DNS issues:

• Plans in different portals will delete each other's DNS records, so each portal must use a distinct subdomain for its Plans.

• DuploCloud Plans in the same portal can share a DNS domain without deleting each other's records. Duplo-created DNS names will always include the Tenant name, which prevents collisions.

• The recommended practice for most portals is to set all Plans to the same DNS name, including the default Plan.

• Ideally, custom subdomains will be set in the Plans before turning on shell, monitoring, or logging. If the DNS is changed later, those services may need to be updated.

Infrastructures are abstractions that allow you to create a Virtual Private Cloud (VPC) instance in the DuploCloud Portal. When you create an Infrastructure, a (with the same Infrastructure name) to supply the network configuration that runs your Infrastructure is automatically created and populated with the Infrastructure configuration.

For instructions to create an Infrastructure in the DuploCloud Portal, see:

Each Infrastructure represents a network connection to a unique VPC/VNET, in a region with a Kubernetes cluster. For AWS, it can also include an ECS. An Infrastructure can be created with four basic inputs: Name, VPC CIDR, Number of AZs, Region, and a choice to enable or disable a K8S/ECS cluster.

When you create an Infrastructure, DuploCloud automatically creates the following components:

• VPC with two subnets (private, public) in each availability zone

• Required security groups

• NAT Gateway

• Internet Gateway

• Route tables

Additional requirements like custom Private/Public Subnet CIDRs can be configured in the Advanced Options area.

Plans and Infrastructures

The DuploCloud Platform is an application-infrastructure-centric abstraction created atop the user's cloud provider account. Users can deploy and operate their applications using DuploCloud's simple, user-friendly UI, or use the Low-Code Terraform provider to consume cloud services like S3, DynamoDB, Lambda functions, GCP Redis, Azure SQL, etc., from their cloud provider.

Since DuploCloud is a self-hosted platform running in the customer's cloud account, it can work in tandem with direct changes on the cloud account. This means, that while some security functions (IAM roles, KMS keys, Azure Managed Identities, GCP service accounts, etc.) are hidden from the end user, they are still configurable. See examples in this .

The following diagram shows the high-level abstractions within which applications are deployed, and users operate.

Tenant as a Logical Concept

A Tenant, like a project or a workspace and a child of the Infrastructure, is the most fundamental construct in DuploCloud. While Infrastructure is a VPC level isolation, Tenant is the next level of isolation implemented by segregating Tenants using concepts like Security Groups, IAM roles, Instance Profiles, K8S Namespaces, KMS Keys, etc.

For instructions to create a Tenant in the DuploCloud Portal, see:

At the logical level, a Tenant is fundamentally four things:

• Container of Resources: All resources (except those corresponding to Infrastructure) are created within the Tenant. If we delete the Tenant, all resources within it are terminated.

• Security Boundary: All resources within the Tenant can talk to each other. For example, a Docker container deployed in an EC2 instance within a Tenant will have access to S3 buckets and RDS instances in the same Tenant. By default, RDS instances in other Tenants cannot be reached. Tenants can expose endpoints to each other via ELBs or explicit inter-Tenant SG and IAM policies.

• User Access Control: Self-service is the bedrock of the DuploCloud Platform. To that end, users can be granted Tenant-level access. For example, an administrator may be able to access all Tenants while developers can only access the Dev Tenant and a data scientist the data-science Tenant.

• Billing Unit: Since a Tenant is a container of resources, all resources in a Tenant are tagged with the Tenant's name in the cloud provider, making it easy to segregate usage by Tenant.

• Mechanism for Alerting: Alerts generate faults for all of the resource within a Tenant.

• Mechanism for Logging: Each Tenant has a unique set of logs.

• Mechanism for metrics: Each Tenant has a unique set of metrics.

Tenants and Kubernetes

Each Tenant is mapped to a Namespace in Kubernetes.

When you create a Tenant in an Infrastructure, a Namespace called duploservices-TENANT_NAME is created in the Kubernetes cluster. For example, if a Tenant is called Analytics in DuploCloud, the Kubernetes Namespace is called duploservices-analytics.

All application components in the Analytics Tenant are placed in the duploservices-analytics Namespace. Since nodes cannot be part of a Kubernetes Namespace, DuploCloud creates a tenantname label for all the nodes launched within the Tenant. For example, a node launched in the Analytics Tenant is labeled tenantname: duploservices-analytics.

Any Pods launched using the DuploCloud UI have an appropriate Kubernetes nodeSelector that ties the Pod to the nodes within the Tenant. Ensure kubectl deployments use the proper nodeSelector.

Tenant Use Cases

DuploCloud customers often create at least two Tenants for their Prod and Nonprod cloud environments (Infrastructures).

You can map Tenants in each (or all) of your production environments.

For example:

• Production Infrastructure

  • Pre-production Tenant - for preparing or reviewing production code

  • Production Tenant - for deploying tested code

• Nonproduction Infrastructure

  • Development Tenant: For writing and reviewing code

  • Quality Assurance Tenant: For automated testing

Some customers in larger organizations create Tenants based on application environments: one tenant for data science applications, another for web applications, etc.

Tenants can also isolate a single customer workload allowing more granular performance monitoring, flexibility scaling, or tighter security. This is referred to as a single-Tenant setup. In this case, a DuploCloud Tenant maps to an environment used exclusively by the end client.

With large sets of applications accessed by different teams, it is helpful to map Tenants to team workloads (Dev-analytics, Stage-analytics, etc.).

Tenant Naming Conventions

Ensure Tenant names in DuploCloud are unique and not substrings of one another. For example, if you have a Tenant named dev, you cannot create another named dev2. This limitation arises because IAM policies and other security controls rely on pattern matching to enforce Tenant security boundaries. If Tenant names overlap, the patterns may not work correctly.

To avoid issues, we recommend using distinct numerical suffixes like dev01 and dev02.

DuploCloud supports a variety of deployment models, from basic multi-tenant applications to complex single-Tenant deployments within customer environments. These models cater to different security needs, allowing customers to achieve their desired isolation level while maintaining operational efficiency.

DuploCloud-supported tenancy models, outlined below, include:

Tenancy Deployment Models

Application-Managed Multi-Tenancy

• Description: The application manages tenant isolation with DuploCloud structured pooled tenancy.

• Use Case: The most common scenario is where the application logic isolates customer data. DuploCloud Tenants are then used to isolate development environments (i.e., Nonprod and Prod).

• Infrastructure:

  • Shared DuploCloud Infrastructure (VPC, Tenant, VM/instances, S3 bucket, RDS). Cluster/namespace can also be shared.

  • Scaling: Increase compute instances for Kubernetes worker nodes as needed.

DuploCloud Tenant-per-Customer

• Description: Each customer gets a separate DuploCloud Tenant.

• Use Case: Suitable for older applications not designed for multi-tenancy, or security and compliance needs.

• Infrastructure:

  • Shared network layer (VPC).

  • Separate Tenants per customer with security boundaries (security group, KMS key, SSH key, Kubernetes namespace).

  • Kubernetes cluster is shared and boundaries are through the namespace.

DuploCloud Infrastructure-per-Customer

• Description: Each customer gets a separate DuploCloud Infrastructure.

• Use Case: Provides a higher security boundary at the network layer where customer access and data are separated.

• Infrastructure:

  • Separate VPC and network resources for each customer.

  • Clusters are inherently separate through Tenants isolated in different Infrastructures.

  • Higher cost due to duplicated resources and operational overhead.

Cloud Account-per-Customer

• Description: Each customer gets a separate cloud account.

• Use Case: The least common model, used for customers requiring complete isolation.

• Infrastructure:

  • Separate accounts with a DuploCloud Platform installed in each.

  • Each account then has its own DuploCloud Infrastructure and Tenant.

Hybrid Model

• Description: Combination of the above models as needed to meet specific requirements.

• Use Case: Diverse customer needs.

• Infrastructure:

  • A combination of previous models.

  • Organization-specific depending on requirements: some organizations may be in a pooled application environment whereas others may be more isolated through Tenant boundaries.

Special Hybrid Case: Single-Tenant Deployment in an External Kubernetes Cluster

• Description: DuploCloud imports existing Kubernetes clusters from external environments.

• Use Case: A cluster and resources already exist, or customers require the application or services solution running inside their client's cloud account. Customers are comfortable creating their own Kubernetes environments.

• Infrastructure:

  • Customer's cloud account or On-premises cluster (EKS, AKS, GKE, Oracle, DOKS, etc.) in conjunction with a DuploCloud Infrastructure. This could be any Kubernetes cluster not created by DuploCloud.

  • Manages both multi-Tenant and single-Tenant environments from the DuploCloud UI.

Documentation and Support

Hosts (VMs) are a cornerstone of cloud infrastructure, essential for providing isolated, scalable, and flexible environments for running applications and services. Hosts can exist in various forms and configurations, depending on the environment and the technology stack.

For instructions to create a Host in DuploCloud, see the documentation for your specific cloud provider:

• AWS Host

• Azure Host

• GCP Host

In DuploCloud, Hosts are virtualized computing resources provided by your cloud service provider (e.g., AWS EC2, Google Compute Engine, Azure VMs) or your organization's data center and managed by the DuploCloud Platform. They are used to provision scalable, on-demand infrastructure. DuploCloud abstracts the complexities of provisioning, configuring, and managing these Hosts. DuploCloud supports the following Host contexts:

• Public Cloud: VMs provided by cloud providers and managed through the DuploCloud Platform.

• Private Cloud: Virtualized environments managed within an organization's data center.

• Combination of On-premises and Cloud: A mix of physical hosts, VMs, and cloud-hosted instances.

Several DuploCloud components are used with AWS, GCP, Azure, and hybrid/On-premises Services. These include Infrastructures, Plans, Tenants, Hosts, and Load Balancers. This section provides a conceptual explanation of the following common DuploCloud components:

• Infrastructure

• Plan

• Tenant

• Services

• Diagnostics

For instructions to implement these common components in your DuploCloud account, see the documentation for your cloud provider:

• AWS Use Cases

• Azure Use Cases

• GCP Use Cases

Following is the scope of cloud provider resources (accounts) that a single DuploCloud portal can manage:

1. Azure: A single DuploCloud portal can manage multiple Azure subscriptions. Azure natively has the construct of Active Directory or Entra ID which provides the managed identity which has the ability to have access to multiple subscription. DuploCloud inherits the permissions of the managed Identity

2. GCP: Similar to Azure, in GCP a single instance of DuploCloud can manage multiple GCP projects.

3. AWS: In AWS a single DuploCloud portal manages one and only one AWS account. This is inline with the AWS IAM implementation i.e. even in native AWS IAM model the building blocks like IAM role, Instance profiles do not span multiple accounts. The cross account SCP policies are quite light weight. In fact AWS organizations was an after thought and added almost 10 years later since the launch of AWS. A good place to experience the concept is when a user logs in using AWS Identity center, they have to choose an account and the session is scoped to that. See the picture below of IAM login console

Inline to this, while behind the scenes there is one DuploCloud portal per AWS account, we implement the same experience as the identity center and provide an account switcher in both login page and inside the portal as below

A Service could be a Kubernetes Deployment, StatefulSet, or DaemonSet. It can also be a Lambda function or an ECS task or service, capturing a microservice. Each service (except Lambda) is given a Load Balancer to expose itself and is assigned a DNS name.

DuploCloud Supported Services

For information on cloud-specific Services supported by DuploCloud, see:

• AWS Services

• Azure Services

• GCP Services

DuploCloud supports a simple, application-specific interface to configure dozens of cloud services, such as S3, SNS, SQS, Kafka, Elasticsearch, Data Pipeline, EMR, SageMaker, Azure Redis, Azure SQL, Google Redis, etc. Almost all commonly used services are supported, and new ones are constantly added. DuploCloud Engineers fulfill most requests for new services within days, depending on their complexity.

All services and cloud features are created within a Tenant. While users specify application-level constructs for provisioning cloud resources, DuploCloud implicitly adds all the underlying DevOps and compliance controls.

Below is an image of some properties of a service:

DuploCloud Diagnostics Functions

The DuploCloud platform automatically orchestrates the following main diagnostic functions:

Central Logging

A shared Elasticsearch cluster is deployed and Filebeat is installed in all worker nodes to fetch logs from various applications across Tenants. The logs are injected with metadata corresponding to the Tenant, Service, container ID, Host, etc. Further, each Tenant has a central logging dashboard which includes the Kibana view of logs from applications within the Service. See the screenshot below:

Metrics

Metrics are fetched from Hosts, containers, and Services and displayed in Grafana. Services metrics are collected behind the scenes by calling cloud provider APIs like CloudWatch and Azure Monitor. For nodes and containers, metrics are collected using Prometheus, Node Exporter, and cAdvisor. The Metrics dashboards are Tenant-centric and segregated per application and Service as shown in the image below:

Alarms and Faults

The platform creates faults for many failures automatically. For example, health check failures, container crashes, node crashes, deployment failures, etc. Further, users can easily set alarms like CPU and memory for EC2 instances or free disk space for RDS databases. Failures are displayed as faults under their respective Tenant. Sentry and Pager Duty projects can be linked to Tenants, and DuploCloud will send faults there so the user can set notification configurations.

Audit Trail

All system changes are logged in an audit trail in Elasticsearch where they can be sorted and viewed by Tenant, Service, change type, user, and dozens of other filters.