01/07/2021
Contrasting a declarative policy engine to an imperative job scheduling, the sticky world of imperative operational models
Traditional architecture has long been ruled by the imperative operational model. We take some piece of infrastructure and then tell that same piece of infrastructure exactly what it must do to meet our desired end state. This has resulted creating backup jobs, each job requires a non-trivial amount of hand holding to function, such as which specific workloads or Virtual machines must be protected, where to send data and how to store that data (compression, deduplication, etc), when to purge backup files from the storage, how to schedule the backups and in which order: Full, Reverse Full, Periodic Full, Synthetic Full, Incremental followed by next Full, NDMP, how to connect to the storage target, be it protocols or access methods, backup catalogs, catalog details for in-guest file indexing, along with application specific requirements, backup proxy nodes, protected/unprotected targets, pool selection for data ingest, the use of ancillary methods for quiescence and the associated credentials, and so on… not too much right ?
Making any sufficiently complex system look and feel simple is a tall order, meet Cerebro
https://www.linkedin.com/pulse/meet-cerebro-brains-behind-rubriks-time-machine-aggelos-dimitropoulos/?trackingId=MmcCgwgZTZSrUVGZfSNGcw%3D%3D