3D Design Reviews On-Demand with VRED and AWS

ANDY MUI: Hello. Thank you for joining 3D Design Reviews on Demand with VRED and AWS. My name is Andy Moi, and that's my coding companion, Panda, in the picture. I'm a solutions engineer on a neat little team called Open Source and Emerging Technology at AWS.

One of the things I love to do, is to build proof of concepts and prototypes to help bring new ideas and solutions to our customers, partners, and even internally to our service teams. I'm also passionate about developer and user experience and creating unique learning experiences.

I moved up to Portland in 2019, so there's a lot to explore outside of work with my wife, kids, and doggo. And when the rain picks up, there's always games. My 10-year anniversary at AWS is coming up in November, so it's truly an honor to present this session at Autodesk University to mark that milestone.

This session dives into the technical details of a prototype I built last year with my teammate, Eric Cornwell. I'll start with some background to explain how this project came to life. I'll then talk about how we scoped and designed the prototype to ensure we met the agreed upon goals and requirements within a six to eight week build window.

This time window forces us to be intentional about the more important features, and helps us avoid scope creep. Next, I'll deconstruct a solution, diving into implementation details. And finally, I'll conclude with what's next for the project.

As for learning objectives, throughout the presentation, you'll learn how to leverage AWS services to automate workflows and infrastructure configuration with the goal of optimizing deployments, being mindful of cost and resource utilization.

So, a little bit about the project and background. In early 2023, the AWS Partner team aligned to Autodesk and released an AWS Quick Start to help customers launch VRED in their AWS accounts. Around the same time, Autodesk Consulting demoed to us, a POC showing how VRED configuration could be automated with VRED's rich APIs.

While the AWS Quick Start helped customers get started, my team was engaged to build upon the work of these two teams, and to reimagine how VRED deployments could be scaled on AWS. So you may be thinking, if an AWS Quick Start solution exists, how was this project different?

So, the Quick Start is a really effective way to spin up a VRED environment, but the launch experience is highly self-service, may require IT expertise, and takes time to spin up. This prompted us to focus on the end user. How could we simplify the user experience and remove operational overhead?

And by end user, I mean participants that would use VRED for design reviews. So when we are thinking about the solution, we figured it should be as simple as scheduling a meeting where our back end would then manage the lifecycle of deployed resources.

Firstly, this means launching resources in a reasonable amount of time. We aimed to reduce the time to an active collaboration session as much as possible, while still being mindful of cost. To that end, we needed a mechanism to tear down the collaboration session and resources when the design review was done.

One of the main benefits of AWS resource elasticity, we wanted to be able to scale resources, especially costly GPU resources, down to zero when no collaboration sessions were happening. And finally, we thought about the entry point for a collaboration session. In other words, how could it integrate with other systems? Would it be ideal to be able to launch a collaboration session from another application, such as an asset management system or a creative project management system?

Let's dig into the details. So we came up with a solution comprised of two parts. A Golden AMI pipeline, and a VRED session management service, that would utilize those baked AMIs. AMIs, which is short for Amazon Machine Image, contains software and drivers needed to boot EC2 instances with the bundled applications in a repeatable manner. The Golden AMI pipeline is an open source solution that we adapted to build VRED AMIs.

The other part of the solution is the VRED session management service, which applies workflow orchestration to manage the life cycle of VRED instances, to serve design review collaboration sessions. It's fronted by an API to enable customers to integrate the service with existing systems, and more tightly integrate into their engineering workflows.

So let's first dig into the Golden AMI pipeline, since its outputs serve as inputs to the VRED service project. This solution, the Golden AMI pipeline, leans heavily on EC2 Image Builder, which is an AWS service that lets you define pipelines that are comprised of an image recipe, build infrastructure definition, and distribution settings.

The image recipe starts with a vanilla base image and executes components to carry out specific steps to customize the AMI. Our pipelines start with a base windows 2022 operating system. It performs OS level settings optimized for VRED, loads VRED core install media, along with helper scripts stored in S3, and performs the VRED installation.

Finally, it checks the VRED installation as a part of a test component to make sure everything was created as expected. The infrastructure definition in the pipeline simply defines what resources are needed for the instance that actually does the building of the AMI. And finally, the distribution settings lets you define a launch configuration and specify which accounts and regions should receive the image output.

The screenshot shows an example of a pipeline configuration file. The Golden AMI project looks for these JSON configuration files to know what pipelines to create an EC2 image builder. Each AMI version will have its own pipeline. This allows us to create AMIs for different operating systems, and versions of VRED.

