A CFEngine agent running on the client executes in less than one second, and it does so independently of other hosts in the CFEngine deployment. Being the only fully autonomous solution in the industry, it can operate and be fully functional without the need to always be connected to a central master. CFEngine is akin to a Formula One leader for the automation industry.
At one bank that was using a traditional push-based automation solution, it took 5-6 hours to update packages across several thousand servers. The performance impact on their system during deployment to the desktops was so severe, they had to wait for nights or weekends to make changes. With CFEngine you can update 100,000 hosts within just a few minutes.
When CFEngine 2 was introduced 10 years ago, the default run-interval of its agents was 30 minutes. In today’s fast changing world, this is no longer fast enough, and the new default run-interval has been shortened to 5 minutes. Since CFEngine runs so fast, and barely impacts available resources (memory and CPU) during each execution, one can even have the agent running every minute if they want. Most solutions in the industry today are either push-based where changes are invoked by humans or operate with run-intervals of 30 minutes or more.
A practical use of this speed would be around patching systems. Let’s say a new security vulnerability has been exposed and IT operations needs to patch 20,000 servers. With CFEngine, the change or patch can be applied almost instantaneously across all 20,000 servers. This is because of the autonomous nature of the agents running on each individual server as well as the speed at which they execute CFEngine policy.
If you want a self-healing system that is continuously in compliance, speed is important as it allows you to check your system more frequently. Fast execution ensures that you don’t have agent processes occupying your process table for long, and in turn using up costly resources (such as CPU or Memory).
Proof-points of Speed:
CFEngine is written in C and is very lightweight. It has been tested and hardened for many years in numerous small and large-scale production environments. Any third party libraries included in the code have been carefully reviewed from a security perspective. CFEngine normally only includes libraries that are mature and well-tested. In general, since it is a goal to keep CFEngine lean, new libraries are seldom added to the code.
All communication between the hub and clients can be encrypted, leveraging TLS. CFEngine uses its own protocol to communicate. CFEngine only requires one port to be open (5308 – and this is configurable). Most permissions, whether it relates to file copying or bootstrapping of new agents, must be explicitly allowed in the system configuration files. It is impossible to push any commands or instruction to CFEngine locally without going through a pre-defined and trackable change-process. Not only does this prevent potentially unrecoverable conditions resulting from accidental typos, but it also adds a layer of security to all your intended changes.
The bootstrapping of new agents to the hub uses a simple key exchange algorithm (like SSH key authentication). There is no need for external certificate servers with CFEngine.
CFEngine holds a very strong security track record according to NIST. The technology holds an extremely strong track record over the last 20 years!
Another testimonial to the security is our customer base. Verticals such as finance, government and other heavily regulated industries all tend to favor CFEngine because of its security track record.
If you are looking for an automation solution with a strong security track-record, a solution which is built and designed with security in mind, CFEngine is probably the best tool of choice.
Proof-points of Security:
CFEngine powers automation at one of the largest financial institutions in the US, and has done for many years.
The lightweight nature of CFEngine and the care exercised in selecting and implementing third party libraries has contributed to a lean, predictable and stable product. Regardless of the version (CFEngine 2 or 3), stability has been a cornerstone of the product. Even today there are countless installation of either version that form the backbone of IT automation for mission-critical production environments. The light weight also implies that there is no negative performance impact on the infrastructure, nor the applications running atop them.
In case of a user-error (say for example a typographic error in writing policy), or deployment of new policy code that has errors in it, CFEngine will detect the errors during validation and avoid the deployment of the policy. If, however, such a policy reaches the local host, CFEngine will still detect the syntax-error and fail back to run a fail-safe policy instead of executing the wrongly deployed policy.
CFEngine is built on Promise Theory. It regards each directive (or promise as it is called) as an autonomous unit. By decoupling the software this way, and ensuring autonomous execution, systems automated using CFEngine become less vulnerable to a catastrophic and domino-effect failure. In short, a single error does not cripple the system and CFEngine can intelligently work around issues – as well as rectify them where possible.
The robustness of CFEngine – from design & architecture to code implementation – has resulted in a very stable product that users and customers quickly entrust their production workloads and infrastructure with. In turn this trust yields confidence in the software, allows IT to make more frequent changes in a stable fashion, and thus lets the business remain competitive.
Proof-points of Stability:
The architecture of CFEngine is a star network and consists of hosts and hubs. Hosts are the end points where policy instructions are being executed. A hub serves as a policy distribution point and data collector for the hosts. One hub typically can serve 5,000 hosts that check in at a 5 minutes interval.
CFEngine is fully decentralized. All logic and decision making occurs on the hosts. Agents run locally and will check for and pull down policy updates from regional or global policy distribution points (hubs). After download, the agents evaluate the policy locally to decide which part of the policy to apply, given their current state.
One advantage of a fully decentralized architecture is that you don’t need to have a complex setup for the hubs. Other solutions typically would need to have load balancers and (at large scale) front-end and back-end servers to assist with host calculations; whereas CFEngine simply requires the hubs to serve policies and pull hosts for data of actual states – no calculation is needed. Assuming a medium specification hub and agents running both on the hub and the nodes at a 5 minutes interval, one hub can serve 5,000 nodes. A more powerful server with improved IOPS performance can serve several thousand more hosts.
Scaling out policy distribution hubs is easy with CFEngine. All that is needed is to add another server horizontally and add its IP address to the pool of allowed hubs an agent can connect to. CFEngine agents can use built-in functionality to ensure even load distribution on the hubs. We call this software based-load balancing. The advantage of scaling the hubs horizontally is that it’s cheap and easy to scale. The cost of scaling is not only the costs of a server, but also the cost of requiring a more complex setup. With complexity comes fragility and increased management costs.
Another big advantage of the lean architecture of CFEngine is resiliency. If you have two hubs, and one goes down, CFEngine agents will automatically connect to the second hub. You can add as many hubs as you like to the list of allowed hubs for the agent to trust.
CFEngine consists of various for-purpose processes with distinct responsibilities. A failure in one of the processes will not take down the whole system. CFEngine is designed to work autonomously with as few dependencies as possible.
Proof-points of Scalability: