Deployment
How an akenza Enterprise deployment is hosted: the deployment models, multi-region setups, and domains.
An akenza Enterprise deployment is a tenant of its own. The platform runs either in an akenza cloud subscription or in a customer cloud subscription, using several infrastructure components to process and manage IoT data at scale.
Cloud platforms
akenza deploys on any of the major cloud providers:
Amazon Web Services (AWS)
Google Cloud Platform (GCP)
Microsoft Azure
Picking the provider you already use keeps the deployment inside the cloud governance, billing, and network your organization has established, which matters most in the customer subscription model below.
Deployment models
Which model applies decides who holds the cloud subscription, who has access to the infrastructure, and where responsibility sits when something needs changing.
Enterprise SaaS
akenza operates the private cloud deployment in its own cloud subscription.
No infrastructure access for customers.
Customer subscription
akenza deploys and operates the private cloud deployment in the cloud subscription of the customer.
akenza has full access to deploy infrastructure components and applications.
Shared responsibility
A hybrid mode: the customer's DevOps team manages the infrastructure, and akenza manages the application deployed on top of it.
Split between both parties.
Enterprise SaaS
The simplest of the three. akenza holds the subscription, runs the deployment, and customers work only with the platform itself. Choose it when a private deployment is wanted without taking on any infrastructure of your own.
Customer subscription
The deployment lives in your own cloud subscription, so the infrastructure and the data on it sit within your organization's cloud governance, while akenza still deploys and operates it.
Shared responsibility
Your DevOps team owns the infrastructure and akenza owns the application running on it. This suits organizations with an established cloud practice that expect to manage infrastructure themselves.
Because the responsibility boundary runs through the middle of the system, this model requires close collaboration and a custom service level agreement with its own service level objectives. Agree both before committing to it, since the standard terms do not describe this split.
Multi-region setup
Latency between devices and the platform is a real constraint, so a deployment should be placed in the region it serves. Where worldwide coverage is needed, akenza is deployed once per geographical region, for example in EMEA, APAC, and the US.
Regional deployments are not synchronized. Each is a separate tenant, managed separately, with its own organizations, users, devices, and tenant-level configuration. Something set up in one region has to be set up again in the others.
Plan for this at the outset. Deciding which region a customer, site, or fleet belongs to is straightforward before onboarding and awkward afterwards, because moving devices between deployments means recreating them.
Domains and certificates
A deployment is reached either under an akenza domain or under your own:
akenza domain
Nothing. The deployment is hosted under *.<customer>.akenza.io.
Custom domain
A wildcard certificate covering all akenza hostnames, and DNS records configured accordingly.
A custom domain is what makes a deployment feel like your own product rather than akenza's, and it pairs with white labeling, which changes the name, colors, and logo inside the application.
Getting a deployment
Deployment models, regions, and domains are agreed as part of an Enterprise arrangement. To discuss which model fits, get in touch through the Service Desk.
Last updated
Was this helpful?