SRE vs DevOps: Key Differences and Common Grounds

SOLID is an acronym for five object-oriented programming principles for creating understandable, scalable, and maintainable code.  S: Single Responsibility Principle.  O:Open/Closed Principle.  L: Liskov Substitution Principle.  I: Interface Segregation Principle. D: Dependency Inversion Principle. In this article, we will understand what SOLID is and what each of its five principles states. All shown code examples were executed by Python interpreter version 3.10.12 on a Hostman cloud server running Ubuntu 22.04 operating system. Single Responsibility Principle (SRP) SRP (Single Responsibility Principle) is the single responsibility principle, which states that each individual class should specialize in solving only one narrow task. In other words, a class is responsible for only one application component, implementing its logic. Essentially, this is a form of "division of labor" at the program code level. In house construction, a foreman manages the team, a lumberjack cuts trees, a loader carries logs, a painter paints walls, a plumber lays pipes, a designer creates the interior, etc. Everyone is busy with their own work and works only within their competencies. In SRP, everything is exactly the same. For example, RequestHandler processes HTTP requests, FileStorage manages local files, Logger records information, and AuthManager checks access rights. As they say, "flies separately, cutlets separately." If a class has several responsibilities, they need to be separated. Naturally, SRP directly affects code cohesion and coupling. Both properties are similar in sound but differ in meaning: Cohesion: A positive characteristic meaning logical integrity of classes relative to each other. The higher the cohesion, the narrower the class functionality. Coupling: A negative characteristic meaning logical dependency of classes on each other. The higher the coupling, the more strongly the functionality of one class is intertwined with the functionality of another class. SRP strives to increase cohesion but decrease coupling of classes. Each class solves its narrow task, remaining as independent as possible from the external environment (other classes). However, all classes can (and should) still interact with each other through interfaces. Example of SRP Violation An object of a class capable of performing many diverse functions is sometimes called a god object, i.e., an instance of a class that takes on too many responsibilities, performing many logically unrelated functions, for example, business logic management, data storage, database work, sending notifications, etc. Example code in Python where SRP is violated: # implementation of god object class class DataProcessorGod: # data loading method def load(self, file_path): with open(file_path, 'r') as file: return file.readlines() # data processing method def transform(self, data): return [line.strip().upper() for line in data] # data saving method def save(self, file_path, data): with open(file_path, 'w') as file: file.writelines("\n".join(data)) # creating a god object justGod = DataProcessorGod() # data processing data = justGod.load("input.txt") processed_data = justGod.transform(data) justGod.save("output.txt", processed_data) The functionality of the program from this example can be divided into two types: File operations Data transformation Accordingly, to create a more optimal level of abstractions that allows easy scaling of the program in the future, it is necessary to allocate each functionality its own separate class. Example of SRP Application The shown program is best represented as two specialized classes that don't know about each other: DataManager: For file operations.  DataTransformer: For data transformation. Example code in Python where SRP is used: class DataManager: def load(self, file_path): with open(file_path, 'r') as file: return file.readlines() def save(self, file_path, data): with open(file_path, 'w') as file: file.writelines("\n".join(data)) class DataTransformer: def transform(self, data): return [line.strip().upper() for line in data.text] # creating specialized objects manager = DataManager() transformer = DataTransformer() # data processing data = manager.load("input.txt") processed_data = transformer.transform(data) manager.save("output.txt", processed_data) In this case, DataManager and DataTransformer interact with each other using strings that are passed as arguments to their methods. In a more complex implementation, there could exist an additional Data class used for transferring data between different program components: class Data: def __init__(self): self.text = "" class DataManager: def load(self, file_path, data): with open(file_path, 'r') as file: data.text = file.readlines() def save(self, file_path, data): with open(file_path, 'w') as file: file.writelines("\n".join(data.text)) class DataTransformer: def transform(self, data): data.text = [line.strip().upper() for line in data.text] # creating specialized objects manager = DataManager() transformer = DataTransformer() # data processing data = Data() manager.load("input.txt", data) transformer.transform(data) manager.save("output.txt", data) In this case, low-level data operations are wrapped in user classes. Such an implementation is easy to scale. For example, you can add many methods for working with files (DataManager) and data (DataTransformer), as well as complicate the internal representation of stored information (Data). SRP Advantages Undoubtedly, SRP simplifies application maintenance, makes code readable, and reduces dependency between program parts: Increased scalability: Adding new functions to the program doesn't confuse its logic. A class solving only one task is easier to change without risk of breaking other parts of the system. Reusability: Logically coherent components implementing program logic can be reused to create new behavior. Testing simplification: Classes with one responsibility are easier to cover with unit tests, as they don't contain unnecessary logic inside. Improved readability: Logically related functions wrapped in one class look more understandable. They are easier to understand, make changes to, and find errors in. Collaborative development: Logically separated code can be written by several programmers at once. In this case, each works on a separate component. In other words, a class should be responsible for only one task. If several responsibilities are concentrated in a class, it's more difficult to maintain without side effects for the entire program. Open/Closed Principle (OCP) OCP (Open/Closed Principle) is the open/closed principle, which states that code should be open for extension but closed for modification. In other words, program behavior modification is carried out only by adding new components. New functionality is layered on top of the old. In practice, OCP is implemented through inheritance, interfaces, abstractions, and polymorphism. Instead of changing existing code, new classes and functions are added. For example, instead of implementing a single class that processes all HTTP requests (RequestHandler), you can create one connection manager class (HTTPManager) and several classes for processing different HTTP request methods: RequestGet, RequestPost, RequestDelete. At the same time, request processing classes inherit from the base handler class, Request. Accordingly, implementing new request processing methods will require not modifying already existing classes, but adding new ones. For example, RequestHead, RequestPut, RequestConnect, RequestOptions, RequestTrace, RequestPatch. Example of OCP Violation Without OCP, any change in program operation logic (its behavior) will require modification of its components. Example code in Python where OCP is violated: # single request processing class class RequestHandler: def handle_request(self, method): if method == "GET": return "Processing GET request" elif method == "POST": return "Processing POST request" elif method == "DELETE": return "Processing DELETE request" elif method == "PUT": return "Processing PUT request" else: return "Method not supported" # request processing handler = RequestHandler() print(handler.handle_request("GET")) # Processing GET request print(handler.handle_request("POST")) # Processing POST request print(handler.handle_request("PATCH")) # Method not supported Such implementation violates OCP. When adding new methods, you'll have to modify the RequestHandler class, adding new elif processing conditions. The more complex a program with such architecture becomes, the harder it will be to maintain and scale. Example of OCP Application The request handler from the example above can be divided into several classes in such a way that subsequent program behavior changes don't require modification of already created classes. Abstract example code in Python where OCP is used: from abc import ABC, abstractmethod # base request handler class class Request(ABC): @abstractmethod def handle(self): pass # classes for processing different HTTP methods class RequestGet(Request): def handle(self): return "Processing GET request" class RequestPost(Request): def handle(self): return "Processing POST request" class RequestDelete(Request): def handle(self): return "Processing DELETE request" class RequestHead(Request): def handle(self): return "Processing HEAD request" class RequestPut(Request): def handle(self): return "Processing PUT request" class RequestConnect(Request): def handle(self): return "Processing CONNECT request" class RequestOptions(Request): def handle(self): return "Processing OPTIONS request" class RequestTrace(Request): def handle(self): return "Processing TRACE request" class RequestPatch(Request): def handle(self): return "Processing PATCH request" # connection manager class class HTTPManager: def __init__(self): self.handlers = {} def register_handler(self, method: str, handler: Request): self.handlers[method.upper()] = handler def handle_request(self, method: str): handler = self.handlers.get(method.upper()) if handler: return handler.handle() return "Method not supported" # registering handlers in the manager http_manager = HTTPManager() http_manager.register_handler("GET", RequestGet()) http_manager.register_handler("POST", RequestPost()) http_manager.register_handler("DELETE", RequestDelete()) http_manager.register_handler("PUT", RequestPut()) # request processing print(http_manager.handle_request("GET")) print(http_manager.handle_request("POST")) print(http_manager.handle_request("PUT")) print(http_manager.handle_request("TRACE")) In this case, the base Request class is implemented using ABC and @abstractmethod: ABC (Abstract Base Class): This is a base class in Python from which you cannot create an instance directly. It is needed exclusively for defining subclasses. @abstractmethod: A decorator designating a method as abstract. That is, each subclass must implement this method, otherwise creating its instance will be impossible. Despite the fact that the program code became longer and more complex, its maintenance was significantly simplified. The handler implementation now looks more structured and understandable. OCP Advantages Following OCP endows the application development process with some advantages: Clear extensibility: Program logic can be easily supplemented with new functionality. At the same time, already implemented components remain unchanged. Error reduction: Adding new components is safer than changing already existing ones. The risk of breaking an already working program is small, and errors after additions probably come from new components. Actually, OCP can be compared with SRP in terms of ability to isolate the implementation of individual classes from each other. The difference is only that SRP works horizontally, and OCP vertically. For example, in the case of SRP, the Request class is logically separated from the Handler class horizontally. This is SRP. At the same time, the RequestGet and RequestPost classes, which specify the request method, are logically separated from the Request class vertically, although they are its inheritors. This is OCP. All three classes (Request, RequestGet, RequestPost) are fully subjective and autonomous; they can be used separately. Just like Handler. Although, of course, this is a matter of theoretical interpretations. Thus, thanks to OCP, you can create new program components based on old ones, leaving both completely independent entities. Liskov Substitution Principle (LSP) LSP (Liskov Substitution Principle) is the Liskov substitution principle, which states that objects in a program should be replaceable by their inheritors without changing program correctness. In other words, inheritor classes should completely preserve the behavior of their parents. Barbara Liskov is an American computer scientist specializing in data abstractions. For example, there is a Vehicle class. Car and Helicopter classes inherit from it. Tesla inherits from Car, and Apache from Helicopter. Thus, each subsequent class (inheritor) adds new properties to the previous one (parent). Vehicles can start and turn off engines. Cars are capable of driving. Helicopters, flying. At the same time, the Tesla car model is capable of using autopilot, and Apache, radio broadcasting. This creates a kind of hierarchy of abilities: Vehicles start and turn off engines. Cars start and turn off engines, and, as a consequence, drive. Tesla starts and turns off the engine, drives, and uses autopilot. Helicopters start and turn off engines, and, as a consequence, fly. Apache starts and turns off engine, flies, and radio broadcasts. The more specific the vehicle class, the more abilities it possesses. But basic abilities are also preserved. Example of LSP Violation Example code in Python where LSP is violated: class Vehicle: def __init__(self): self.x = 0 self.y = 0 self.z = 0 self.engine = False def on(self): if not self.engine: self.engine = True return "Engine started" else: return "Engine already started" def off(self): if self.engine: self.engine = False return "Engine turned off" else: return "Engine already turned off" def move(self): if self.engine: self.x += 10 self.y += 10 self.z += 10 return "Vehicle moved" else: return "Engine not started" # various vehicle classes class Car(Vehicle): def move(self): if self.engine: self.x += 1 self.y += 1 return "Car drove" else: return "Engine not started" class Helicopter(Vehicle): def move(self): if self.engine: self.x += 1 self.y += 1 self.z += 1 return "Helicopter flew" else: return "Engine not started" def radio(self): return "Buzz...buzz...buzz..." In this case, the parent Vehicle class has a move() method denoting vehicle movement. Inheriting classes override the basic Vehicle behavior, setting their own movement method. Example of LSP Application Following LSP, it's logical to assume that Car and Helicopter should preserve movement ability, adding unique types of movement on their own: driving and flying. Example code in Python where LSP is used: # base vehicle class class Vehicle: def __init__(self): self.x = 0 self.y = 0 self.z = 0 self.engine = False def on(self): if not self.engine: self.engine = True return "Engine started" else: return "Engine already started" def off(self): if self.engine: self.engine = False return "Engine turned off" else: return "Engine already turned off" def move(self): if self.engine: self.x += 10 self.y += 10 self.z += 10 return "Vehicle moved" else: return "Engine not started" # various vehicle classes class Car(Vehicle): def ride(self): if self.engine: self.x += 1 self.y += 1 return "Car drove" else: return "Engine not started" class Helicopter(Vehicle): def fly(self): if self.engine: self.x += 1 self.y += 1 self.z += 1 return "Helicopter flew" else: return "Engine not started" def radio(self): return "Buzz...buzz...buzz..." class Tesla(Car): def __init__(self): super().__init__() self.autopilot = False def switch(self): if self.autopilot: self.autopilot = False return "Autopilot turned off" else: self.autopilot = True return "Autopilot turned on" class Apache(Helicopter): def __init__(self): super().__init__() self.frequency = 103.4 def radio(self): if self.frequency != 0: return "Buzz...buzz...Copy, how do you hear? [" + str(self.frequency) + " GHz]" else: return "Seems like the radio isn't working..." In this case, Car and Helicopter, just like Tesla and Apache derived from them, will preserve the original Vehicle behavior. Each inheritor adds new behavior to the parent class but preserves its own. LSP Advantages Code following LSP works with parent classes the same way as with their inheritors. This way you can implement interfaces capable of interacting with objects of different types but with common properties. Interface Segregation Principle (ISP) ISP (Interface Segregation Principle) is the interface segregation principle, which states that program classes should not depend on methods they don't use. This means that each class should contain only the methods it needs. It should not "drag" unnecessary "baggage" with it. Therefore, instead of one large interface, it's better to create several small specialized interfaces. In many ways, ISP has features of SRP and LSP, but differs from them. Example of ISP Violation Example code in Python that ignores ISP: # base vehicle class Vehicle: def __init__(self): self.hp = 100 self.power = 0 self.wheels = 0 self.frequency = 103.4 def ride(self): if self.power > 0 and self.wheels > 0: return "Driving" else: return "Standing" # vehicles class Car(Vehicle): def __init__(self): super().__init__() self.hp = 80 self.power = 250 self.wheels = 4 class Bike(Vehicle): def __init__(self): super().__init__() self.hp = 60 self.power = 150 self.wheels = 2 class Helicopter(Vehicle): def __init__(self): super().__init__() self.hp = 120 self.power = 800 def fly(self): if self.power > 0 and self.propellers > 0: return "Flying" else: return "Standing" def radio(self): if self.frequency != 0: return "Buzz...buzz...Copy, how do you hear? [" + str(self.frequency) + " GHz]" else: return "Seems like the radio isn't working..." # creating vehicles bmw = Car() ducati = Bike() apache = Helicopter() # operating vehicles print(bmw.ride()) # OUTPUT: Driving print(ducati.ride()) # OUTPUT: Driving print(apache.ride()) # OUTPUT: Standing (redundant method) print(apache.radio()) # OUTPUT: Buzz...buzz...Copy, how do you hear? [103.4 GHz] In this case, the base vehicle class implements properties and methods that are redundant for some of its inheritors. Example of ISP Application Example code in Python that follows ISP: # simple vehicle components class Body: def __init__(self): self.hp = 100 class Engine: def __init__(self): self.power = 0 class Radio: def __init__(self): self.frequency = 103.4 def communicate(self): if self.frequency != 0: return "Buzz...buzz...Copy, how do you hear? [" + str(self.frequency) + " GHz]" else: return "Seems like the radio isn't working..." # complex vehicle components class Suspension(Engine): def __init__(self): super().__init__() self.wheels = 0 def ride(self): if self.power > 0 and self.wheels > 0: return "Driving" else: return "Standing" class Frame(Engine): def __init__(self): super().__init__() self.propellers = 0 def fly(self): if self.power > 0 and self.propellers > 0: return "Flying" else: return "Standing" # vehicles class Car(Body, Suspension): def __init__(self): super().__init__() self.hp = 80 self.power = 250 self.wheels = 4 class Bike(Body, Suspension): def __init__(self): super().__init__() self.hp = 60 self.power = 150 self.wheels = 2 class Helicopter(Body, Frame, Radio): def __init__(self): super().__init__() self.hp = 120 self.power = 800 self.propellers = 2 self.frequency = 107.6 class Plane(Body, Frame): def __init__(self): super().__init__() self.hp = 200 self.power = 1200 self.propellers = 4 # creating vehicles bmw = Car() ducati = Bike() apache = Helicopter() boeing = Plane() # operating vehicles print(bmw.ride()) # OUTPUT: Driving print(ducati.ride()) # OUTPUT: Driving print(apache.fly()) # OUTPUT: Flying print(apache.communicate()) # OUTPUT: Buzz...buzz...Copy, how do you hear? [107.6 GHz] print(boeing.fly()) # OUTPUT: Flying Thus, all vehicles represent a set of components with their own properties and methods. No finished vehicle class carries an unnecessary element or capability "on board." ISP Advantages Thanks to ISP, classes contain only the necessary variables and methods. Moreover, dividing large interfaces into small ones allows specializing logic in the spirit of SRP. This way interfaces are built from small blocks, like a constructor, each of which implements only its zone of responsibility. Dependency Inversion Principle (DIP) DIP (Dependency Inversion Principle) is the dependency inversion principle, which states that upper-level components should not depend on lower-level components. In other words, abstractions should not depend on details. Details should depend on abstractions. Such architecture is achieved through common interfaces that hide the implementation of underlying objects. Example of DIP Violation Example code in Python that doesn't follow DIP: # projector class Light(): def __init__(self, wavelength): self.wavelength = wavelength def use(self): return "Lighting [" + str(self.wavelength) + " nm]" # helicopter class Helicopter: def __init__(self, color="white"): if color == "white": self.light = Light(600) elif color == "blue": self.light = Light(450) elif color == "red": self.light = Light(650) def project(self): return self.light.use() # creating vehicles helicopterWhite = Helicopter("white") helicopterRed = Helicopter("red") # operating vehicles print(helicopterWhite.project()) # OUTPUT: Lighting [600 nm] print(helicopterRed.project()) # OUTPUT: Lighting [650 nm] In this case, the Helicopter implementation depends on the Light implementation. The helicopter must consider the projector configuration principle, passing certain parameters to its object. Moreover, the script similarly configures the Helicopter using a boolean variable. If the projector or helicopter implementation changes, the configuration parameters may stop working, which will require modification of upper-level object classes. Example of DIP Application The projector implementation should be completely isolated from the helicopter implementation. Vertical interaction between both entities should be performed through a special interface. Example code in Python that considers DIP: from abc import ABC, abstractmethod # base projector class class Light(ABC): @abstractmethod def use(self): pass # white projector class NormalLight(Light): def use(self): return "Lighting with bright white light" # red projector class SpecialLight(Light): def use(self): return "Lighting with dim red light" # helicopter class Helicopter: def __init__(self, light): self.light = light def project(self): return self.light.use() # creating vehicles helicopterWhite = Helicopter(NormalLight()) helicopterRed = Helicopter(SpecialLight()) # operating vehicles print(helicopterWhite.project()) # OUTPUT: Lighting with bright white light print(helicopterRed.project()) # OUTPUT: Lighting with dim red light In such architecture, the implementation of a specific projector, whether NormalLight or SpecialLight, doesn't affect the Helicopter device. On the contrary, the Helicopter class sets requirements for the presence of certain methods in the Light class and its inheritors. DIP Advantages Following DIP reduces program coupling: upper-level code doesn't depend on implementation details, which simplifies component modification or replacement. Thanks to active use of interfaces, new implementations (inherited from base classes) can be added to the program, which can be used with existing components. In this, DIP overlaps with LSP. In addition to this, during testing, instead of real lower-level dependencies, empty stubs can be substituted that simulate the functions of real components. For example, instead of making a request to a remote server, you can simulate delay using a function like time.sleep(). And in general, DIP significantly increases program modularity, vertically encapsulating component logic. Practical Application of SOLID SOLID principles help write flexible, maintainable, and scalable code. They are especially relevant when developing backends for high-load applications, working with microservice architecture, and using object-oriented programming. Essentially, SOLID is aimed at localization (increasing cohesion) and encapsulation (decreasing coupling) of application component logic both horizontally and vertically. Whatever syntactic constructions a language possesses (perhaps it weakly supports OOP), it allows following SOLID principles to one degree or another. How SOLID Helps in Real Projects As a rule, each iteration of a software product either adds new behavior or changes existing behavior, thereby increasing system complexity. However, complexity growth often leads to disorder. Therefore, SOLID principles set certain architectural frameworks within which a project remains understandable and structured. SOLID doesn't allow chaos to grow. In real projects, SOLID performs several important functions: Facilitates making changes Divides complex systems into simple subsystems Reduces component dependency on each other Facilitates testing Reduces errors and makes code predictable Essentially, SOLID is a generalized set of rules based on which software abstractions and interactions between different application components are formed. SOLID and Architectural Patterns SOLID principles and architectural patterns are two different but interconnected levels of software design. SOLID principles exist at a lower implementation level, while architectural patterns exist at a higher level. That is, SOLID can be applied within any architectural pattern, whether MVC, MVVM, Layered Architecture, Hexagonal Architecture. For example, in a web application built on MVC, one controller can be responsible for processing HTTP requests, and another for executing business logic. Thus, the implementation will follow SRP. Moreover, within MVC, all dependencies can be passed through interfaces rather than created inside classes. This, in turn, will be following DIP. SOLID and Code Testability The main advantage of SOLID is increasing code modularity. Modularity is an extremely useful property for unit testing. After all, classes performing only one task are easier to test than classes consisting of logical "hodgepodge." To some extent, testing itself begins to follow SRP, performing multiple small and specialized tests instead of one scattered test. Moreover, thanks to OCP, adding new functionality doesn't break existing tests, but leaves them still relevant, despite the fact that the overall program behavior may have changed. Actually, tests can be considered a kind of program snapshot. Exclusively in the sense that they frame application logic and test its implementation. Therefore, there's nothing surprising in the fact that tests follow the same principles and architectural patterns as the application itself. Criticism and Limitations of SOLID Excessive adherence to SOLID can lead to fragmented code with many small classes and interfaces. In small projects, strict separations may be excessive. When SOLID May Be Excessive SOLID principles are relevant in any project. Following them is good practice. However, complex SOLID abstractions and interfaces may be excessive for simple projects. On the contrary, in complex projects, SOLID can simplify code understanding and help scale implementation. In other words, if a project is small, fragmenting code into many classes and interfaces is unnecessary. For example, dividing logic into many classes in a simple Telegram bot will only complicate maintenance. The same applies to code for one-time use (for example, one-time task automation). Strict adherence to SOLID in this case will be a waste of time. It must be understood that SOLID is not a dogma, but a tool. It should be applied where it's necessary to improve code quality, not complicate it unnecessarily. Sometimes it's easier to write simple and monolithic code than fragmented and overcomplicated code. Alternative Design Approaches Besides SOLID, there are other principles, approaches, and software design patterns that can be used both separately and as a supplement to SOLID: GRASP (General Responsibility Assignment Software Patterns): A set of responsibility distribution patterns describing class interactions with each other. YAGNI (You Ain't Gonna Need It): The principle of refusing excessive functionality that is not immediately needed. KISS (Keep It Simple, Stupid): A programming principle declaring simplicity as the main value of software. DRY (Don't Repeat Yourself): A software development principle minimizing code duplication. CQS (Command-Query Separation): A design pattern dividing operations into two categories: commands that change system state and queries that get data from the system. DDD (Domain-Driven Design): A software development approach structuring code around the enterprise domain. Nevertheless, no matter how many approaches there are, the main thing is to apply them thoughtfully, not blindly follow them. SOLID is a useful tool, but it needs to be applied consciously.

