We live a completely digital world. Every day we use a diverse range of applications for everything from communicating with our friends and families, to watching films or series, listening to music, learning about things that motivate us or searching for a new job.
Last week’s article described the difficulties faced by developers when working with distributed and/or microservice architectures, often lacking in-depth knowledge about the underlying network technologies that enable different components of the architectures to communicate.
Microservice-based architectures are changing the way we design software today, raising new challenges in development and operations. These architectures are adding a strong network dependency on business logic, increasing the number of potential hazards, which grow proportionally to the connections or links that are created between services.
Many companies today are opting for microservices-based architecture. And this most certainly has to do with the fact that microservices are a perfect complement to SDN/SD-WAN technology, allowing the modules that make up the applications to be implanted in numerous servers or data centers.
Since the early days of systems administration, a god has hovered over server rooms: uptime. uptime tells us how long a server has been on, which indirectly indicates how long it has been since it had a problem requiring a reboot. Operating systems have always had commands to display server uptime, figures that, indirectly, were also indicative of how good a job the administrators were doing. But the gods aren’t eternal; they are outdone, or simply replaced, by other gods. The time must come for even uptime to fall.