How Stellantis built the serverless self-service portal for the Virtual Engineering Workbench

Introduction

Developers face many challenges when building web-based enterprise applications, including rapid prototyping to test ideas, setting up the infrastructure for static web site asset hosting, hosting business logic, exposing APIs and ensuring security across all layers. In this blog post, we show how Stellantis uses AWS serverless services to help build its Virtual Engineering Workbench (VEW) web application that is used by Stellantis employees and partners to help expedite the development of Stellantis’ software defined vehicles (SDV).

Overview of the solution

VEW is a cloud-native, fully serverless web application built on AWS services through a collaboration between Stellantis and AWS. This architecture helps enable the application to be highly available and scalable to Stellantis developers without having to manage any infrastructure. VEW consists of three major pillars: 1/ the React web application 2/ the backend, including the business logic, and 3/ the development process and Continuous Integration/Continuous Delivery (CI/CD) pipeline. In the following paragraphs we will describe the solution architecture and how Stellantis implemented the design.

VEW web application utilizes AWS Serverless services such as Amazon API Gateway, AWS Lambda and Amazon DynamoDB. This means that there is no need for Stellantis to provision resources and no need to guess capacity because the AWS services used by Stellantis scale automatically based on demand.

The AWS account for the web application hosts the static web application for the frontend and APIs, business logic and databases for the backend. The backend is separated into bounded contexts following the domain-driven design principles. Communications with external systems are made either synchronously via APIs or asynchronously via events. All logs, metrics and alerts are accumulated in Amazon CloudWatch.

Hosting the React web application

The VEW web application uses a React framework, hosted on an Amazon S3 bucket and distributed via the Amazon CloudFront content delivery network which helps make the web application accessible to Stellantis developers globally at low latency. Following security best practices, we customize the content CloudFront delivers with the Lambda@Edge function to allow access to the static content only for authenticated users and use AWS WAF to allow the web application access only from the corporate IP space.

The web application utilizes Amazon Cognito to handle user authentication and JWT exchange. React application uses the amplify-js library to seamlessly integrate authentication and authorization of the application with Amazon Cognito, Amazon CloudFront, Lambda@Edge and Amazon API Gateway.

Amazon Cognito User Pool uses Identity Federation to enable corporate Open ID Connect authentication. When users successfully authenticate in Stellantis directory services, Amazon Cognito generates its own JWT token, then uses it to authorize REST API requests.

We use the Cloudscape design system to quickly build a web application prototype. Cloudscape is a React.js based open-source design system and includes reusable React components for various elements such as buttons, dropdowns or checkboxes which are customizable to fit the project’s needs. Design patterns such as table views or split views consist of a group of components and can be utilized to build entire pages quickly.

In this section, we discussed the development of the VEW web application and will now outline the backend structure supporting it.

Hosting the business logic

We follow domain-driven design patterns when designing the backend of the web application. VEW architecture consists of multiple highly cohesive and loosely coupled bounded contexts, where each bounded context contains logic of a specific business area. Examples for these bounded contexts include products which refer to functionality around the workbenches themselves or directory services for Active Directory integration. We use hexagonal architecture to structure our code within the bounded context.

A typical bounded context utilizes API Gateway to serve data to the clients using REST API. We use AWS WAF to allow API access only from the corporate IP space. VEW APIs use an AWS Lambda authorizer to validate JWT tokens and to execute custom business logic to decide if a user’s role is authorized to call the respective endpoint in the API.

We use Lambda to execute business logic of each bounded context. Each bounded context utilizes multiple Lambda functions to serve as an entry point to the application. We use Python 3.11 as the language for the backend and we leverage Lambda Powertools for structured logging, tracing, metrics and routing.

We use DynamoDB to store metadata related to each bounded context. For example, we store workbench metadata associated with provisioned resources in the bounded context responsible for provisioning, we store user metadata in the bounded context responsible for user management.

We use Amazon EventBridge to enable asynchronous inter-process communication between the micro-services. Events are also used to communicate with other AWS accounts, which are used by other teams in the VEW project.

We utilize AWS Service Catalog as the backbone of product management in VEW. The web application accesses Service Catalog through APIs. VEW provisions workbenches as Service Catalog products in multiple AWS accounts created for a particular project. We use AWS Security Token Service (AWS STS) to obtain temporary credentials to perform actions on these accounts. There is a trust relationship between use case accounts and web application account established through AWS Identity and Access Management (IAM), facilitating secure cross-account access.

We use Lambdas in isolated subnets with AWS Transit Gateway to access applications which reside in Stellantis’ on-premises network. The network connection is established through AWS Direct Connect.

We open-sourced the skeleton of the backend code structure here and explained how to develop in Python with Lambda using hexagonal architecture step by step.

Concluding our discussion on the backend architecture, we now focus on our development process and CI/CD practices.

Enabling seamless deployment with Trunk-based development (CI/CD)

We choose a trunk-based development process that enables controllable and rapid release cycle of new features. We only have one main branch and short-lived feature branches merging to the main branch multiple times a day. This forms the basis for both continuous integration (CI) and continuous delivery (CD) as we maintain our codebase in a shippable state and can deploy to production environment at any time. We introduce feature toggles to be able to release the codebase even if bigger features are incomplete. We can enable and disable features in the backend and frontend and for DEV, QA and PROD environments. Development (DEV) is where software is created and tested by developers. Quality Assurance (QA) is dedicated to thorough testing to help ensure software quality before deployment. Production (PROD) is the live environment where the finalized and fully-tested software is deployed by customers, in this case Stellantis, for end-users.

We utilize the squash and merge strategy when merging commits to the main branch to condense the commit history. We use the Angular commit naming convention to keep commit naming consistent and produce release notes from the commits to the main branch.

For each repository, we configure one CI/CD pipeline that can deploy into all environments with AWS CodeBuild and AWS CodePipeline. We trigger the pipeline with each new commit to one of the AWS CodeCommit repositories. The pipeline runs tests and linter checks before creating the build for all environments in parallel and deploying.

By adopting trunk-based development as opposed to Gitflow, we avoid the necessity of creating pull requests to promote features to QA or PROD. Due to the fact that features are rebased and merged straight to the main branch, we encounter 50% fewer merge conflicts and deploy to production in less than a third of the time. The frequency of production bugs has decreased by over 30% in the last 9 months as well.

Conclusion

In this blog post, we described how we build an enterprise web application through a collaboration between Stellantis and AWS for Stellantis’ SDVs using serverless services on AWS. Starting with the frontend, we provided a secure and globally accessible infrastructure using Amazon CloudFront, Lambda@Edge and AWS WAF. The VEW backend employs a highly scalable event-driven architecture using Amazon API Gateway, AWS Lambda and Amazon EventBridge and finally trunk-based development helps enable more seamless deployment by Stellantis and helps accelerate their automotive software release cycles.

If you are interested in this architecture and want to learn more, we recommend to check the following resources: