|
|
|
### Cloud agnostic first
|
|
|
|
The **main** goal of this project is to be as cloud agnostic as possible.
|
|
|
|
|
|
|
|
With this project, system/cloud migration should be as easy and seemless as possible. As long as you have accounts and backups, it should be extremely straightforward migrating from one provider to another. In fact this project has been used to go from Digital Ocean -> AWS -> Digital Ocean.
|
|
|
|
|
|
|
|
Examples:
|
|
|
|
- Your application/service is very network intensive (streaming, content provider, etc) you find Digital Ocean suits your needs.
|
|
|
|
- Digital Ocean lacks IAM type policies for your growing business and wish to move to AWS.
|
|
|
|
- After careful cost analysis, you find you can save 10-30% from moving from Provider A to Provider B.
|
|
|
|
|
|
|
|
|
|
|
|
Because of this intentional design, several services provided by each of these providers are not implemented due to them being provided _exclusively_ by this provider. _Exclusive_ services may never be implemented into the project _unless_ 2 or more of the providers provide this service. Once they become widely available, then it is a goal to provide that functionality at some point in the future.
|
|
|
|
|
|
|
|
Examples:
|
|
|
|
- AWS was the _only_ S3 object storage provider, now there's multiple choices.
|
|
|
|
- Kubernetes was not a managed service on _any_ provider, now _many_ cloud providers provide it.
|
|
|
|
- Docker Hub was _the_ container registry, now _many_ providers provide their own Docker Container Registry.
|
|
|
|
|
|
|
|
Some of these services may be implemented in a cloud agnostic way initially and re-writing them to integrate directly with the cloud providers version for each provider costs time. This may be a dealbreaker for businesses that have hard requirements that must be met.
|
|
|
|
|
|
|
|
Below you will find a non-comprehensive list of those services to allow the user to evaluate if it's worth the time and effort to proceed.
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
#### AWS IAM
|
|
|
|
Organizations utilize AWS IAM for a variaty of reasons. In order for rapid developmental changes to propogate across all providers and remaining cloud agnostic, it does not use AWS IAM profiles to control resources. Instead of it uses single User account and a Bot account with the necessary policies to manage the infrastructure.
|
|
|
|
|
|
|
|
#### Docker Images
|
|
|
|
This project is currently built around utilizing GitLab for storing and using Docker Images. It is out of the scope of this project to use either of the providers services at this time. It's not that it isn't possible (in fact it briefly used Amazon ECR and has some options for it), but it's current iteration does not optimize utilizing those services.
|
|
|
|
|
|
|
|
[Digital Ocean Registry](https://cloud.digitalocean.com/registry)
|
|
|
|
[Amazon ECR](https://aws.amazon.com/ecr/)
|
|
|
|
|
|
|
|
#### Kubernetes
|
|
|
|
A major reasion for using Kubernetes is its RBAC for managing it. Curently the Kubernetes provisioning and GitLab integration is automated but done through scripts and does **not** utilize the managed services [DO: Managed Kubernetes](https://cloud.digitalocean.com/kubernetes/clusters) or [AWS EKS](https://aws.amazon.com/eks/) of the cloud providers. This is by design _currently_. However, the goal **is** to provide **at a minimum** the functionality to plugin to these services for quick auto-scaling through Kubernetes. |
|
|
\ No newline at end of file |
