Deployment Architecture
ESP RainMaker is built on a serverless architecture using Amazon Web Services (AWS), ensuring scalability, flexibility, data ownership, and minimal maintenance overhead. The diagram below illustrates the high-level architecture of ESP RainMaker, highlighting its components and the key AWS services used in the cloud backend.
View Cloud Backend under development section for more detailed information.
Deployment Model
ESP RainMaker is entirely based on a Serverless Architecture. It uses services like Lambda and DynamoDB, which are internally provisioned by AWS across multiple Availability Zones in a Region.
Currently, ESP RainMaker can be deployed in only one region per AWS Account, and SAM is the default deployment model.
Deployment upgrades using SAR will still be supported, but all new deployments will be done exclusively with SAM.
SAM Deployment Model
The model uses pre-defined and pre-configured templates to quickly and easily deploy serverless applications in the cloud.
When deploying RainMaker components (which are parts of a larger serverless application), we use SAM package templates. These templates are special files that define how the application will be structured and how different parts (like functions, databases, or APIs) will work together in the cloud.
The SAM template simplifies this process by providing a streamlined way to describe your application. Behind the scenes, SAM takes this template and automatically converts it into CloudFormation (CF) templates, which AWS uses to create and manage the cloud resources.
Required Components
Two mandatory components for private RainMaker need to be deployed. These components come in the form of two SAM templates for the backend:
- ESP-RainMaker-Base
- It includes DynamoDB, S3, Base API gateway, etc.
- ESP-RainMaker-Core
- It includes Lambda, APIs, SNS, etc.
The parent ESP RainMaker stack includes all sub-module stacks such as:
- User Management
- Node Management
- Access Control
- Over-the-Air Upgrade (OTA)
Deploying the parent stack will deploy all required sub-module stacks in sequence.
Optional Components
A parent SAM template is also available for all add-on services, allowing users to choose which add-on stacks to deploy in their account.
Listed below are the optional add-on stacks:
- ESP-Nested-AddOns
- ESP-TimeSeries
- ESP-RainMaker-Skills
One SAM template includes Alexa and GVA Voice Assistant integration.
Please proceed to the next steps to learn more about account setup and repository access.
- SAM (Serverless Application Model) Templates
- Configuration files used to define the serverless application for deployment. They simplify the setup by handling complex CloudFormation syntax. Reference link
- SAR (Serverless Application Repository) (NRND)
- AWS SAR is a managed repository that allows developers to discover, deploy, and share serverless applications. It simplifies application deployment by providing access to pre-built serverless solutions. Reference link
- Resources
- Components or services (such as DynamoDB, S3, Lambda) that you create and manage on AWS.
- Stacks
- A collection of AWS resources managed as a single unit. CloudFormation templates are used to create, update, and delete these stacks.
- Submodule Stacks
- Smaller stacks within the main stack, each handling a specific function or service (e.g., user management, node management).
- Global RainMaker & China RainMaker
- China RainMaker and Global RainMaker are separate instances of the ESP RainMaker platform. The China version is tailored to comply with local regulations and infrastructure, while the Global version serves international users.
- Standard (Non-OAuth) vs. OAuth-Only RainMaker
- ESP RainMaker offers two authentication options: Standard (Non-OAuth) and OAuth-only, allowing users to choose based on their application needs. The Standard RainMaker setup includes built-in identity management with email-based login, password management, MFA, multiple identity providers, user migration, admin tools, ESP Insights, and backup/restore. In contrast, OAuth-only RainMaker relies on OAuth for authentication, enabling SSO and OAuth 2.0 with external providers like Google and Apple but omitting features like email/password login, ESP Insights, and backup/restore. Users can select either approach based on security, identity management, and integration requirements.