The cumulonimbus cloud of creative destructionPublished: 6 Dec 2015
I spent most of 2015 in the cloud, the computing cloud that is:
- Spur and advise internal cloud migration efforts
- Evaluating cloud computing vendors and products
- Talking to IT department of enterprises with cloud computing initiatives
- Improving DevOps culture and putting in place supporting tools
- Developing Liquid Sky
Yes, its the year of the Enterprise for me (by that, I mean huddling with people that deals with the needs and wants of managing computing for large public companies).
One common theme I find is this. Amidst the stable facade of stability of operations or product direction within lobbies and meeting rooms with manicured plants, firm handshakes and etc., there always seem to be a glint in the corner of the eye of executives and engineers that I interpret as follows:
“Hey man, yep, you definitely need to trust us with this man. I know the quantum of investment may seem huge, but hey! This is the Enterprise world dude and its already cheaper than whatever Enterprise used to pay. Look, I’d been at this for 20 years and I hadn’t been surer that we’d nailed the right approach… but obviously we get better every day right, there are so many contributors working at getting our approach better, it’s not perfection, but you have to get something sensible sorted and you really need to just pay for this and move on to your core competency”
“Look, we’re the hippest shop in the DevOps-Cloud scene, look at these credible teams that had used our product, we’re sure this is the future and there isn’t much commitment to try us out on a monthly basis anyway… and we realise there are larger industry shifts happening with the way applications are ran, we look at those as well and we’re integrated with that approach as well”
“We’d been using this very grounded approach since the 90s. We’d developed policies and safeguards. Yes, its expensive to keep it running the same way but compared to the stability and continuity of business that it is a part of, its well worth it. This Cloud thing, we are looking at it. Agility? I’d been hearing that since I was in college. It’s about what the business want you know… 船到桥头自然直 (the boat will adjust itself as it gets to the bridge)”
“It is clear that public cloud is the way to go, economies of scale and all… Most Enterprises can’t use public cloud out of the box though, you’ll need this and that product to make it more secure and manageable”
“We need to use the right tool for the right job, project X will do just fine with VMs. Why do we need to look at containers again?… This guy should know that I used to administer Solaris Containers back in 2005 before dropping names at me”
“Seriously wish I can just commit my code and be done with it… Though I dream that one day I really can be done with it when I can just code against services and not have any environment concern at all”
The common theme, well, is that of change. Amidst the certainty that they exude when selling a certain product, endorsing a certain decision or agreeing to a certain design, I think the general vibe with everyone is that the cloud is still a rapidly changing proposition.
Don’t get me wrong, we definitely need action and decisions today and many of these products, decisions and designs around the cloud does need to happen. Life goes on… But things are still rapidly changing. As always.
So this brings us to the point. We are still in a cumulonimbus cloud of change. A working life in this cumulonimbus cloud of change is better lived recognising that its, again, a swiftly changing element.
I find that having this recognition in focus really help my work as someone that has to deal with cloud recommendation, decisions and implementation on an almost daily basis:
Don’t be too hard on yourself
If you find that you’re sometimes lost/confused/worried when choosing paths to take in the cloud. You’re not alone. It’s just the state of the “industry” (at least that’s what I tell myself :)).
Seriously, there are quite some domains to deal with from software development, to software finishing to production operations. All of these had been impacted by the cloud phenomenon.
Each of these domain can be approached differently. There are all encompassing paths such as PaaS, which, although of great value in abstracting complexity, comes with many flavours themselves (CloudFoundry, Open Shift, Deis, Heroku, etc.).
There are many very credible tools and technologies that’s crashed the party in your head (and the “hive mind” of your team) as well: hypervisors (Xen?, KVM?, Hyper-V?, ESX?), unikernels, rump kernels, deployment tools (Otto?, ElasticBox?, Spinnaker), containers (Docker?, Rocket?, LXD?) You name it! The list goes on..
When we go about this with a mind that change is in the air, we are less prone to analysis paralysis and more encouraged to action. It sometimes may feel futile evaluating how one PaaS does against another. We may be asking too much of ourselves to to make a decision based on textual information, conversations and quick demos alone. Deep dives are best, but it takes time. Meanwhile, the clock is ticking and we need something to go live with next week. You know what I mean… Which brings us to the next point.
Learn by executing practically
If we believe that the cloud encourages agile change (see this slide for attributes of the cloud that supports such behaviour), i.e. by allowing on-demand setup and teardown of resources and configuration that can be extensively automated, then the best way to find the best path for a certain project or situation may be by to just try it out within a controlled cloud environment.
“Action without study is failure. Study without action is futile”
This may be overkill, but how do we get a good, advised, honest opinion of one path vs another without actually giving it a shot and getting ourselves muddied in the edge cases, bugs and complexity that happens only by immersion through execution.
So, what I always find my doing is getting immediate needs sorted while scrambling on to explore optimistically better alternatives by giving those a shot with the time pressure relieved.
Create and destroy!
“It’s better to create something that others criticise than to create nothing and criticise others. Go create, have fun!!”
Of course, I write these on my context and constraints, which definitely isn’t universal. I.e., you may have a fully managed PaaS and isn’t too bothered about the life of your application beyond the master branch merge or a release tag. I do think that the approaches there are out there with the cloud today is immensely diverse, beginning from the service models (IaaS, PaaS and SaaS), and that is a good thing. I expect to see better ways emerging from this cumulonimbus cloud of creative destruction. Let’s explore, create and destroy! Will love to hear from you.
Find me on Twitter
=================OK, here’s where I peddle what I’d been working on this year: Liquid Sky (with @richardkoh and co.). As you deal with this dynamic ever changing cumulonimbus cloud, Liquid Sky helps you communicate and manage the cost of your various cloud vendors.