Tech Independence: the Case for Excellence
Let’s face it: nowadays big cloud providers have freed many companies from hardware. With cloud instances and object storage, CTOs don’t have to worry anymore about hardware failures and redundancies.
But the likes of Amazon, Azure etc did not stop there. Most providers also provide plenty of extra services (container orchestration, hosted database, “serverless” features such as AWS Lambda etc) in the hope of better helping their customers, but also vendor-lock them further.
Every once in a while you encounter an architecture problem and it is tempting to rely on just that one proprietary feature of your cloud provider (object storage webhooks, custom triggers etc). But giving in to this temptation has consequences.
When you look at the bigger picture, many will say that cloud providers may wiretap you for the US government, that you should always have total control on your data… But let’s be honest here: most of us are not a prime NSA target and even if you are, don’t think you’re safer with your own dedicated servers. You’re most likely just fine on the cloud with a VPN and basic best practices. The risks lie somewhere else.
Make no mistake: in the era of giant cloud providers, unless you’re Fortune500 your business is peanuts to the big boys and the risk of being a collateral victim of their corporate strategy is real. OVH shutting down deliveries during 3 months and raising prices by 30% in 2014, Apple enabling ad-fighting tech by default on iphones in their war against Google, Google discontinuing Google Earth API support to make place for a new product… Those things happen every day. Being locked with 1 provider comes with real risks.
Using cloud providers core features (cloud instances and object storage) without all the extra services brings you most of the cloud benefits, without being vendor-locked (sure S3 API is not the same than Azure but a migration would be most of the time a matter of days). It’s not about rejecting the cloud, it’s about profiting from it without surrendering to it. Of course, with freedom comes responsibility and you’ll probably have to manage your DB and orchestrate containers yourself.
So far, we’ve been talking about costs and benefits of tech independence. But just framing the problem like this would be missing the point. Tech independence is not only about costs and benefits, it’s a way of life. The higher in the stack the services you outsource, the more you delegate important architecture decisions to 3rd parties that know nothing about your business. Solving problems in a generic way that works for everybody can mean 2 things: either it’s a technological breakthrough, either someone made some kind of middle-ground trade-off with existing tech. Let’s face it, most of cloud providers extra services fall inside the latter. By subscribing to this trade-off, you’ll probably have something that works OK with a lot of red tape here and there.
You may use AWS lambda functions with dirty hacks to circumvent execution time limitations. You may use hosted database services with dirty scripts to install the business-specific add-ons you need (ex: postgis with postgres). You may use hosted kubernetes for scalability and add some extra bloat to make it work nicely with your VPN solution.
Even though I’m not at all a fan, the approach of using cloud providers extra services to their full extent and trying to fit your system in is less risky. That’s what standards and processes are about: it’s less risky in that in binds you to the average. You won’t suffer epic fuck-ups. But you won’t enjoy spectacular wins either.
In some organizations with a lot of turnover, where people mostly don’t give a shit, outsourcing as many things as possible can make sense. But one CTO should always wonder: am I really in that situation? Should I settle for average? Or should I put my ass on the line and take the risk of excellence?
Published September 18, 2018
Originally published at fruty.io on September 18, 2018.
