Why is public cloud potentially a bad idea from a programmer's perspective?

Cloud may be a developers best friend, but it can also be a programmer's worst enemy. Why? And what can we do to protect ourselves? Here we enter into the debate, and explain how this all links back to some fundamental questions about values...

Concern 1: Is public cloud consistent with zero trust?

Amazon does a pretty good job of encouraging zero trust development in its cloud.
However, they also encourage you to use their 'easy black box security solutions', and ask you to trust 'them'.  The cloud is counter-intuitive if zero trust is your thing. If you want a chain of custody, you don't give it to a third party — 'end of'. So if security is a priority, your programmer will tell you you shouldn't delegate that. Regardless of the commercials.

By its very nature, the scale and convenience of public cloud therefore makes it a more attractive target for bad actors — and, as we know, there are lots of those about. Recent financial thefts in the crypto industry for example have been for eye watering amounts ($1.4 billion this year alone)! Bad actors spot a vulnerability and install their software, mining your resources to make bitcoin, at your expense. Meanwhile, ransomware also gets a lot of airtime. Here bad actors hijack your data, which can lead to downtime and financial demands. Many will recall the whole of the UK's National Health Service being closed for 48 hours by ransomware.

Now that's not to say these threats don't exist outside the public cloud, but the cloud can increase your risk of exposure to vulnerabilities, and breed a complacency that is bad for security.

Concern 2: Are proprietary APIs and vendor lock-in a good idea?

The cloud came into being thanks to the open source community and some pretty cool Linux wizardry. Built on top of Linux instances, the abstraction layers and APIs on which the cloud is founded provide the perfect platform for developers, but this in turn has inadvertently turned it into the biggest proprietary operating system on the planet, where the network is the computer.

As the wise Kyle Rankin once said: "Left unchecked, this proprietary operating system has the potential to undo the achievements open source software has made in the past two decades".

So proprietary operating systems and services aren't dead. Far from it. They've just pivoted to the cloud.

And - as we learned from Sun Microsystems (aka Sun) and the Solaris operating system it created - if we start to move way from open source values, things can get pretty murky, pretty quickly.

Sun was an American tech company that created a proprietary UNIX operating system called Solaris.  They also gave the world the Java programming language, Scalable Processor Architecture (SPARC) and the Zettabyte (ZFS) file system, contributing significantly to the advancement of several important technologies. In the sphere of open source software they made contributions to the development of MySQL (a relational database management system (RDBMS)), released StarOffice (the predecessor to the popular LibreOffice) and released the source for many of their projects under their own Common Development and Distribution License (CDDL).  Most famously, they coined the phrase “the network is the computer”, and today's ecosystem of apps and micro-services certainly proves they knew what they were talking about.

Unfortunately Sun was also incentivised, as a proprietary UNIX vendor, to ‘lock’ their customers into their ecosystem.  This usually took the form of providing additional libraries and functionality that their competitors did not, or implementing subtle differences in the functionality all of their vendors provided, in the hopes that developers would create solutions that depended on the systems only Sun sold. Such dependencies kept customers from switching vendors as the additional expense of porting key applications between nominally compatible UNIXes often negated any cost savings.

Ultimately it was the development of successful, operating system-agnostic, open-source libraries and tools which hid the implementation differences between the numerous offerings that broke the ‘lock-in‘ of the big UNIX vendors. This allowed customers to migrate freely between vendors and choose the most cost-effective solutions without penalty.

Today we see that same pattern starting to play out once more in the cloud space with each of the big three offering features and solutions in ways just different enough from one another to make migrations painful exercises that might tie up your development department for months. Of course, we already see the rise of solutions that sit between your applications and the cloud providers and abstract away the differences to create a seamless multi-cloud experience, so the cycle continues...

Concern 3: Does the one-size-fits-all public cloud really fit everyone?

There are very few customization opportunities in the public cloud. While this might work for companies with simple network architecture, for companies with complicated network architecture the opportunity to tailor this architecture is seriously lacking — with an inability to make the cloud provided services fit the use-case. Anyone who's tried to run a layer 4 DR mode virtual service in Azure VPC knows that disappointment....

Not a problem for those not worried about security. But for those such as finance institutions and hospitals who are subject to stringent regulatory and compliance requirements, putting their critical data in the public cloud just isn't worth the risk.

So how can you be secure — and yet avoid vendor lock-in?

I'm a strong believer in 'zero trust', and understanding your own security profile, so that means trying to avoid 'easy to use proprietary black boxes'. If you do use proprietary services then make sure you 'trust but verify' with your own security testing. Which can be difficult when you can't see the code! Which brings me to my main point that Open Source solutions are by far the most secure, powerful and easy to verify choice you can make.

But then we get back to cost, verifying an open source solution yourself can cost more than trusting a proprietary public cloud vendors black box. Which is why a lot of people pay a lot of money for vendor supported open source i.e. open source tools tied together in a battle tested appliance configuration and used by many customers who do many security tests.

At the end of the day, many confuse open source with free. Open source values mean code can be freely inspected and therefore gives developers the "freedom" they need — but this doesn't necessarily mean it comes "without cost". So although the terms "open source software" and "free software" may refer to similar sets of licenses, the values that get you there are very different. As the open source community explains: "open source is a development methodology; free software is a social movement."

At Loadbalancer.org, we don't obfuscate our use of free and open-source software. Unlike the big public cloud providers, we invite examination of the underlying software and configuration files. This makes it easy for our customers to migrate to and from us (hence the many users currently migrating to us from Snapt). And yes I did say 'from us' — No vendor lock-in here!

We believe that by valuing open source, and not getting seduced by easy to use public cloud black boxes that are a potential security risk and as discussed in many other blogs already  — almost certainly cost you far more than you thought in the long run :-).