How Vendia leverages the AWS CDK to dynamically provision cloud infrastructure

In this guest post, Ryan Green, senior software engineer, explains how Vendia uses the AWS Cloud Development Kit (AWS CDK) and AWS CloudFormation to dynamically provision cloud infrastructure on behalf of their customers.

Abstract

Vendia enables organizations to securely share data and code across regions, accounts, and clouds at scale. Vendia Unis, or Universal Apps, are multi-node applications where each node is assigned a dedicated cloud provider account containing its own copy of fully isolated resources including ledger databases, GraphQL endpoints, and message queues. By using a novel serverless architecture leveraging the Single Tenanted Accounts on Multi-Tenanted Infrastructure (STAMTI) model and the AWS Cloud Development Kit (AWS CDK), Vendia is able to deploy dynamic cloud infrastructure to single-tenanted, fully isolated AWS accounts on-demand.

SaaS architectures designed to deliver business data – such as tracking employee expenses – can be relatively straightforward. But delivering full-scale infrastructure using a SaaS-style model introduces multiple development and operational challenges. To address these, Vendia leverages the AWS CDK with its Infrastructure as Code (IaC) toolchain and runtime environment to help us build, iterate, and manage the operational complexity required by this type of architecture.

Intro

Vendia’s founding team were the inventors and builders of some of the services that spawned the serverless revolution at Amazon Web Services. At AWS, they cut their teeth building and operating complex, large-scale distributed systems like AWS Lambda, Amazon DynamoDB, and Amazon API Gateway. In these environments, Infrastructure as Code (IaC) is not just a best practice but a necessity. For cloud services, achieving continuous delivery across dozens of data centers while supporting new data center expansion and maintaining a healthy development velocity requires a disciplined approach to infrastructure management and best-in-class tooling.

Despite the sophistication and scale of their deployments, even hyperscaled cloud services usually follows an IaC deployment pattern that deploys static infrastructure, to a static number of cloud provider accounts. Let’s take a look at how that works before discussing why Vendia needed to go further…

IaC 1.0

The concept of Infrastructure as Code has been around for at least a decade. The book Continuous Delivery introduced the concept to many developers back in 2010. Since then, the service offerings, tooling, and techniques around IaC have evolved considerably, but there has been arguably little change in the way IaC is employed.

Typically, in multi-tenant SaaS software, IaC is used by the vendor to author, version, and deploy the cloud infrastructure required to run their services. The infrastructure is commonly deployed via a deployment pipeline, with a release cadence determined by the team. Users interact with these multi-tenant services, but the underlying infrastructure is opaque and more-or-less static (Figure 1).

Figure 1. Simple IaC deployment model

Dynamic Infrastructure-as-code

Vendia uses this model in part to deploy the multi-tenanted components of its architecture. However, Vendia’s multi-tenanted control plane also orchestrates on-demand deployments of dynamic resources to single-tenanted customer accounts. This architecture has been termed Single Tenanted Accounts on Multi-Tenanted Infrastructure (STAMTI). The STAMTI model allows Vendia to provide the benefits of account-level isolation, such as strict security controls, auditing, billing, and quota management. For more information on STAMTI architectures, see this detailed explanation from Vendia’s founder, Tim Wagner.

Unlike most uses of IaC, Vendia uses IaC to deploy dynamic customer infrastructure on-demand, triggered by user actions, rather than through a traditional CI/CD pipeline triggered by Development or Ops teams. Both of these differences have important implications: Because the timing and content of changes are driven by data (and unique customer demands), Vendia’s deployment engine must respond with highly customized actions in real time. Rather than invoking the IaC tool from a build server or development environment, Vendia packages and deploys customer infrastructure by running CDK commands inside an AWS Lambda function to enable it to achieve this level of dynamism. Hosting AWS CDK inside a Lambda function enables Vendia to scale, and reliably run CDK operations, without having to own or manage servers for its IaC needs. It also makes it possible to service multiple customers at once without introducing scaling complexity.

In Vendia’s architecture, when a user requests a configuration change to a Uni, the Vendia control plane deploys the change to all nodes in the Uni. It is critical that these deployments occur safely and quickly. Since a multi-party Uni can span many cloud provider accounts, infrastructure is deployed using the AWS CDK via concurrent Lambda invocations, allowing all the accounts to be updated in parallel.

