2 ms·
Initially it was designed to manage IT infrastructure and to automate server management even during "split brains", for each partition individually. It was inte
by mnabozny 7y ago
Initially it was designed to manage IT infrastructure and to automate server management even during "split brains", for each partition individually. It was intended to be partially a replacement for Ansible and partially as something more functional, with logics.
Now, when I'm working a bit more with this tools, I think that it could be applied to anything related to IoT, autonomous cars/robots or wide area installations, like BTS network and its configuration or management of home/industrial automation. It should fit good in places, where connectivity is far away from perfect and we cannot guarantee connection with central management service (let's say database or LDAP), and regardless the network damages, all remaining services should be available and functional as much as possible.
As far as your question is concerned, initially I planned to use that to manage virtual machines, bare metal servers and my local machines to provision them regardless the cloud operator, connection type and cloud automation services. For some reasons Ansible was too complicated to deliver the same functionality as I needed. Moreover, with Ansible there always be some "central" service that manages whole infrastructure. For client, who has some infrastructure in cloud and some in own, local servers, there would always be a weak point in managing such infrastructure. From the other hand there was a Kubernetes, but it was too complicated, especially when spanning over local cluster and public cloud
- eterps 7y agoThank you