Workflows (continued)

 
Comparisons to Deis Workflow:
Deis workflow is a platform-as-a-service that adds a developer friendly layer to any Kubernetes cluster so that applications can be deployed and managed easily. Kubernetes evolved as an industry effort from the native Linux container support of the operating system.  It can be considered as a step towards a truly container centric development environment. Containers decouple applications from infrastructure which separates dev from ops.
Containers made PaaS possible. Containers help compile the code for isolation. PaaS enables applications and containers to run independently. PaaS containers were not open source. They were just proprietary to PaaS. This changed the model towards development centric container frameworks where applications could now be written with their own  
Let us look at the components of the Deis workflow:
The workflow manager – checks your cluster for the latest stable components.  If the components are missing. It is essentially a Workflow Doctor providing first aid to your Kubernetes cluster that requires servicing.
The monitoring subsystem consists of three components – the Telegraf, InfluxDB, and Grafana. The first is a metrics collection agent that runs using the daemon set API.The second is a database that stores the metrics collected by the first. The third is a graphing application, which natively stores the second as a data source and provides a robust engine for creating dashboards on top of time-series data.
The logging subsystem which consists of two components – first that handles log shipping and second that maintains a ring buffer of application logs
The router component which is based on Nginx and routes inbound https traffic to applications. This includes a cloud-based load balancer automatically.
The registry component which holds the application images generated from the builder component. 
The object storage component where the data that needs to be stored is persisted. This is generally an off-cluster object storage.
Slugrunner is the component responsible for executing build-pack based applications. Slug is sent from the controller which helps the Slugrunner download the application slug and launch the application
The builder component is the workhorse that builds your code after it is pushed from source control.
The database component which holds most of the platform state. It is typically a relational database. The backup files are pushed to object storage. Data is not lost between backup and database restarts.
The controller which serves as the http endpoint for the overall services so that CLI and SDK plugins can be utilized.
Deis Workflow is more than just an application deployment workflow unlike CloudFoundry.  It performs application rollbacks, supports zero-time app migrations at the router level and provides scheduler tag support that determines which nodes the workloads are scheduled on. Moreover, it runs on Kubernetes so other workloads can be run on Kubernetes along with these workflows. Workflow components have a “deis-” namespace that tells them apart from other Kubernetes workloads and provide building, logging, release and rollback, authentication and routing functionalities all exposed via a REST API. This is a layer distinct from the Kubernetes.  While Deis provides workflows, Kubernetes provides orchestration and scheduling.

Comparision to Azure DevOps:
Some tenets for organization from ADO have parallels in Workflow management systems:
·        Projects can be added to support different business units 
·        Within a project, teams can be added 
·        Repositories and branches can be added for a team 
·        Agents, agent pools, and deployment pools to support continuous integration and deployment 
·        Many users can be managed using the Azure Active Directory. 
 
Conclusion:
The separation of workflows from resources and built-to-scale design is a pattern that makes both workflows and resources equally affordable to customers.