Figure 2. Vendia’s STAMTI deployment model

Vendia’s dynamic IaC architecture (Figure 2) confers multiple benefits to our customers: Easy, SaaS-style consumption (thanks to our serverless architecture) and highly responsive configuration updates (thanks to our use of the AWS CDK inside a scaling AWS Lambda function). However, developing and operating a system with this level of dynamic capability introduces a host of new challenges relative to static deployment mechanisms. Fortunately, the AWS CDK helps us with many of them!

AWS CDK: Imperative and modular

Vendia uses the AWS CDK as a fundamental building block for its next-generation STAMTI architecture, helping overcome some of the challenges of managing dynamic, per-customer infrastructure.

Declarative infrastructure formats such as CloudFormation or Terraform are reliable approaches for IaC deployments. However, these representations are not ideal for modern deployment models such as STAMTI. Representing dynamic infrastructure in a declarative format requires developers to understand specific IaC domain knowledge, such as macros, custom resources, intrinsic functions, and advanced templating techniques. This requires a specialized skillset and can result in increased code complexity, a challenging developer experience, ultimately impacting development velocity and operational performance. It’s also hard to produce using a compiler!

Instead, by using a familiar, imperative programming idiom, the AWS CDK enables Vendia’s developers to easily implement infrastructure patterns that can be modified and deployed based on customer input. While the infrastructure “template” is stored and versioned in source control, the infrastructure definition itself is generated dynamically at runtime based on user actions.

Common infrastructure patterns can then be refactored into higher-order constructs and libraries, allowing the development team to iterate quickly on new features, maintain existing functionality, and keep the codebase DRY. For example, Vendia has created a common construct for all Lambda functions which decorates functions with critical monitoring aspects like logging, configuration, and alarms, reducing the overhead of adding observability to our functions (and making it harder to get it wrong!)

These constructs can be driven by automated tests, providing confidence that changes will not result in negative customer impact. Integrating a suite of infrastructure tests into a CI/CD system provides the same benefits as traditional unit testing – allowing the development team to move quickly, catching regressions earlier in the development cycle.

Improved developer experience

The imperative model used by AWS CDK provides Vendia developers an improved development experience, enabling us to leverage existing development tools and expected niceties such as auto-completion, inline documentation and the CDK CLI, which adds features like detailed logging on top of the AWS CloudFormation provisioning engine.

Safe deployments

Most importantly, IaC must prioritize deployment safety. Vendia requires that customers are not impacted during deployments, infrastructure is never left in a partially updated state, and persistent data is never removed.

With many years of experience deploying mission-critical systems using AWS CloudFormation, the Vendia team places its trust in CloudFormation’s safe deployment model and first-class integration with AWS services. Using the proven AWS CDK/CloudFormation deployment model, the Vendia team has built a custom deployment framework to safely deploy critical updates across all customer Unis in production, with zero downtime or impact to customer resources.

Customization as a first-class outcome

One of the most critical realizations for us at Vendia was that we’re not the primary users of the AWS CDK…our automated systems are. For us, running the CDK inside of Lambda functions enables the creation of a highly responsive, massively customizable deployment engine that simply wouldn’t be possible with other alternatives, especially ones designed to be written by humans. At Vendia, computers generate most of our deployment plans in response to customer data updates!

Looking forward

The CDK team is iterating quickly, and Vendia looks forward to adopting new features as the AWS CDK continues to evolve. Looking forward, the team expects to continue building additional higher-order constructs, as well as adopting Constructs introduced by AWS, and the open source community.

The expansion of provisioning engines beyond CloudFormation, such as CDK for Terraform, is an exciting possibility, and Vendia looks forward to test driving this technology to support cross-cloud capabilities within a unified codebase.

Conclusion

The AWS CDK is instrumental in helping Vendia move fast, maintain high operational standards, and support modern cloud-native architectures like STAMTI. Vendia looks forward to a long partnership with the AWS CDK and CloudFormation teams, delivering value to our customers.

Disclaimer
The content and opinions in this post are those of the third-party author and AWS is not responsible for the content or accuracy of this post.