Notice the build and test component configuration files that are referenced in the pipeline configuration. We'll talk about that next, and what those are used for. So here's a look into what a build component configuration looks like. It's very readable, so you can get the gist of what's happening.

Think of this as an automated runbook used to configure the OS and desired software. Baking VRED into the AMI lets us cut down VRED launch times from around 30 minutes, which is what we saw with the AWS Partner Quick Start, to about 10 to 12 minutes.

10 to 12 minutes was definitely a more reasonable amount of time for an end user to wait for a VRED collaboration session to be created, especially if they're creating this on demand. We could have considered persistent resources to further shorten that time to an active collaboration session, but remember, we wanted to spin down resources when they're not in use to save on cost.

Once we have these pipeline in component configuration files defined, we can deploy the Golden pipeline using AWS Cloud Development Kit or AWS CDK, for short. We'll touch on deployments and CDK later in the presentation. But for now, notice the CDK deployment creates the desired EC2 image builder pipelines.

For our project, we started with Autodesk VRED version 15.31, and added support for 16.0 when it was released. We also aspire to build in support for the new VRED 25 released earlier this year. With the pipelines deployed, the final step is to run them for each of the VRED versions to output the desired VRED AMIs. This way, we can use them in the VRED session management service.

This can be done using the console, as shown here, where we select the pipeline name and choose the run pipeline from the action context menu. Or, you could programmatically do this using AWS SDKs or using the AWS CLI.

The pipeline will take some time to run, but once complete, outputs an EC2 AMI that can be used to launch instances of VRED core. Notice, there's a versioning system to allow for further customization of the images to be used in different contexts. The outputted AMIs are passed as inputs to the second part of the overall solution, the VRED session management service.

Now that we have the AMIs to use, let's talk about how we designed the VRED session management service to deploy and manage VRED collaboration sessions. There's a lot on this slide, so let's start with the API.

We're using Amazon API gateway to deploy a scalable REST API endpoint. API resources and methods map to a combination of AWS Lambda functions and an AWS step functions execution. AWS Lambda functions are a simple way to execute code in the cloud.

You can see, it's used in a number of ways. One, we use it to retrieve session information from our backend database. We chose Amazon DynamoDB for its scalability and flexible data model, being a NoSQL solution. We use it to store information about each VRED session, as well as information about the VRED nodes that service a session.

Another Lambda function is also used to tear down VRED collaboration sessions. Notice the Lambda function delete method interacts with the VRED core instances directly. It uses the VRED's web API to perform application level configurations, in this case, tearing down a collaboration session and most importantly, terminating the VRED process on the VRED instances.

This is an essential step to ensure the license gets released from the license server. Once VRED is terminated, the EC2 instance is terminated, as well, and a collaboration session is marked as ended in the database. This last piece isn't illustrated in the diagram, to improve readability, but it is no data in our project documentation.

So, let's switch gears to the POST method, which creates a VRED session. This path leans on an integration between API Gateway and AWS Step Functions. AWS Step Functions is a serverless workflow orchestration service--

--and it's easily one of my favorite services for a number of reasons. It has great support for integrations with other AWS services, has an excellent developer experience, and supports a wide variety of workflow use cases.

The next slide, we'll dive deeper into the orchestration details, but for now, just know that an incoming POST request through the API for a VRED session executes an instance of a step function state machine to run a workflow that configures the requisite nodes. It also loads the request to VRED scene file and joins them to a collaboration session.

Once the creation workflow completes, an Amazon SNS notification sends an email to a subscribed email address when the session VRED is launched. More on that later. So now, let's dig into the orchestration details, to understand how we're preparing the collaboration session and the nodes to support it.

This diagram is a different view of the same architecture from the previous slide, only it draws attention to the provisioning workflow. That state diagram you see in the middle of the slide lists all the actions that happen when creating a VRED session.

First, the workflow validates the existence of the requested scene file. There's no point provisioning nodes, if the scene file cannot be loaded or does not exist in S3. Next, it generates a UUID using an intrinsic function available in the Amazon States Language or ASL, for short.

ASL resembles JSON, and is essentially, how you define your state machine. You can also define how data flows through your state machine as it enters and exits each state. You can also define what AWS service actions to carry out each step of the way. This UUID represents a VRED session ID, and is written to the DynamoDB database.

The next state in the workflow is where we prepare the notes. Notice how the diagram shows a stack of node prep operations. This state uses a step functions state called, a map state. This allows for parallel processing of data contained in an array within the execution input.

