The paradigm of Change of state vs Change a whole block

I’m an engineer that worked with infrastructure as a system engineer at that time when we didn’t know what’s Jenkins because it was called Hudson. When NGNIX had a logo that looks like a Russian jet.

it was the Jenkins at that time

In that time nobody spokes anything about Infrastructure as Code, and Immutable Infrastructure, which is pretty recent concepts and best practices.
We had an idea that we need an agent, inside of our machines(bare-metal) or Virtual Machines(new technology for that time) to automate our configuration and keep everything on track. Some years in that wave yet, some authors and specialists were starting sharing where did this bring us:

agents in a host

1) Working for the tools not to what the tools can provide

In the day-by-day, in real-life, we worked several hours creating scripts to install the agents for Zabbix, Nagios, Chef, Puppet, VMWare, Storage Systems, etc.. etc.. After that work we have to monitor these agents, update it. When we finished this work we didn’t have better configuration management, we don’t have a better monitoring system, or whatever these agents can bring to us, we just have our environment ready to use. What results we can deliver to business in this stage? nothing! we had only working to attend the requirements of the tools that we decided to use.

when tools are more relevant than results…

2) Cloud as commodity & Network

We starting seeing in 2006 Amazon launching the AWS and the movement of Cloud was being more professional that we never saw before. We still had thousands of ISP, Hosting Providers but the first global cloud appeared. Our strategy moves faster to add proxies for these regions to connect our corporate headquarters(HQ), MPLS/VPN networks with these Hosting Providers, or Amazon AWS. At that moment we expand our agent issues to proxies issues, communications between agents, and central servers are constant in our backlog.
The network…