JI> A mathematical model alone is not going to make a product a success, JI> unless it can predict the market itself.
Indeed. Factually I am more interested in the increase of application and use of Promise Theory in the entire configuration management industry, than I am in the specific success of the CFEngine product itself. I do, however, believe the two are more closely related than you appear to think. NW> I do not want to see yet another CM syntax and product unless that NW> syntax is designed and offered as an open standard, not ruled or NW> controlled by any for-profit corp, that any CM product can use. The NW> selfish silos of open source CM have hurt us all. NW> Many orgs are not happy with their first choice of CM tool, but the cost NW> of rewriting all their policy to a new one keeps them where they are. TZ> I agree with both Mike and Neil. But Neil's point applies to our entire TZ> industry. TZ> An open standard for CM tools will grow the market by creating an open TZ> community that can share expertise, modules, and tools. The history of TZ> many other industries shows this. I couldn't agree more. This relates to my point above in response to Joaquin. If a language is: 1. well designed, 2. from an open standard, 3. is simple to learn, and 4. has a means of expression for the actual use cases to which it is intended to be applied, ...it has a greater chance of being widely adopted than a closed language which changes based on the whims of the few developers of the sole parser for that language. I would like to see such an open CM language that is based on Promise Theory. I think that could potentially do as much for the long-term relevance of configuration management as Relational Theory has done for databases. I would also like to avoid the departures from the underlying theory which were built in to SQL. SQL is close enough to the workable underlying theory that it has been a remakable success in terms of adoption, but it is not a relational language. There are a great many factual reasons why that is, and a great many historical reasons why it came about. (If you're interested, review the works of C. J. Date. <https://www.safaribooksonline.com/search/?query=C.J.%20Date&field=authors>) In my opinion, the non-relationality of SQL is one of the reasons for the "success" of NoSQL databases. By violating Relational Theory in important ways, SQL makes certain practical use cases very difficult, or impossible, which are very easily handled by pure Relational Theory—thus forcing users into other systems. (I place "success" in quotes because I consider this success to be relatively ephemeral; I believe the popular NoSQL databases will none of them still be in use in 100 years, while Relational Theory will be.) As CFEngine policy language was explicitly based on Promise Theory, it seems a logical starting point for envisioning a CM language which could handle any aspect of Promise Theory with accuracy. (You may call me an idealist if you wish.) The point is not that Promise Theory must be regarded as holy. The point is that if holes are found in the practical application of the theory, where it does not seem to apply, perhaps the theory could even be extended. But first would come a reality check: Does the current implementation even apply Promise Theory? Are we actually testing the applicability of the theory itself, or are we omitting parts of the theory that would handle the practical problems we are running into? ------------- A comment on CFEngine 3 syntax: In considering CFEngine 3's "compound promises" today, I realized something: There are no promise types in the CFEngine 3 policy language. "What about 'files' and 'users' and 'packages,' then? What are all those things, if they're not promise types?" They are PROMISER types. A "single files promise" can actually consist of multiple promises, as noted earlier in this thread. However, what does that really mean? It means that the same promiser (the file) has made multiple promises. In a Promise Theory Language, this should be distinguished better. Taking a look at an example of CFEngine syntax to represent promises for something other than server configuration, such as HTML—what do you see as the "promiser" and what do you see as a "promise"? html: main:: "h1" font_size => "12px", color => "red"; "p" text_align => "justify"; I see two promisers—"h1" and "p"—and three promises. What we call "attributes," I believe, were actually intended each to be distinct promises in the original CFEngine 3 syntax conception. (Note: This example was written by Mark Burgess <http://www.linuxjournal.com/content/promise-theory%E2%80%94what-it?page=0,1>!) This syntax seems to me extremely intuitive. The devil, as they say, is in the [implementation] details. Best, —Mike Weilgart Vertical Sysadmin, Inc. On Nov 29, 2016, at 10:33 PM, [email protected] wrote: 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] <mailto:[email protected]>. To post to this group, send email to [email protected] <mailto:[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 <https://groups.google.com/d/msgid/dev-cfengine/08bd3ab5-4657-49d8-970b-3a8460ec4d73%40googlegroups.com?utm_medium=email&utm_source=footer>. For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>. -- 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/2774E47C-F0D9-4F03-B9A3-F8CC03F0C984%40verticalsysadmin.com. For more options, visit https://groups.google.com/d/optout.