Ansible is an open-source tool used for automating tasks related to management, configuration, and maintenance of servers or network devices. Official website and documentation: https://docs.ansible.com/ How Ansible Works So, what does Ansible do? It connects to selected nodes (hosts) from your inventory and sequentially executes tasks to bring them into the desired state. playbook: a file describing tasks and their sequence task: a task, a single action for verification or execution inventory: grouping and list of managed nodes (hosts) Advantages The simplest yet most powerful automation tool Does not require additional software installed on managed nodes (only Python is needed, which usually comes “out of the box”) Uses the standard SSH protocol for connections Only necessary changes are applied Operations can be safely re-run (the system won’t make redundant changes) Ensures consistent system state Allows clear and convenient infrastructure descriptions In addition, Ansible has a large community that develops and supports various modules. Where Is Ansible Used? Main use cases: System preparation and configuration Automated software deployment, package and service management Automation of CI/CD processes Network device configuration (network management) System auditing, applying security policies, and automatic compliance enforcement It’s important to understand that Ansible is just a tool. Choosing the right tool depends on the task at hand. For example, theoretically, you can use Ansible to manage Kubernetes (k8s) configurations, but there are better tools for that purpose: Helm, helmwave, and kustomize. Another example: with Ansible, you can create virtual machines and containers in clouds or hypervisors, but Terraform is better suited for such tasks. Installing Ansible Ansible can be installed as a standalone package or via Python libraries. Installation instructions for different operating systems are available in the documentation. For installation, the following VPS at Hostman is sufficient: OS: Ubuntu 24.04 CPU: 1 × 3.3 GHz RAM: 1 GB NVMe: 15 GB Ansible Configuration Settings: Key Files and Parameters Configuration File Path to the configuration file: /srv/ansible/ansible.cfg Example configuration: [defaults] inventory = ./hosts.yaml host_key_checking = False log_path = /var/log/ansible.log vault_password_file = ./vault.key force_color = 1 callback_result_format = yaml [ssh_connection] timeout = 10 retries = 2 server_alive_interval = 60 pipelining = True ssh_args = "-o StrictHostKeyChecking=no" scp_if_ssh = True allow_world_readable_tmpfiles = True Section [defaults] inventory = ./hosts.yaml: specifies the path to the hosts file. This file stores information about all managed hosts and organizes them into logical groups. host_key_checking = False: by default, Ansible enables host key checking. Host key checking protects against server spoofing. Not recommended in production, but convenient for development. log_path = /var/log/ansible.log: path to the log file. vault_password_file = ./vault.key: path to the master password file, used for Ansible Vault encryption. force_color = 1: enables colored logs for readability. callback_result_format = yaml: formats output results as YAML. Some parameters can be set as environment variables, for example: ANSIBLE_HOST_KEY_CHECKING=False ANSIBLE_FORCE_COLOR=1 Other parameters, such as inventory or vault_password_file, can be set in the command line when launching: ansible-playbook ansible/debug.yaml -i ansible/hosts.yaml But it is more convenient and clearer to store basic settings in the file ansible/ansible.cfg. Ansible Inventory: Managing Hosts To manage hosts, the file ansible/hosts.yaml is used. Example: all: vars: ansible_user: ansible hosts: 5.181.182.204: # your host IP or domain ansible_user: root # ansible_password: 'SuperPass' ansible_ssh_private_key_file: ./ansible/ssh/id_rsa As connection points, you can use either an IP address or a domain name. In this example, there is no domain name, so we specify the external IP address obtained when creating the Hostman VM. Note: the user password must be enclosed in quotes. Connections usually use either a password or a certificate (public key must be pre-installed on remote nodes). For experiments, it’s easier to use a password. When using a private key, you must check file permissions for id_rsa; only the owner should have read access; no one else can copy or modify the key: chmod -R 400 ./ansible/ssh/id_rsa In the file ansible/hosts.yaml, the variable vars.ansible_user is set for demonstration. Inside hosts.ansible_user, the same variable is redefined as root. If you don’t override it and only define it at the higher vars level, you can avoid duplicating common variables across different hosts. Basic Commands and Usage Examples Let’s start with simple tasks that don’t make changes to the system but help to understand the structure of commands. For example, we have the ansible/debug.yaml file, a simple playbook example. Run it: ansible-playbook ansible/debug.yaml In the output, we’ll see various system information and go through the commands from the file ansible/debug.yaml in order: - hosts: all vars: my_variable: aaaawww tasks: - name: Show ansible variable debug: msg: "variable: {{ my_variable }}" - name: Show environment variable debug: var: lookup('env', 'ANSIBLE_CONFIG') - name: Show OS release info debug: msg: "{{ ansible_distribution }} {{ ansible_distribution_version}} {{ansible_distribution_release}}" hosts: defines which nodes (hosts) to run commands on. Since we specified only one host in ansible/hosts.yaml, all tasks will be executed on that host. vars: allows us to set variables at the playbook level. tasks: sequence of tasks to run. Output of the variable set in vars: - name: Show ansible variable   debug:     msg: "variable: {{ my_variable }}" Output of an environment variable: - name: Show environment variable   debug:     var: lookup('env', 'ANSIBLE_CONFIG') Output of OS and hardware info: - name: Show OS release info debug: msg: "{{ ansible_distribution }} {{ ansible_distribution_version}} {{ansible_distribution_release}}" - name: Show total CPU + RAM debug: msg: | CPU cores: {{ ansible_processor_cores * ansible_processor_count }} Total memory: {{ ansible_memtotal_mb }} MB Where does Ansible get this data? By default, unless gather_facts: false is set, Ansible automatically collects system information when connecting to a host. To view all collected information, you can use this task: tasks: - name: Show all facts debug: var: ansible_facts Each task is described using a module and its parameters: name: task name (arbitrary) debug: name of the module (from the list of available ones, depending on goals) debug.var: module parameter In the documentation, you may also see examples like: tasks:   - name: Show all facts     ansible.builtin.debug:       var: ansible_facts ansible.builtin.debug is the same as the debug module (the ansible.builtin prefix can be omitted). debug and other standard modules are part of Ansible’s core. All built-in modules can be found in the documentation. apt Module (Debian/Ubuntu Package Manager) See Documentation for the module. - name: Install packages   apt:     pkg:       - htop       - curl Even without documentation, it’s clear that this task will install the htop and curl packages (equivalent to apt install -y htop curl). Checking Variables with when and assert Goal: Check that the variable my_age contains a number between 18 and 100. - name: Check var hosts: all vars: my_age: 42 tasks: - name: Checking the type of a variable fail: msg: "The variable must be an integer" when: my_age is not integer - name: The value of the my_age variable must be between 18 and 100 assert: that: - my_age <= 100 - my_age >= 18 fail_msg: "Incorrect my_age value - must be from 0 to 100" success_msg: "The value of my_age is correct" At the start, the variable my_age = 42 is set. The first task checks with when if it’s actually an integer; if not, the playbook stops with an error. The second task checks if the value is within the range. If you run the playbook, it will succeed. But if you override the variable in the launch command: ansible-playbook ansible/playbooks/assert.yaml --extra-vars "{ my_age: 769 }" You’ll get an error and the playbook will stop: TASK [The value of the my_age variable must be between 18 and 100] ************** fatal: [5.181.182.204]: FAILED! => assertion: my_age <= 100 changed: false evaluated_to: false msg: Incorrect my_age value - must be from 0 to 100 Loops Loops in Ansible look like this: - hosts: all tasks: - name: Register loop output as a variable shell: "echo {{ item }}" loop: - "test" - "test2" - "test3" register: echo In this task, the echo command will run for each element in the loop list. Additional functions: map: a basic for loop; iterates over list items. select / reject: conditional for; creates a subset of a list matching (or not matching) conditions. selectattr / rejectattr: similar, but works on specific attributes of list elements. Ansible selectattr: Filtering Data in Playbooks Example: select only red fruits from a list using selectattr. - hosts: all vars: fruits_list: - name: apple color: red - name: banana color: yellow - name: cherry color: red tasks: - name: Selectattr show red fruits debug: msg: "{{ item.name }} is red." loop: "{{ fruits_list | selectattr('color', '==', 'red') | list }}" copy Module Playbook: ansible/playbooks/copy.yaml See Documentation for the module. - name: Copy files to remote locations hosts: all tasks: - name: Copy file with owner and permissions copy: src: ../files dest: /tmp owner: root group: root mode: '0644' This task copies the directory from ansible/files to /tmp/files on the remote host. If src is a directory, it is copied recursively. If the path ends with /, only the contents are copied into the destination. This behavior is similar to rsync. To copy files from a remote host back to local, use the fetch module (see documentation). template Module See Documentation for the module. Templates let you create dynamic files by inserting variable values. Ansible uses the Jinja2 templating engine. Example template file ansible/files/simple_template.j2 (not required to use .j2 extension, but recommended): # This is a simple example of using a template. name: {{ name }} task: {{ task }} Playbook using the template: - name: Template a file out to a target host hosts: all tasks: - name: Simple template a file template: src: ../files/simple_template.j2 dest: /tmp/test.conf vars: name: "Ansible" task: "Template" As the result, the remote host receives the file with substituted variables. You may want to check an online service for creating and testing templates: tech-playground.com. Ansible Web UI The main way to run and use Ansible is the command line, but there are projects that provide a graphical interface for managing tasks: Ansible AWX (free, Apache License 2.0) Red Hat Ansible Tower (commercial) Semaphore (free, MIT License) Semaphore UI Ansible vs Other Automation Systems Infrastructure automation tools fall into two main categories: Configuration management tools: Ansible Chef SaltStack Puppet Their main job: configuring and managing software on already existing servers. They automate software installation, package updates, and system settings. Provisioning tools: Terraform Pulumi Their job: creating the infrastructure itself: virtual machines, networks, databases. This is a broader approach that starts from the foundation of IT systems. Often, these tools are combined, with Terraform + Ansible being the most common pairing. Feature Highlights Ansible Easiest to start with No extra software required on nodes (besides Python) Uses SSH protocol for connections Chef Uses cooking metaphors (recipes, cookbooks) Suitable for complex infrastructures Strong support for configuration testing Steeper learning curve SaltStack High performance thanks to optimized architecture Good for large-scale solutions Modules are written in Python Works well in distributed systems Puppet Powerful for large enterprises Well documented More complex to learn, but very powerful Great for standardizing configurations In any case, we recommend starting with Ansible when learning infrastructure automation. Summary In this article, we aimed to show Ansible’s built-in modules and basic usage examples as clearly as possible. However, the most effective way to learn such tools is practice. Ansible skills are often required in job postings for system administrators, DevOps engineers, and SREs. Next steps for learning: Roles Encryption with ansible-vault Community Collections

