Preface
Server Farmer is a set of tools allowing time-effective management of large number of Linux servers. It is focused mostly on various security-related aspects, where it provides many ready to use solutions.
The main difference between Server Farmer and the competitive tools is that Server Farmer is designed to manage a completely heterogeneous environment, where servers:
- are owned by many different companies
- have different operating systems
- have different configurations
- have different installed services and applications
- have different system users, groups and permissions
- have different roles and purposes
All existing server management tools try to impose a narration, where having such environment requires running separate "instances" (configuration repositories, management servers etc.) for each customer and application, while Server Farmer takes entirely different approach and allows managing this whole environment using one management server shared across all customers and managed servers.
The competition of Server Farmer - and is it really the competition?
There are a few wide known server management frameworks, mostly Puppet, Chef, Ansible, Salt and CFEngine, that are often seen as competition of Server Farmer. But are they really?
In fact, there are a few key differences between all of them and Server Farmer, that makes them not a competition:
- Server Farmer is built around very specific business/HR model, that is right for most software houses and IT outsourcing companies (that means, companies, that manage several different servers, with completely different applications, configurations, user sets etc.), while the above frameworks are built to manage homogeneous infrastructures (for a single company, with single application or at least same application principles, similar user base etc.).
- Server Farmer is mainly focused on low-level server security aspects, and doesn't try to cover the application level at all - in fact, the application level can be covered by Ansible, which has the same architecture, very similar inventory format, and which is officially recommended as the application level supplement to Server Farmer.
- All mentioned frameworks follow "Infrastructure as Code" convention, which means that they provide internal tools, using which administrators can create the "infrastructure application", which is responsible for transforming the current state of managed servers to the desired state, at both system and application levels. Server Farmer does not. It provides a closed set of extensions, which are configurable enough to achieve certain goals, but overall it doesn't try to aspire to "Infrastructure as Code" philosophy.
- All mentioned frameworks follow "one managed application/customer - one instance" model, while Server Farmer is built from the ground up to manage many customers, applications etc. using only one shared instance, which is the only economically viable model for companies, that have 1-5 managed servers overall.
Because of the above key differences, Puppet, Chef, Ansible, Salt, CFEngine, or most other server management tools, are not the competition of Server Farmer, since they are created to cover completely different business areas. The real competition, from business point of view, is between Server Farmer and manual management of each server - or, at most, between Server Farmer and custom made scripts.
Additionally, Server Farmer can co-exist with these tools. For example, Ansible is successfully being used by the authors of Server Farmer to manage the application level stuff for a few biggest commercial customers (while Server Farmer is responsible for all system level stuff at the same time).
Business concept around Server Farmer
In opposite to all competitive tools, Server Farmer is not designed as yet another tool to manage servers for a single company, team and purpose.
Instead, it is designed to be a vital part for all kinds of software houses and IT outsourcing companies, that manage (or co-manage) large numbers of servers for different companies. Therefore, it is primarily focused on aspects common for all such servers (which is security of various system level components), while not touching the application level almost at all.
HR concept around Server Farmer
Server Farmer is designed to be secure and simple at the same time. To achieve the maximum simplicity, it is based on passwordless ssh (using keys). This model has one major drawback: it means that the central management server (called "farm manager" below), which stores all root ssh keys, and which acts as the remote console to all managed servers, has to be operated by one person only. This person can be called primary administrator, owner, super-administrator, überadministrator etc.
Of course, technically many people can have access to farm manager - however no real accountability is possible in this situation (there is no way to distinguish, which administrator is responsible for given action on given managed server).
Therefore, Server Farmer is intentionally designed with one important functional limitation in mind: there can be only one primary administrator (who has access to all keys), and unlimited number of administrators, devops, or other people with privileged access to particular managed servers (possibly everywhere except only farm manager).
If the above is achievable in your business, Server Farmer will probably be much better choice than "big" tools built for corporations, with fancy authentication and action accounting for many equivalent administrators.
What Server Farmer really is: the core and the extensions ecosystem
Just like Linux, Server Farmer can be considered as the core part only, or as a whole ecosystem.
Server Farmer core is the main repository. It contains only the very small micro-framework, that is responsible for initial configuration and installing extensions.
Server Farmer extensions (forming the whole Server Farmer ecosystem) are separate repositories, providing many different functionalities:
- backup (including encryption, automatic data sources detection, distributed storage etc.)
- security hardening tools (at various levels: kernel, sshd, firewall etc.)
- message logging tools (central logging, log monitoring and rotation)
- server and application monitoring functionalities
- remote server management functionalities
- "bricks" to build certain typical services (Samba server, IMAP server, Continuous Integration etc.)
- pre-configured, security-hardened base software eg. Java, PHP
- and many others...
What is common for most of these extensions, is that they can be installed manually (or using other management tool eg. Ansible) and used separately, without installing Server Farmer core. So, using eg. "Server Farmer backup" doesn't imply that you have to install and use the whole Server Farmer.
Is Server Farmer the right tool for my company?
First of all, Server Farmer is built around very specific business and HR concept. You can read more about this above. Depending on how close if your business model to the described one, Server Farmer may be, or may be not, a tool for you.
If you're yet about to start with server management business - note that there are 2 different architectures, around which all server management solutions are built:
- push (eg. Server Farmer, Ansible) - central management server has network access to managed servers
- pull (eg. Puppet, Chef) - managed servers have network access to central management server, to download updates and process them locally
Push model is better for servers with public IP address (eg. cloud servers, which statistically generate more revenue than servers inside someone's office), and servers inside the same local network, as the central management server. This model is also much easier to start with and learn, and often cheaper to implement, especially for smaller companies.
Pull model is better for servers without public IP address, located in many different networks (eg. in many different offices), because you don't have to configure port redirection for each such server (however you may still need to do it for the setup phase). This model is also better for fast scaling inside big companies with really large server farms in multiple datacenters, but at the same time, requires much more effort to write a good management application.
So, if you have trouble choosing the right tool, consider the right architecture first. This will narrow your choice to 2, maybe 3 tools, from which you should choose one, that suits you better in terms of programming language, documentation, overall simplicity etc.