Antifragility and the cloud
My colleague Bill Murray (not the actor but it would be cool if he was) has led a recent piece of research on antifragility. You can read more about that here.
Antifragility is the concept that suggests that 21st Century organisations benefit from being exposed to shocks, stressors and risk. IE, in a culture that embraces experimentation and learns from failure, then you are on the road to continual improvement.
Whilst the Antifragile term may be new to those in IT, the concept certainly isn’t. We’ve been embracing the “Design for Failure” architecture paradigm since EC2 was launched over 10 years ago. This led to things like the famous Netflix Chaos Monkey and the subsequent simian army that constantly injects fault into your environment.
Anitfragility talks about optionality. The paper talks about this in a business context whereby you build options into contracts to potentially give you access to resources at a later stage when you may need them. It then goes on to use the example of cloud computing which essentially gives you the option to use or dispose of infrastructure resources. By building your application in the cloud, you instantly get this option, which may well be more difficult where you to build that same app in your data center.
Optionality for me is a key consideration when designing an application architecture. What options do you want? To be able to move between environments/cloud providers? The option to move off a particular stack and onto another E.G off COTS and onto open source? You may not want to do these things day 1, but you may well want the option to do these in the future if the situation demands it. Antifragility means you are more agile when the environment changes, such as the large scale failure of your cloud provider, your COTS vendor changes licensing or pricing which negatively impacts your environment, regulators bringing in new controls. If your application architecture had these options considered for and designed in at the beginning then your ability to remain agile has improved and the changing environment that will no doubt cause many of your competitors to have to stop and get into a re-engineering project, is now a time you can exploit and move forward in the market place.
I recently spent time in the US with Amazon, Microsoft and Google (amongst others) and I observed that in regards to antifragility they all have slightly different approaches.
Amazon want you to be all in on their cloud. So when choosing them as a cloud provider your options will be limited to the ones they provide, which are vast, but you may not like a single vendor strategy. So now you have to run across multi-clouds and deal with the interoperability issues that presents.
Microsoft want you to use their cloud. You can use their public cloud as well as (soon to launch) their private cloud, Azure Stack. Based on the changing environmental conditions, this will be a nice option to have.
Google were the one that surprised me the most and where the penny/cent dropped. In regards to optionality, they support the most diverse business strategy. They have taken an application centric view on the world, and that is what they want to own, and if it runs in their cloud, then even better, but they give you the flexibility to run it across any. This is where there investment in Kubernetes is such a smart move. By orchestrating the application container they will allow you to run your app across nearly any device. Their acquisition of Apigee even helps deal with some of the legacy technology issues, and allows you to unlock and integrate those with your cloud native apps.
In the very competitive world of cloud, i’d suggest keeping your options open, and building with optionality in mind, taking an approach that embraces containerisation and cross environment orchestration and control, is a good position to be in. Ofcourse, easier said than done. I’m sure you can’t start packing many of your apps straight into containers today, and ship them about without significant integration headaches. So I still see this as the domain of green-field development, but one I will be encouraging people to think of as a starting point for anything new.
Ofcourse, Kubernetes has stiff competition, so it’s not a done deal. You can chose any container orchestration technology and achieve the same optionality, and indeed, if you chose Kubernetes and moved your containers only across AWS and Azure, then Google got a bigger problem.
Antifragility is not new in IT, but it should become a key consideration in application architecture. Optionality is only 1 way to become more antifragile. Read the paper here for more details on becoming antifragile.