File sharing is an integral part of the modern Internet. Files are downloaded from websites, sent through social networks and messengers, and uploaded to remote storage. The level of detail in modern virtual objects is astonishing. Game textures are no longer eight-bit, and images now come in extremely high resolution. Naturally, such detail requires resources. Despite compression technologies, file sizes grow year after year. For example, in the early 2010s, a technologically advanced computer game rarely exceeded 10 gigabytes in size. A modern AAA title can easily surpass 200 gigabytes. That is why special services for file sharing have emerged.  What is a File Sharing Service A file sharing service is an online platform for storing and exchanging files between users. Files can be of any type: Documents Images Videos Audio Text Binaries In essence, a file sharing service acts as a type of file hosting with a set of tools for sending files to other users, compressing them, editing, and analyzing their contents. So, how do you share a file? You simply upload a file to a remote server and then send a special link to another person, allowing them to download the file to their local computer. Thus, the service takes on the full functionality of storing and transferring files, relieving the devices of ordinary Internet users from these tasks. Types of File Sharing Services File sharing is actually a broad concept. There are many ways to organize the process, and they differ technologically. This applies both to storage infrastructure and transfer protocols. File Sharing Service vs. Cloud Storage The fundamental difference between a file sharing service and cloud storage is evident from the names: a file sharing service focuses on exchanging files, while cloud storage emphasizes storing them. While file sharing services rely on a centralized server architecture, cloud storage represents a distributed network of servers. As a rule (though not always), file sharing services limit the maximum file size and retention period. In contrast, cloud storage rarely imposes restrictions, especially on paid plans. However, with the development of cloud technologies, the line between file sharing services and cloud storage is becoming blurred. In fact, classical file sharing services are now rarely used. Modern cloud storage provides the same or even greater functionality for free. Paid subscriptions often remove all limits entirely. Moreover, the term “file sharing service” is undergoing semantic change. It increasingly means “storage” rather than “exchange,” and the phrase is used less frequently. People now say “uploaded to the cloud” rather than “uploaded to a file sharing service.” Nevertheless, file sharing services anticipated the era of cloud storage, and they remain relevant today. P2P File Sharing Services P2P (Peer-to-Peer) is a computer network where all users are equal participants in data exchange. Special clients are used to connect to P2P networks. There are dozens of them, but the most popular include: uTorrent BitTorrent MediaGet eMule Despite having file exchange functionality, a P2P network is not a file sharing service in the strict sense as it does not have its own server for centralized file storage. Unlike classical file sharing services, P2P networks focus more on efficient data transfer than on storage. Moreover, P2P technology does not impose any limits on file size or transfer speed; it depends on the infrastructure and protocol. For example, the BitTorrent protocol can handle files up to one terabyte. However, downloading a large amount of data may be unstable if there are few seeds, i.e., participants distributing files in the P2P network. That is why a 10-gigabyte file could take anywhere from 30 minutes to 30 hours to download. The quality of file sharing in P2P networks depends on several key factors: Number of seeds: the number of participants sharing files. Internet speed: network restrictions imposed by the provider. P2P client settings: limits on speed and simultaneous connections. NAT and firewall: blocking of incoming connections at the network level. P2P networks are most often used for secure file downloads. If the connection is lost, the download pauses and resumes automatically without losing progress. Alternative Technologies Centralized file sharing services (and cloud storage) and decentralized P2P networks are the most common, but not the only ways to exchange files. Other technologies include: NAS servers: Network Attached Storage allows files to be stored on a separate physical server (corporate or home) connected to a local network. FTP/SFTP connections: Standard FTP (File Transfer Protocol) and secure SFTP (SSH File Transfer Protocol) allow files to be transferred between network nodes: a remote server and a user. Messengers and social networks: Almost all modern communication platforms support sending files in private messages and comments. In this case, files are stored on the platform’s remote server. Many users therefore use social networks as free file hosting. Email: Files up to 25 MB can be attached to emails, which are then sent through the mail server. Most file transfer methods operate in a centralized manner. They require a main server (or group of servers) to handle data transmission. File sharing services act as a compromise compared to other methods. They are easier to use than cloud storage, P2P networks, or NAS servers but offer less security and control over files. Cloud storage is large, P2P networks are highly decentralized, and NAS servers are complex. Social networks and messengers may be safer and more functional but require registration and personal data. In short, file sharing services balance multiple characteristics, remaining the most optimal method for exchanging files. For long-term storage, cloud storage is the best choice. Each method has its core ability: File sharing service: fast exchange Cloud storage: long-term storage P2P network: secure download NAS server: high control Messenger/social network: social engagement Email: simple sending How File Sharing Works A classical file sharing service is a website for uploading and downloading files. Each uploaded file has its own page with information on its name, extension, format, size, creation date, and upload date. A link to this page can be shared with anyone. From a user’s perspective, file sharing services and cloud storage work similarly: uploading, storing, and sending files to others. Choosing a file: On a dedicated page (sometimes the homepage), the user either clicks a button to manually select files or drags them into a designated area. Uploading the file: After selection, the user clicks “Upload” to start transferring files to the remote server, and a progress indicator shows the status. Generating a link: Once uploaded, the service provides a unique URL to the file page, including basic information and a download button. Access permissions: Some services allow setting permissions for uploaded files, using HTTP cookies or authorization data. Sharing the link: The URL can be shared with others so they can download the file. Most file sharing services require registration, though some allow uploads with limits on file size and retention period. Usage differs depending on whether the user is logged in. Types of file sharing services: Without registration: anonymous services with minimal control and limited retention. With registration: services with personal dashboards; the best file sharing platforms are of this type. Encrypted: secure services with client-side encryption, hiding content even from the platform itself. Choosing a File Sharing Service There are many services available online. Option 1: One-time transfer For one-time file sharing, free services with direct links are suitable. These usually show ads, their main monetization method. Example: an interior designer uploads a ZIP archive of a finished 3D model and sends the link via email. Option 2: Recurring transfers For regular sharing of the same files with multiple users, use a service with registration and a full dashboard. Paid plans often remove limits. Example: a student uploads nine volumes of a textbook in PDF format and shares links in various groups and chats, allowing downloads throughout the academic year. Option 3: Constant transfers For continuous large-scale sharing, cloud storage is best. Example: an audiobook website administrator uploads MP3 files to cloud storage and shares links on the site. Option 4: Constant distribution For regularly sharing large amounts of data (hundreds or thousands of megabytes) with many users, P2P networks are ideal. Users must install a special client. Example: a mod developer distributes a large game mod through a P2P network. Participants can download and share files depending on the network and client. Top File Sharing Services in 2025 Name Free Storage Paid Storage Max File Size Min Subscription Files.fm 20 GB 2 TB–100 TB 400 GB $10/mo Filemail 5 GB 250 GB–1 TB 250 GB $5/mo   Jumpshare 2 GB - 20 GB $15/mo   Transfer Now 5 GB 500 GB–2 TB 500 GB 10 €/mo   Send Anywhere 10 GB 200 GB–500 TB 30 GB $6/mo   anonfiles - - 20 GB -   MediaFire 10 GB 50 GB–1 TB 50 GB $4/mo   Tresorit - 50 GB–4 TB 20 GB $6/mo   DropMeFiles 50 GB - 50 GB - Top Cloud Storage in 2025 Name Free Storage Paid Storage Max File Size Min Subscription Google Drive 15 GB 100 GB–2 TB 10 GB $2/mo OneDrive 5 GB 100 GB–6 TB 250 GB $2/mo Dropbox 2 GB 2 TB–15 TB 250 GB $12/mo TeraBox 1024 GB 2 TB–5 TB 128 GB 249 ₽/mo pCloud 10 GB 500 GB–10 TB - $5/mo Conclusion Universal services, although increasingly popular, cannot fully replace specialized tools. Despite the shift to cloud, file sharing services remain relevant. Cloud storage is multifunctional but bulky. A file sharing service is specialized but compact. Cloud storage is like a multitool with many attachments. A file sharing service, by contrast, resembles a pocket knife with a sharp, dedicated edge. For quick local tasks, overly complex tools are unnecessary. “Upload, send, forget!” is the motto of the modern file sharing service.