How it works
App Environments
To deploy your Application on a cloud account, LocalOps takes an environment-based approach.
LocalOps will provision a dedicated Application environment with exclusive cloud infrastructure in the target cloud account and deploy your app inside.
Each Application enivronment comprises of
- VPC
- Private subnets
- Public subnets
- Kubernetes cluster (E.g., EKS in AWS)
- Compute servers and volumes (E.g., EC2 in AWS)
- Plus, few other companion kubernetes deployments to support
- Cloud dependencies (E.g., S3 in AWS)
- Monitoring
- Backups
- Custom domain
- 👉 Your App
- Unique Domain for your app
- Auto-renewing SSL certificate for the unique domain
Your app runs on a unique kubernetes cluster with a unique domain, leveraging all the network, compute, disk, domain LocalOps created for it.
We collectively refer the above set as one “App Environment”.
LocalOps provisions App environment via our standard in-house provisioning templates and scripts such that you can create any number of app environments on any cloud account (AWS, Google Cloud or Azure) and any region.
Packaging
Your application has to become portable to run in any kubernetes cluster. This way, it can be deployed to any app enivornment we provisoin.
To become portable, your application has to be dockerised and packaged as a Kubernetes Helm Chart. The helm chart should define different components of your application as Kubernetes deployments, jobs, services etc.,
Cloud Credentials
LocalOps needs credentials of the cloud account, to programmatically create resources required to get the app environment running. You will have to gather these credentials and add them inside LocalOps as Connections.
Exclusive Infrastructure
Each app environment get its own kubernetes cluster, compute servers and volumes. This is ideal for providing maximum Network, Data & Compute isolation between your deployments & customers.
All cloud infrastructure to run an app environment is provisioned in the cloud account chosen while creating the app environment inside LocalOps. The underlying cloud account will be billed by the cloud provider (say AWS) for the resources LocalOps spins up. Cloud account's owner has to pay these charges. If the cloud account belongs to your customer in the case of Private SaaS deliveries, they would pay for these resources.
Deployments
Deployments can be triggered on an App environment at any time with new version of your application's Helm chart.
Customise app environments
Every application is different. Some are CPU heavy, some are memory intensive or GPU intensive (Machine learning use cases). So each environment can run any kind of server supported by the underlying cloud provider (E.g., AWS) and be customised via Environment templates. Learn more
Cloud Dependencies
Within your applicaiton, you can declare any cloud specific managed resource as dependency. For example, you may want to provision AWS S3 buckets to store files or pictures from your app. Learn more
Monitoring
To debug, LocalOps provisions industry standard open source observability tools such as Loki, Prometheus and Grafana inside each app environment. LocalOps provisions, configures these tools and connects them with each other, so that your team can view Logs and Metrics in a single grafana dashboard.
Custom domain
Every app environment is given a unique localops url like your-app.localops.run. You can set a custom domain for each app environment based on your needs. LocalOps provisions a managed SSL certificate to match the domain you set, inside the cloud account where the app environment is running.
Backups
Backups are pre-configured for each app environment. Scheduled backups can be enabled or one-off backups can be taken at any point. Say before a major deployment.
Security Best Practices:
Within each app environment, LocalOps also turns ON security best practices suggested by the respective cloud provider. In AWS for example, security groups, disk encryption etc., are enabled by default.