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 DuploCloud Whitepaper.

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

Existing Approach

Technology organizations today typically have people with two distinct skill sets: Software Engineers and DevOps Engineers. Compliance functions may be managed by these engineers or by a separate team. In startups and smaller companies, engineers may wear all three hats.

Software Engineers design high-level application architectures that typically include multiple environments (Dev, Stage, QA, Production, etc.), CI/CD pipelines, and diagnostics like central logging, monitoring, and alerting. The business dictates specific compliance standards like PCI, HIPAA, SOC 2, etc. All this information is passed to the DevOps team, who translates it into cloud infrastructure configurations.

DevOps Engineers must manually convert requirements into hundreds or thousands of lower-level configurations, best practices, and compliance controls such as IAM Roles, Instance profiles, KMS Keys, PEM keys, vulnerability scanning systems, virus scanners, VPC, Security Groups, Intrusion detection, etc. This translation is usually done based on human knowledge and subject matter expertise and often requires thousands of lines of code using languages like Terraform, Python, and Bash.

A common misconception is that tools like Terraform fully automate DevOps workflows. Terraform is only a programming language. One needs substantial infrastructure know-how to build automation using Terraform. DevOps engineers often lack awareness of compliance nuances beyond best practices and must revisit and redo their work frequently to ensure compliance.

DevOps essentially requires one to be a programmer, an operator, and a compliance expert: three distinct skill sets that have never traditionally co-existed in the IT industry. This is the primary challenge in the DevOps space.

DuploCloud Approach

DuploCloud simplifies and automates cloud infrastructure management by enabling users to deploy and operate applications without knowledge of lower-level DevOps nuances. The platform requires only three high-level inputs:

1. Application architecture

2. Compliance standards (SOC 2, PCI, HIPAA, etc.)

3. Public cloud provider

With these inputs, DuploCloud generates all the lower-level configurations to adhere to DevOps best practices and required compliance standards.

DuploCloud's core approach to security and compliance is out-of-box compliance so users don't have to learn and apply compliance controls. DuploCloud supports PCI, HIPAA, SOC 2, HITRUST, NIST, ISO, GDPR, and more. See the DuploCloud documentation to learn more about how DuploCloud provides unparalleled security and compliance.

Users interact with their applications through the No-Code DuploCloud UI or our Low-Code Terraform provider, operating directly on cloud constructs like S3 buckets, DynamoDB, Lambda functions, and more, without sacrificing flexibility or scalability. The DuploCloud Terraform provider enables users to achieve the same automation with a tenth of the code and significantly fewer DevOps skills than native Terraform.

Unlike a PAAS such as Heroku, the DuploCloud platform does not prevent users from consuming cloud services directly from the cloud provider. DuploCloud is a self-hosted platform running in the customer's cloud account and can therefore work in tandem with direct cloud account changes. Complex security details (IAM roles, KMS keys, Azure Managed Identities, GCP service accounts, etc.) are hidden, but remain configurable if needed. See this DuploCloud white paper for more information and examples.

DuploCloud uses APIs to handle tasks in the background (e.g., processing user requests, generating configurations synchronously, and calling the cloud provider). Other operations require asynchronous processing, requiring a state machine with retries that continuously identifies and corrects configuration drift and continuously monitors faults and compliance controls.

