A new age of programmable infrastructures
There are a thousand reasons why creating and operating an IT infrastructure can be problematic, but entrusting the stability, reproducibility, and reliability of the operation of your system to an “irreplaceable” system administrator doesn’t have to be one.
While it’s true that certain programming skills are required to maintain an IT infrastructure, it isn’t an unrealistic expectation of this working in IT.
IT infrastructures, according to Wikipedia, are the IT components that serve as the foundation of an IT service. In a nutshell, the infrastructure includes everything that’s “behind” and “supporting” the system this includes the hardware, software, network and other devices necessary for developing and operating a service.
If we are examining “programmable infrastructures”, it’s important to clarify what an IT infrastructure is since it’s harder to comprehend the concept of the infrastructure than the idea of something that is programmable. Now that we know what an infrastructure is, we can discuss what it means for something to be programmable. A program is a collection of data and commands that a computer can execute in order to resolve a particular problem. If something is programmable, this means that we are able to or at least have the option of creating a program that solves the problem in question.
This reasoning suggests that an infrastructure can be complex – anyone who has ever dealt with the installation or operation or a computer system is aware of this. Creating and operating an infrastructure has always been a challenge, but programmable infrastructures are the technology created to help facilitate this process.
In a typical conventional approach, you get a computer, install basic software in preparation and finally, embed (install) the system in question. What’s the trouble with this? There doesn’t seem to be any issues, but if you think about it, this procedure can be problematic in many ways. Firstly, it requires a person who knows what they’re doing. Hiring staff is costly, particularly if they are skilled in something. What is more, one person isn’t enough – what happens when they take their annual leave or if they cannot work for any particularly reason?
You require several people and the viability of your system will depend on their expertise and the knowledge they possess…
“Documentation!” cries the experienced IT manager, but we all know that the extent to which documentation is maintained is directly proportional to the lull in the drive of the project – it continuously decreases. At the beginning, everything works smoothly, resulting in documentation fit for a dissertation. Then the updates become more sporadic until the whole thing is lost in oblivion and there’s only a single system admin who still knows the magic words to enter in a particular configuration file in a particular folder on a particular server in order to reboot the system.
Not to mention that occasionally it’s necessary to identically replicate systems in order to test or troubleshoot them when necessary, and reinstall them in the case of machine failure or possibly train new users in a more stable environment without disturbing live operation. In such cases, we are at the mercy of documentation of a dubious quality and an irreplaceable system admin and their skills in creating a replica that closely approximates the live environment from start to finish (documentation).
Unfortunately, human memory is fallible. We can’t always remember everything perfectly and we don’t always perform a task the same way twice. While in most cases, when the documentation is incomplete, efforts to replicate systems will mostly only yield limited results. It’d be impossible to create two identical systems from scratch.
Subsequent to reinstallation, the new server won’t be the same as the old one. The software (the infrastructure that we’re talking about) is rightfully ‘offended’ by this and doesn’t operate as expected and no one can explain exactly why this is the case. You would be left searching for the cause for days, or weeks in the worst cases, wasting a great deal of time and money on troubleshooting and even if you manage to find the cause of the problem and fix it, there is no way to guarantee that it won’t happen again. Which is rather disturbing…
“Backups!” cries the IT manager again, who continues to trust in his bonus and assumes that shouting is a show of expertise. They suggest that backups should be created that can be used for restoring in a different environment and reproduce the faulty system or one which is to be tested, taught or replicated for any other reason.
This sounds nice and rather idealistic, but it isn’t very effective at all. Backing up and restoring is usually a time and energy-intensive process and as such is typically designed for restoration purposes after an emergency and not as the foundation of running automated tests even several times a day to inspect the soundness of new developments. Just to mention a single example, I intentionally omitted the issues of load-proportional scaling and resource optimization from this discussion, even though they are related to the subject.
So what can we do?
Thankfully, we’re in the age of agile cloud systems, so there’s actually quite a lot we can do. Life would be easier if our systems and their infrastructure didn’t have to be manually created and maintained, but rather through the use of auditable, reusable declarative programs that can be automated, serve as documentation and stored in version control. In fact, life would be much, much easier!
Say goodbye to your irreplaceable System Admin and say hello to Programmable DevOps Infrastructure! The sector has long realized the opportunities in this and with the spread of cloud services, most infrastructure services are available through programmable interfaces. Moreover, this isn’t only commonplace with major service providers (AWS, Azure, GCP, etc.) but also with in-house virtualization solutions (OpenStack, VMWare, etc.).
Although this requires programming skills, this isn’t an unrealistic expectation in the field of IT.
Systems must still be created, albeit by writing and executing programs. It’s like delegating the tasks of a stonemason to a 3D printer following blueprints in the form of commands. Stonemasons no longer have to lay bricks, only operate a 3D printer, while architects no longer have to draw designs in ink on paper, but rather work in ArchiCAD. It’s a brave new world...
2021-05-19
A new age of programmable infrastructures
5 min
Services and products we used
Share