Expertflow’s approach for an on-demand cloud solution is using a concept known as “Container as a Service for Independent Software Vendors”.
All new Expertflow software is now being deployed in Docker Containers on Linux or Windows Machines. The advantage as compared to Virtual Machines on VMWare is that individual instances don’t each require an operating system. The footprint is much lower, and new instances can be started in seconds rather than in minutes. So whenever an instance fails, a new instance will be spawned within seconds, which is noticeable in most use-cases.
Basic installation is done with Docker Compose files, as illustrated here for Hybrid Chat.
If multiple servers are required, this is managed by Docker Swarms or Kubernetes. This also takes care of auto-scaling, failover, and healing. Our normal deployment model is simple Docker Swarms:
For larger deployments or clients that already have a private cloud with a proper CI (Continous Integration)/ CD (Continuous Deployment/ DevOps environment, we support Kubernetes, currently with either the Redhat Openshift, Google Kubernetes, or Rancher flavors.
Looking forward, we plan to use CaaSi to provide cloud solutions. CaaSi stands for container as a service for ISVs (Independent Software Vendors). The cloud can be a public cloud (Amazon AWS, Google GCP, Microsoft Azure, Digitalocean…), or your private cloud. We will then continuously update the containers on your cloud using a CI/CD solution such as Jenkins or Gitlab. These docker containers are accessing data that resides on a database that can reside on your premises:
This blog on Venturebeat describes advantages to this approach:
So this is how Expertflow provides SaaS/ Cloud services. Timing as to when is largely driven by concrete customer demand. We will initially make available our Software on a customer-per-customer base, but then gradually start to directly extend our CI/ CD pipeline to customers on-prem or pure cloud instances for clients that wish this approach.
The largest advantage as compared to the existing traditional heavy-handed approach to upgrades (which are usually a project in their own right) is that upgrades will happen instantly in the background without downtime or human intervention. Rollbacks are tested and pre-implemented in the CI/ CD pipeline.
