I hope I am not too late to add my two pence. I am inspired by your enthusiasm, passion, and insight, and hope to contribute thoughtful discourse on this.
In creating a successful software product, capability VS viability VS usability/desirability should be considered [1]. With out a balance, the greatest technology in the world can fail. A mathematical model alone is not going to make a product a success, unless it can predict the market itself. Thus the capability (implementation of promise theory) must be measured against viability (use cases and meeting business needs) and both of these are measured against desirability/usability (do users derive pleasure or frustration in using a product). In conversations at convention, such as RedHat Summit 2016, CFEngine is treated like a dirty word. Honestly, I heard boos and hisses, and not one person commented positively. I felt that was unfair how people reacted, and I am not sure exactly their experience, but I can imagine is this has to do with desirability/usability factor, where CFEngine is often associated with complexity to use and get up to speed (lead time) vs the competition of other solutions; Puppet DSL or HashCorp or YAML (Salt, Ansible, Hiera) are far easier to master. CFEngine DSL is not all that intuitive, especially to a new comer. So the question is, do people derive pleasure or frustration with CFEngine? Usability testing can elicit this, by having set of use cases, and measuring how quickly a user can accomplish the task with tool X, tool Y, or tool C. From there, you can adjust the product to close the gap, and design an experience where users will want to use the product. The actual use cases will represent the business/customer/market requirements. A large part of the market are moving away from convergence style configuration (snowflake servers[2]) to congruence style configuration[3]. This means that immutable production (phoenix servers[4]) with containers is a big game changer, and with a push to microservice architecture [5] or other cluster solutions, containers make sense. The cost savings (ROI, CBA) are enormous for immutable production patterns, and thus this is a game changer, as much as digital film vs. chemical film. As a metaphor, CF Engine is still addressing chemical film (runtime state convergence) as the market shifts to digital film (deploy time config, immutable stateless containers). On top of this shift to immutable production with containers, there is rising popularity to apply convergence to managing not just systems themselves (or networking equipment) but also applying it to resources exposed through RESTful APIs. With this, you can not only configure CI tasks and builds with Jenkins or TeamCity, and integration with code repos (GitHub, GitLab) and chat ops (Slack, Jabber), you can configure the entire infrastructure like AWS, GCE, Azure, and others. This style of IaC (Infrastructure as Code), especially when combined with ImP (Immutable Production) has tremendous value add, both in savings and capability (flexibility, short lead time, cloning data centers), and increases innovation[6]. But alas for both ImP or IaC, CFEngine does not have an answer. This is viability. As an analogy, I feel like CF Engine is the dream car, but assembly is required, but some parts, like transmission you may have to build it yourself. Once assembled, there's two stick shifts. This is instead of fully assembled with automatic shifting. Other solutions offer the fully assembled car with not only automatic shifting, but all kinds of amenities on top of it, which allows shorter lead time to craft solutions that for engineering best practices and patterns using microservices and 12-factor applications [7]. For examples, Ansible is intuitive for deploy, orchestration, Docker, and Cloud Provisioning (GCE, AWS, etc.). Terraform focuses only on RESTful resources, and has full robust DSL for AWS, Azure, GCE, Jenkins, GitHub and more. The crossroads of tools from HashiCorp, Ansible, and others is truly amazing. On container orchestration, schedulers, and service discovery, there's a whole new set of patterns, and solutions, but one that stands out is Habitat, which does this using promise theory. Docker has InfraKit that on the surface might do similar things, and there are numerous custom solutions out there using a mix of Consul (async agent) and Nginx (routing, health check). CF Engine could do all of this, but it would be a lot of work to expose such configurable resources, get state from them, and achieve idempotence. It would take 2 years R&D (~ $500K+) work to build the same tooling using CF Engine in order to catch up to what the current market is at with other tools out there. Even if that could be achieve, so that product is more viable, there's still a question on desirability/usability. As for capability, I hope I implicitly addresses that, there's not doubt that CF Engine has that, but again, is that enough. Thank you for reading, Joaquin Menchaca Notes/Imagination: [1] *Capability, Viability, Desirability* is *Larry Keeley’s three qualities for high tech products* presented in Alan Cooper’s classic book: *The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity* (2004) [2] *Snowflake server* mentioned Gene Kim’s *The Visible Ops Handbook: Implementing ITIL in 4 Practical and Auditable Steps* [3] *Divergence, Convergence, Congruence* is from *Why Order Matters: Turing Equivalence in Systems Administration* is from article in USENIX publication by Stephen Gordon Traugott (2002) [4] *Phoenix Server* by Martin Fowler - http://martinfowler.com/bliki/PhoenixServer.html [5] *Microservices* by Martin Fowler - http://www.martinfowler.com/articles/microservices.html [6] Imagine, using CFEngine to master entire pipeline (without calling the shell): build, functional/systems test, deploy pre-prod, integration/load testing, promote to production, with feedback in slack, email, github badges, metrics, deploying entire infrastructure (routers, switches, vlans, firewalls, disks, systems, DNS, and applications) testing it, then destroying it. [7] *12-Factor Application* https://12factor.net/ -- You received this message because you are subscribed to the Google Groups "dev-cfengine" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/dev-cfengine/08bd3ab5-4657-49d8-970b-3a8460ec4d73%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
