I use a hybrid model of the solution as a blueprint to create and deploy virtual machines to the open stack.
The solution includes the option to run background scripts and processes from a connected API.
The YAML format is also easy to use with some practice.
Documentation is sufficient to learn from examples and modify to any company's needs.
The solution is a bit of a headache because mistakes happen in the blueprint every time we deploy and they require modifications. Containerizing deployments would make the process simpler.
There should be a way to create plugins and connect to tools like HashiCorp Vault to read secrets instead of having secrets located inside the blueprint or YAML file. Currently, we have to run a script in another cloud platform to read and copy secrets. The solution might gain users if it connected with other cloud platforms.
Our developers have to create templates for Amazon Azure because they do not exist on the solution's website.
I have been using the solution for four years.
The solution is difficult to scale because deployments are not containerized.
The initial setup was not complicated but was not user-friendly because it takes time to learn. If mistakes are made or something is missing, it might take multiple tries to rectify problems because the solution does not identify errors.
We implement and manage the solution in-house.
Our client is a legacy bank with more than 500 users and many servers running the solution. We deployed the first API on Azure more than a year ago and hope to deploy others over time.
We are moving to Azure because it includes many tools that make it more scalable and efficient such as being able to change templates and VMs, working with Terraform and Kubernetes, and using Docker containers. We don't have to type a million things to deploy a VM and Azure includes automatic connection to a vault containing the secrets. We use an open stack and it is unknown if this will be transferred to Azure.
The solution is a legacy product and it takes time to understand it because there are a lot of dependencies. Not every cloud company uses the product so it is not professionally useful on a CV or in the cloud industry.
I spent over a year understanding the inner workings because it is like coding. There are dependencies like plugins that have to be deployed properly or ongoing issues will occur. If there are processes I don't know or an update that is needed, it is up to me to find the appropriate documentation and modify my blueprint. For example, I look at what other developers write for updating plugins and then I copy and paste it to my blueprint.
Even with the learning curve, the solution is an interesting concept and reminds me of Vagrant Terraform with its own difficulties and easiness. Virtual machines can be deployed with the YAML files so working knowledge of YAML is helpful. It allows provisioning of AWS clusters which is important for Kubernetes.
I rate the solution a seven out of ten.