What we did in the past 2 months on the Cloud was unimaginable just some years ago

What did we do recently? We launched an app in record time. Yes, what’s the biggie here? To some, it is already a way of life, it is already happening in the hyper-scale public cloud space in recent memory. But to some, it is still like experiencing the personal computer for the first time — the sheer potential of what lies in front of you and the endless possibilities it can bring to you.

Not only did we launched an app in record time, we did it with very little planning and worry about its underlying cloud infrastructure and cost. In the not-too-distant past, many of us will still recall the amount of grief that we had to undergo to plan, cost, budget, procure, ship, setup, manage, upgrade, fix, patch, secure, monitor all the underlying IT infrastructure of an application (or suite of applications). Those agonizing days are numbered for a majority of IT professionals in the industry, and another one is also looming in the not-to-distant future — read: Amazon’s cloud boss told us something that should terrify a $140 billion industry.

Call me a fanboy of hyper-scale public cloud, whatever …, having lived through that revolution in the Pacific Northwest since 2006, I firmly believe that public clouds are here to stay (unlike 3D TVs :)) for a long time. And what was really striking to me, and my product management and engineering teams, was that most of our meetings and discussions were focused on our app’s experience, usability, adoption strategy, legal/regulatory compliance, customer support handling, etc. We have essentially reduced the amount of time we would normally spend discussing in numbing excruciating details about the underlying hardware and software infrastructure that we need to plan, cost, budget, procure, ship, setup, manage, upgrade, fix, patch, secure, monitor.

Remember all these: plan, cost, budget, procure, ship, setup, manage, upgrade, fix, patch, secure, monitor? I believe the hyper-scale public cloud providers like Amazon Web Services, Microsoft Azure and Google Cloud has largely taken on the burden of “……..procure, ship, setup, manage, upgrade, fix, patch, secure, monitor” but what about “plan, cost, budget”?

Planning

You see, our team believes that planning for our application’s architecture and the right set of public cloud services to use should no longer be an upfront massive paper exercise of icons, and boxes, and lines, and arrows, and labels which frankly is the antithesis to enterprise agility and responsiveness to the market. We have been taught and grilled into us that we are building architectures, castles, forts, skyscrapers, bridges, that must stand and be standing for years and decades to come. That thinking and approach will no longer make sense — but let’s be honest, it goes against every single fiber of what we know about building software applications in the last few decades.

So how are we thinking and approaching building software applications in the cloud now? One word: Liquid. We think “liquid”. We approach with “liquid” in mind. What does this mean? Let’s use water as an example. It is malleable yet powerful, it can take the shape of any container and stay in one place, and it can also travel for long distance through many forms of vessel (rivers, lakes, waterfalls, etc). We think architecture is now liquid, it is now about micro-services and having them scale out and back in according to real world demands, and similarly for the underlying cloud services. We can talk about “serverless computing” another time :)

Planning is now more of ensuring a thoughtful micro-services architecture approach that can be updated continuously without incurring any downtime or regression.

Cost/Budget

Similarly for costing & budgeting, our team believes gone are the days that we need spreadsheets upon spreadsheets of infrastructure costing, sizing each component to what might be needed to support the applications. It is never good to under-size the underlying infrastructure, and it is universally embarrassing to ever commit such hideous crimes of under-sizing, so legions of IT professionals have always taken the safe bet of sizing each component to handle 70% of the maximum load with 30% capacity to spare! Imagine the amount of idle capacity in all the data centers infrastructure — we are so glad that hyper-scale public cloud providers are taking away that nagging burden away from our collective IT operations consciousness.

Let’s now talk about hyper-scale public clouds, and I appeal to your child-like imagination for the following analogy to work. Imagine you have a house and there are 10 faucets in the house, some are tiny ones, some are regular household faucets, some are big gushers that you can attach a fire hose to. Making sure that they are turned on as they should or turned off as they should or constantly dripping as they should, is relatively easy. 10 faucets, that should not be a problem to keep track.

Now imagine, you now have 20,000 such faucets and to complicate the situation more, some have plain water flowing from them, some have beer (I hear a collective cheer from the background :)), some have fruit juices, wine, champagne … the combination of this very interesting “utility” has grown in complexity exponentially! This is akin to our experience with hyper-scale public clouds. It is a wonderful world, but it can also be treacherous if we are not mindful of what are the right “faucets” to use, and when and how much to use them.

All of a sudden, we are caught up in this wonderful spectrum of choice versus control, and costing and budgeting of our use of public cloud resources become not so exact as we would like it to be. Now, the natural instinct is to try and brute force control it and estimate to some crazy Nth degree to get an accurate costing of the public cloud resources we need, and also the budget that we should ask our bosses for. We decided that it was a fool’s errand and turned this whole notion of costing and budgeting on its head, and approach it differently, completely from the left side, way beyond out of the box.

The Approach

We decided to build a public cloud service to turn this whole notion of public cloud costing and budgeting on its head. We asked ourselves — how do we budget for our water and electricity utilities? We normally don’t! We get into a new house, plug in our appliances, take our showers, water our plants, figure things out when the monthly bills arrive and adjust accordingly.

All of the above was our technical insight. It wasn’t born from some conventional MBA approach of figuring this out. We know that we will never create a great product, disrupt this industry that we play in or transform the way we conduct our business, if we gone about just spouting “let’s build what our customers want”. We didn’t want to just give what our customers want, we want to give our customers something that will solve an existing problem elegantly and EVEN MORE — something that our customers don’t know yet that they want!

So we created a public cloud service — code named Project Liquid Sky — where it would crunch through our public cloud bills daily across all our various cloud projects (we had 20+ of them) and how much we were spending in each project and what were the public cloud resources being spent on. Here is the best part — Liquid Sky would also enable all our DevOps engineers and project leaders, to message each other and collaborate with each other on the spend graphs that Liquid Sky displays. And to boot, we threw in Slack integration for our teams to continue using our favorite team chat/DevOps tool, and also a Slack bot that anyone can interact with to find out their public cloud spend.

We fed every single one of our public cloud projects into Liquid Sky, and before long, our institutional memory of past and present public cloud projects and the cloud services that were utilized is now codified inside Liquid Sky. With this, two amazingly things started to happen. One, we no longer need lengthy, soul-sucking meetings and reviews to cost out our public cloud projects. We simply refer to our rich “library” of past and present public cloud projects, get a good gut sense and plug in our estimated budget into Liquid Sky and we get right to work in spinning up the public cloud resources for our projects. Agility restored! Two, we can now address cost overruns, anomalies, unexpected spikes, “orphaned” cloud resources, using Liquid Sky’s capabilities to watch over our public cloud projects and also have our engineers collaborate and chat directly on the spend graphs in Liquid Sky.

What’s Next?

We think it is too good to just keep Liquid Sky to ourselves :) We decided to introduce Liquid Sky to the world — https://liquidsky.io because we believe that something that has helped us so much would be useful to a lot of enterprises out there who are using hyper-scale public clouds. We have open it up for a limited public preview and any project team who is using public clouds like Amazon Web Services and Microsoft Azure can sign up for a free trial. We would love your feedback and also for you to interact with our Liquid Sky development team, and if you prefer, through our @liquidskyusers channel on Slack too!

Looking forward to seeing you in Liquid Sky!