DuploCloud eliminates the need for extensive manual coding and drastically reduces the need for specialized DevOps expertise. At the same time, the platform ensures efficient, scalable, and compliant cloud infrastructure deployment and management, making it a superior alternative to traditional methods.

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 Plan (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:

• AWS Infrastructure

• Azure Infrastructure

• GCP Infrastructure

• On-premises Infrastructure

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

• VPC peering with the master VPC, which is initially configured in DuploCloud

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

Plans and Infrastructures

Once an Infrastructure is created, DuploCloud automatically creates a Plan (with the same Infrastructure name) with the Infrastructure configuration. The Plan is used to create Tenants.

DuploCloud is a comprehensive solution for DevOps and SecOps, bringing cloud infrastructure management to businesses, regardless of expertise level.

DuploCloud uses templates to create cloud infrastructures comprising hundreds of scaled, managed components. Microservices can be created in minutes, accelerating time to market. Advanced DevOps users can leverage Kubernetes and Terraform to create custom solutions.

For a flat rate per year, personalized onboarding, cloud migration, SecOps questionnaire completion, and auditing support are included.

If there is a way to do something in the cloud, it can be done faster and more efficiently with DuploCloud.

1. Turbo-charging Infrastructure and workspace creation

Did you know that DuploCloud can create a complete cloud infrastructure comprising virtually hundreds of components and sub-components in ten to fifteen minutes? This usually takes hours to develop in a native cloud portal and even longer when using native Kubernetes (K8s). Individual workspaces () can be created in less than a minute.

This acceleration is critical to many of the business value propositions DuploCloud offers. It is why we can perform cloud migrations at such an advanced pace, minimizing downtime and simultaneously ensuring security and compliance (and peace of mind).

2. Built-in scaling and managed services

Virtually all of the services DuploCloud supports are designed to auto-scale as your cloud environment grows exponentially. These Managed Services include automated "set and forget" configurations that dovetail neatly into developer self-service.

As with creating Infrastructures and Tenants, DuploCloud Services are designed for the most common use cases. They enable users to supply a minimum number of inputs to get their service up and running quickly. At the same time, DuploCloud retains the ability to customize, using native Kubernetes YAML coding and custom scripting if needed.

Turnkey access to scalable Kubernetes constructs and managed services ensures minimal implementation detail, making DuploCloud the DevSecOps platform for the rapidly expanding AI/ML cloud space. In this arena, the power of an automated platform becomes readily apparent, not only in setting up your cloud infrastructure but also in maintaining it.

DuploCloud’s ready-made templatized approach to K8s makes adjustments to Kubernetes parameters, such as Horizontal Pod Autoscalars (HPA) for CPU and RAM requirements, easy to access and adjust.

DuploCloud is an efficient, user-friendly means of helping developers automate their environment, reducing the need for constant monitoring or "babysitting." More information on fewer screens and improved ease of navigation enhance monitoring performance.

3. Intuitive self-service DevOps for developers

DuploCloud's simplified UI guides developers and less savvy DevOps users in creating and managing DevOps components and constructs. Even advanced features such as AWS Batch, CloudFront, or setting up a Lambda function are simplified through a combination of procedural documentation, step-by-step UI panels, and even sample code blocks that can be accessed through info-tips in the UI.

Using a templatized approach, potentially complex Kubernetes constructs such as Ingress and Terraform scripting can be managed by developers with minimal exposure to such functionality. Experts who have invested time and money in creating custom solutions using such tools do not need to discard their work. DuploCloud can help integrate existing solutions and workflows, expediting and often automating them during onboarding, often at no additional cost.

4. Ease of use and expedited navigation with JIT access

Do you know that one of DevOps and cloud engineers' biggest headaches is complex navigation and workflows? Using DuploCloud, you can minimize the time you typically spend logging in and out of AWS, Azure, and GCP consoles. Every DevOps and SecOps task can be completed from within the DuploCloud portal, often with significantly reduced clicks.

Compare the keystrokes and navigation between DuploCloud and using a native cloud portal. Often, DevOps engineers "get used to the pain" inherent in many daily DevOps tasks, unaware they can gain back minutes, hours, and days by using DuploCloud.

Some commonly used tools that can be accessed directly within DuploCloud include kubectl, shell access, and JIT access to cloud consoles from within DuploCloud.

5. Turn-key compliance and security

When you let DuploCloud manage your DevOps environment, a scalable and robust SecOps framework and implementation strategy are included. Aligned with industry best practices, our staff of SecOps experts analyzes how your data is stored and transmitted, helps identify the standards you must meet, and then constructs a detailed implementation strategy to meet and exceed those requirements, in addition to creating a scalable model that adapts as your customer base and workloads grow.

Using easy-to-access "Single Pane of Glass" dashboards, DuploCloud provides a granular view of all security issues and compliance controls. Completing questionnaires and passing audits is simple, especially with our 24/7 support.

6. Seamless CI/CD pipeline integrations

Some of the tools we support, such as GitHub Actions, include ready-to-run scripts for quickly creating Docker images, updating Services or Lambdas, uploading data to an S3 Bucket, or executing Terraform scripts.

Whatever your tool of choice, our DevOps experts can help you find the best workflow that requires the least effort to build and maintain.

7. Optimizing DevOps Spending

One of the biggest reasons to consider an automated DevSecOps solution comes down to dollars and cents. It's too easy to spend a lot on a public cloud solution without knowing precisely where your money goes. Sometimes, the components and services you've created (and even ones you've forgotten about) cost you more than they're earning you.

DuploCloud provides several billing dashboards that break down your spending by workspace and component. These dashboards are navigable with just a few clicks. Our support team can help you identify redundancies in services and tools and possibly cut costs by suggesting solutions leveraging the many third-party tools built into DuploCloud.

8. Scalable, simplified, faster Terraform scripting

As with most platforms, the work required to set up and configure a Terraform environment can adversely impact accuracy, productivity gains, and effectiveness. Crafting scalable Terraform requires more skills than simply programming. In addition, as with any code base, it requires constant updating, refactoring, and other maintenance tasks.

Using DuploCloud’s proprietary Terraform provider removes the need to write specifically for one public cloud. You can effectively use the same DuploCloud Terraform code — as it maps to DuploCloud’s constructs, not one specific cloud — with several public clouds. You don’t need to worry about differentiating platform-specific specifications. DuploCloud handles all of this for you in a transparent, replicable manner. You use utilities such as DuploCloud’s Terraform Exporter to quickly clone Tenants and modify configuration details when needed for specific Infrastructures and Tenants.

9. Single Pane of Glass for enhanced observability

Attempting to monitor your cloud infrastructure from the numerous UIs offered by public providers often obscures problems or causes confusion. DuploCloud's monitoring interfaces combine multiple functionalities on one screen; our SIEM dashboard is a primary example of such flexibility and comprehensiveness. Leveraging Wazuh, DuploCloud offers unprecedented insights from a single interface.

Using OpenSearch, Grafana, and Prometheus, you can get single snapshots of logging, auditing, compliance and security vulnerabilities, custom alerting, and fault lists with one click.

10. Cost-reduction leveraging DuploCloud Third-Party tools

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.

To integrate your identity and access-management service logins with your DuploCloud account, reach out to DuploCloud support. DuploCloud supports logins from these services:

• Google SSO

• Microsoft

• Azure Active Directory (AD)

• Okta SSO

Phase 1. Kickoff and Delivery

During Kickoff and Delivery, your team learns about the DuploCloud onboarding flow and what to expect in each phase. Our team works closely with yours to review your project scope and objectives, technical specifications and information, and important dates and deadlines.

By the end of this phase, DuploCloud engineers will configure a DuploCloud Platform in your company's cloud account. We will ask your team for any feedback about the onboarding approach to improve the process in the future.

Your Team Provides:

• Project details, including objectives, technical specifications, and dates/deadlines

• A list of project members and roles

• A new cloud account with access for DuploCloud engineers

• Read-only access to your existing accounts, documents, repositories, and artifacts

DuploCloud Provides:

• Introduction to the onboarding process

• A DuploCloud Platform in your new cloud account

Phase 2. Assessment and Project Planning

In the Assessment and Project Planning phase, DuploCloud engineers create and review a high-level block diagram of your project architecture, verify your containerization needs, and confirm your service configurations, interdependencies, and data migration requirements. We also complete a compliance assessment to ensure your project meets all required compliance guidelines. Together, our teams choose a working-session cadence that aligns with your project needs and timeline.

By the conclusion of this phase, we will provide you with a DuploCloud Portal your team can access and detailed information about the project plan.

Your Team Provides:

• Verification of your project's containerization needs, service configurations, interdependencies, and data migration requirements

• Project plan questions or feedback

• Input for the creation of a working session plan

DuploCloud Provides:

• List of in-scope services and their statuses

• Project plan for the initial workload deployment

• Confirmation of Tenant structure

• A DuploCloud Portal with access for your team

• Recurring working session schedule

Phase 3. Initial Workload Deployment

In this phase, DuploCloud engineers deploy your Dev environment, which includes all in-scope services and applications. During deployment working sessions, we provide your team with comprehensive DuploCloud Platform training. Teams discuss and complete any necessary application-level changes and move on to app containerization, secret management, and Kubernetes configuration (where required). Finally, we review the dev deployment and your team's test plan.

Your Team Provides:

• Necessary application changes

• Dev deployment testing and signoff

DuploCloud Provides:

• A complete Dev environment deployment for testing

• Training on the DuploCloud Platform during deployment work sessions

• Terraform code that can be used as a template for new environments, if needed

Phase 4. CI/CD & Release Management

The CI/CD & Release Management phase involves identifying Services and Tenants to implement pipelines, selecting and agreeing on a pipeline implementation logic, and building the pipelines. DuploCloud builds an operational CI/CD pipeline for each Service and trains your team to add and modify CI/CD pipelines in the future.

Your Team Provides:

• Input for CI/CD pipeline development

• Participation in information/knowledge sharing, training, and demo

DuploCloud Provides:

• An operational CI/CD pipeline for each of the project’s Services

• Training so your team can add and modify pipelines

Phase 5. Production Deployment

The fifth phase, Production Development, focuses on the Production environment. During this phase, the DuploCloud team works with your team to confirm your high-availability requirements and apply any needed adjustments. We also review and update infrastructure component scale parameters (e.g., CPU and memory utilization) and monitoring and alerting configurations. Lastly, we review data migration requirements and formulate a production cutover plan.

Shared Responsibilities

• Deploy the Production environment

• Test the Production environment

• Stabilize production applications

Phase 6. Onboarding Signoff

Onboarding Signoff ensures that your team is prepared for the following stages of support and operations, where you’ll receive ongoing maintenance assistance. We review your ongoing support needs, discuss your plans for the next 3 to 6 months, and establish the next steps with the Operations team to ensure a smooth handover and continuity of service. On top of that, the DuploCloud team delivers an updated architecture diagram, providing a clear and current overview of the system's structure. Lastly, we ask you for feedback about the onboarding experience, which is crucial for assessing the process and identifying areas for improvement.

Your Team Provides:

• Feedback about the onboarding experience

DuploCloud Provides:

• An outline of your next steps with the Operations team

• An updated architecture diagram

DuploCloud offers hands-on 24/7 support for all customers via Slack or email as part of your subscription. Automation and developer self-service are at the heart of the DuploCloud Platform. We are dedicated to helping you achieve hands-off automation as fast as possible via rapid deployment of managed services or customized Terraform scripts using our exclusive Terraform provider. Additionally, you can access various help options, including product documentation and customer support, directly from the DuploCloud Portal. For real-time answers tailored specifically to your organization's needs, ask customer support about Ask DuploCloud, our AI-powered assistant.

How to Contact DuploCloud for Support

• Use the customer Slack or Microsoft Teams channel created during onboarding.

• Email us at support@duplocloud.net.

Included DuploCloud Support Features

Some of the things we support our customers with in real time include:

• Configuring changes in your public cloud infrastructures and associated Kubernetes (K8s) constructs managed by DuploCloud

• Setting up CI/CD pipelines

• Cloud Migration from any existing platform

• Proactive, tailored EKS cluster upgrades designed for minimum downtime impact

• Accelerated onboarding of existing Services

• Troubleshooting and debugging for:

  • Apps and Services crashing

  • OpenSearch or database instances slow or crashing

  • Proof-of-Concepts (PoCs) for third-party integrations, including roll-out to the development environment

  • Downtime during rolling Upgrades

  • Investigation and clarification of public cloud provider billing increases. Many times DuploCloud can suggest a more cost-effective alternative

  • Consolidation of third-party tools for which you currently subscribe that are included with your DuploCloud subscription

  • Adding a CI/CD pipeline for a new service

What DuploCloud Does Not Support or Supports Conditionally

We cover most of your DevOps needs, but there are some. Examples of needs we do not or only partially support include, but are not limited to:

• Patching an application inside a Docker image

• Monitoring alerts in a Network Operations Center (NOC)

• Troubleshooting application code

• Database configuration

How to get help from within the DuploCloud Portal

• What's New: Stay informed about the latest features and updates in the DuploCloud platform.

• FAQs: Access frequently asked questions to quickly find answers to common inquiries.

• Documentation: Browse through our comprehensive product documentation to help you navigate the platform and optimize your usage.

• Contact Us: Reach out to us via an email form for further assistance through this option.

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:

• Application-Managed Multi-Tenancy

• DuploCloud Tenant-per-Customer

• DuploCloud Infrastructure-per-Customer

• Cloud Account-per-Customer

• Hybrid Model

• On-Premises

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

• Documentation: DuploCloud documentation is available to support the development of your DuploCloud tenancy model.

• Support: DuploCloud customer support can assist you in designing your deployment model or creating and managing Kubernetes clusters.

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:

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 . 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:

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:

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

These tutorials are specific to various public cloud environments and demonstrate some of DuploCloud's most common use cases:

is a cloud-based identity and access management platform that provides secure Single Sign-On (SSO), multi-factor authentication (MFA), and lifecycle management for users across applications.

DuploCloud supports using Okta as a source for user authentication and authorization. This integration allows you to log in to DuploCloud and manage user roles, permissions, and platform access using Okta. Okta's group-based permissions system can also be mapped to DuploCloud's user management to manage access to various services within DuploCloud.

This page covers the configuration process for integrating Okta with DuploCloud. To manage Okta users and permissions or perform tasks like generating and managing Okta API tokens, follow the guidelines in the relevant sections of the .

Prerequisites

• . You will need the domain to integrate Okta with DuploCloud.

Configuring Okta with DuploCloud

Step 1. Integrate Okta with DuploCloud

in the Okta Admin Console to enable Okta to integrate with DuploCloud.

Step 2. Configure DuploCloud Authentication Service for Okta

Edit the Configuration File

Update the Duplo.AuthService.exe.config file with your Okta domain and credentials, enabling DuploCloud to authenticate users through Okta and allow single sign-on (SSO) access.

Add the following list of keys to the C:\Program Files (x86)\Duplo.AuthService\Duplo.AuthService.exe.config file, and restart the service (Duplo.AuthService).

Add the DuploCloud Portal URL to the Okta Allowed Callbacks

Step 3. Add the Okta Login Option to the DuploCloud Portal

Configure Okta login allowing users to access the DuploCloud Portal with their Okta credentials.

Add the following list of keys to the C:\Program Files (x86)\Duplo.AuthService\Duplo.AuthService.exe.config file and restart the service Duplo.AuthService.

Step 4. Define Okta User Groups and Permissions in DuploCloud

Assign Group IDs from the Okta Portal to DuploCloud

• OktaAdminGroupId Admin Group: Users assigned to this group in OKTA will be given admin permissions in DuploCloud.

• OktaReadOnlyGroupId Read-Only Group: Users assigned to this group will have read-only permissions.

• OktaSecurityGroupId Security Group: Users in this group will be given security roles.

• OktaSignupGroupId Sign-Up Group: Users in this group will have sign-up privileges.

• OktaTenantGroupPrefix Tenant Group Prefix: These groups use Tenant prefixes such as duploservices-. Group names follow a format such as duploservices-tenant1. All users within this group will be assigned to tenant1.

• OktaTenantGroupPrefix Read-Only Tenant Group Prefix: Use prefixes like duplo-ro-tenant1. Users in this group will be assigned to tenant1 as read-only users.

How to Find Group IDs in the OKTA Portal

Managing Okta Users, Permissions, and API Tokens

• Add and Manage Okta Users:
• Assign Roles and Permissions:
• Delete Users:
• Revoke Permissions:
• Generate and Manage Okta API Tokens:

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.

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:

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.