The last couple of years have been challenging on a personal level. Fortunately, I love solving problems. I found peace with the help of a psychologist (To understand why I was suffering), the practice of yoga and more importantly, a course of MBSR (Mindfulness Based Stress Reduction) to learn how to deal with my emotions.
For years at work I’ve been struggling teaching developers about the need to embrace a defensive programming mindset. Often, I’ve been told that there is no time for this, that the feature must be delivered first, because that’s why the customer asked for. Of course that is true. But it is also true that the software should be resilient to unforeseen circumstances.
I’m not going to quote the Wikipedia article. To make things simple please reflect on the following:
Nothing is stable, everything come into being before dissolving.
Think about your breathing for instance, or the weather, which are both perfect examples of the process.
When programming for the cloud (should it be public or private), you should not assume that the state of the platform you’re relying on will never change. On the contrary, it is always changing – as I wrote these lines and as you read them- and I’m not talking about outages. Orchestrators are doing their everyday jobs: reconfiguring virtual networks, virtual machines and containers to permanently meet customer needs.
I encourage everyone to watch Jeffrey Richter’s excellent free videos about architecting distributed cloud applications.
And remember, the next time you’re writing a call to a web service, please take some time to remove the network cable or deactivate your network card to see how it goes. Of course it will fail, and you’re going to do something about it. Like retries for instance. Your customer will thank you for that, believe me.
I hope I gave you some sense of my bridge metaphor.