An example of an execution input is shown in the upper right-hand corner of the slide. Notice the participants key. The array value assigned to that key is what the map state iterates over. This execution input is relayed from the client through the REST API, and is submitted as input to the state machine execution.

Other data in the execution input includes the location of the scene file in S3, whether to set up a password for the collaboration session, specifies the instance type to use, and what VRED version to launch. In our implementation, we provision a VRED instance for each participant in the collaboration session.

Back to the node prep state. Here, we're calling another AWS service, called AWS Systems Manager, SSM, for short. We use a few different capabilities of SSM in this solution. The two main features, especially in this provisioning workflow, are SSM automation runbooks and run command.

The automation runbook executes a node level workflow that uses run command to execute the Python-based helper scripts loaded onto the AMI when we built the AMIs in the Golden AMI pipeline. These scripts retrieve the scene file from S3, configures licensing, starts the VRED core process, loads the scene, and confirms the web API is available before marking the node as ready.

The Python helper scripts use VRED's Python API to perform base VRED setup. The reason why we check for the web API availability, is because the next step in the state machine sets up the collaboration session.

The reason why we didn't do this during node prep, is because all instances needed to be ready in order to join them to a collaboration session. We're using run command for node setup, which leverages the VRED Python API. And we're using Lambda to interact with the VRED web API for application-specific configurations, like joining a collaboration session.

The collaboration session is marked as active, and the database is the final step, and a notification is sent to the subscribed email address. The email notification contains IP addresses for the VRED nodes, and could be individually sent to each participant in the collaboration session.

But for our cases of prototyping, we just sent this to the subscribed email address and then divvied up public IP addresses for users to test the collaboration session. Here, you can see a side by side view of two users in the same collaboration session. And you can notice the floating avatars in the background and collaboration session information on that contextual menu.

This slide shows our simple API definition and backend database structure. The API table speaks for itself, but I want to touch on the database for a second. DynamoDB offers flexibility when defining how to store and query data. The reason we're using generic partition and store keys, is to optimize the queries.

The partition key, combined with sort key conditions, allows for optimized retrieval of data. For example, I can get all VRED node information by querying for the session UUID and using a sort key condition that starts with node. Or, I can just retrieve the session information with a sort key condition equal to info.

So now, let's talk about application configuration. These are parameters that are used by various aspects of the VRED session management service. We're using SSM Parameter Store to store these values that are looked up and used by the SSM automation workflow.

For example, the VRED AMI IDs are stored here, as well as the network license manager IP address. This enables the node prep stage to actually complete and be able to spin up the correct version of VRED, as well as license it appropriately.

Since the VRED session management service is a low ops model when it comes to working with the instances themselves, we rely on automation to handle spin up and tear down of those resources. However, if something goes wrong, a common EC2 key pair is stored as a secret value, also in SSM Parameter Store, to enable admins with break glass access to instances, if needed.

Let's revisit the CDK, which was mentioned earlier in the presentation. AWS CDK is how we deploy both the Golden AMI pipeline and VRED session management service projects. CDK is an extension of AWS CloudFormation, and provides a set of libraries for developers to express AWS resources using common programming languages such as Python, TypeScript, Java, and C#.

CDK comes with the CLI that synthesizes CDK code into an AWS CloudFormation template. The CLI also can be used to deploy CDK projects, which is equivalent to launching a stack using CloudFormation. A key benefit of using CDK, is the ability to record infrastructure in source control.

This is especially interesting if your organization is looking into a GitOps model for managing infrastructure. CDK maintains something called, context, which are values that are related to your AWS account. These values are written when CDK apps are synthesized, but it also makes it possible for administrators to provide context values, which are used during CDK deployment.

In the case of this project, we're using CDK context values to pass in information, such as the VRED AMI IDs and license server information, which are both resources that already exist in the target AWS account where we're deploying the VRED session management service.

When the VRED service CDK is deployed, these values are used for resource creation, but also stored in SSM Parameter Store for processes that need it to do their job.

And that concludes the solution walkthrough. I hope the information was helpful and informational and interesting to you. Next steps for this project, we plan to open source the solution either through our AWS solutions page or another AWS open source channel, such as AWS samples.

We'll be sure to release a blog to announce when the project will be available to customers. For now, here are some links for further reading about the solution and related services and capabilities used to piece this solution together. The handout and presentation download will also include these links for your reference. And with that, thank you so much for listening to this session.