Why we need to think multi-cloud as we do multi-platform

Business are rushing to the cloud today, and this scenario must be considered strategically when we do our choice. To understand better the landscape, and get some strategic vision, I want to start this post telling a personal short story.

A dilemma of many years ago

When I completed my master’s degree (in Italy, at University of Pisa), I tried to plan my career, and I felt I had to choose which environment to focus on. At the time there was basically only one viable commercial choice for a safe bet on a careers: PCs with Windows. I mean, it was 1994. OS/2 did not pick up, Windows 3.1 was the king, everyone was coding GUIs with VisualBasic and Access.

But at the University, I was also exposed to the primordial Internet. It was even before Netscape was out (the leading browser at the time was Mosaic), when the only TCP stack available for Windows was Trumpet Winsock. Even if everything was so primordial, I had the clear feeling it was going to be huge.

So basically I felt I had to choose between a career on coding commercial applications (where the easy money looked to be) or risk everything a career on something new and fascinating: Internet.

The only practical way for a penniless student to work on Internet at that time was to buy a PC and run on it the open source operating system Linux, with native TCP-IP (something that Windows 3.1 didn’t have at the time). where you could run ncsa-httpd (it was the standard before apache) and other Internet software like bind (the DNS server), sendmail (the email server) and more stuff (do you remember Gopher?).

In practice, the choice turned out to be: Windows or Linux. I spent weeks thinking to it. Which one should I pick for my career? I will not tell you now what I decided to do. Will tell you later.

A dilemma of today

Now, let's move fast forward to today. I have an application, and I have to deploy it. A few years ago I would have rented a server. Today, I am going to deploy on a Cloud. Problem is, which cloud?

While picking a server was only a matter of price, and you had only to select a number of well known parameters (CPU, bandwidth, memory), with the cloud, things today are very different. There is a huge complexity deploying on a cloud. It is why the “Devops” job today is so hot!

The 500 pounds Gorilla is AWS. More or less as Windows was the way to go in 1994. But there are a number of things where AWS is not just right. For now, I am comparing it with what is offered by Google Cloud (the Linux alternative of today)

First, I will package my application using Docker, but running containers on AWS with ECS does not look optimal

Furthermore, I want to manage container running Kubernetes on AWS but running Kubernetes on AWS looks pretty expensive. The main reason is: AWS cheapest virtual machines receive a limited amount of CPU credits per hour, and Kubernetes is pretty CPU intensive. So you need to buy at least 3 M3 instances at 35$/month. Not huge but when you go to pay 105$ / month for a total of 12GB of memory and 3 virtual machine, while a dedicated physical server with 64GB costs $50, well…. Renting a physical server looks a better option.

Not surprisingly, Google cloud is much cheaper for Kubernetes, offers larger instances with more CPU and does not charge for the Kubernetes master. It also offers easier scaling for Kubernetes while scaling on AWS is still (as per today) a manual process.

However not everything on Google Cloud is fine. For storage I still prefer the simplicity and availability of tools offered by Amazon S3. Furthermore, I will need some instances with GPU for machine learning. Those instances are not available in Google Cloud while they are in AWS. AWS offers a lot of other services not available on Google Cloud

The dilemma AWS or Google Cloud looks a bit like my old dilemma: Windows or Linux? But the situation is even worse: Google Cloud and AWS are not the only available options. I have not even explored the options offered by Microsoft Azure, IBM SoftLayer, RedHat OpenShift, Oracle Clouds and more...

How I solved my old dilemma (Windows or Linux)

The heading picture of the article shows my current desktop today. I actually do most of my coding work on a MacBook Pro, like many other developers today. But I keep everything shareable with my Surface tablet running Windows 10, and I test the code I develop on another laptop, that I use as a server, with lot of memory and running RedHat Linux. You can also see I also have an iPad where I do most of my web browsing (and gaming), an Android phone and a Raspberry PI. And I actually use all of them!

How can I keep using all those systems today? Simple: I solved my dilemma many years ago going multi-platform. I was an early adopter of Java (as early as 1995) and I has been using it all the time. Today I write most of my code in Scala, based on the portable Java VM, producing UI in Javascript for the what I like to call the “Javascript VM” (or the browser VM). I actually write client code in Scala.js producing JS just to be an “one-language” man, but it is not important. If you write Javascript manually it is fine, too.

What is important is all my code is always portable, and after 20 years of Java and Javascript development I cannot even think it can make any sense to write non portable code.

I have not settled on any operating system, I pick the one is the most conveniente for my work. Mac today is fine for development because it is still very usable and includes a good Unix environment. Macs are by far the best hardware money can buy. This is true and not a hype: I have 6 dead PC in my closet, and 3 macs, all of them still working! But I do not dislike Windows. While I love iPads, the best tablet for more work intensive today is actually Surface. And of course, I have a phone (2 actually): an iPhone and a Samsung Galaxy.

Whatever I do, I develop on a platform but my work it is not done until it also runs properly at least in another one. Usually I code on Mac, then I test on Windows. If it works usually I can deploy them safely on Linux.

How we have to choose a cloud

Based on my experience, the we have to choose a cloud not choosing it. Choosing Amazon AWS today today looks very similar to settling on Windows in 1994. The landscape will change quickly and our application will be stuck to one vendor. Enterprises with still IBM mainframes around know very well how expensive this choice can be. We have to focus on multi-cloud technologies starting from the day one.

There are already multi-cloud technologies emerging. Docker is one, for example. Another is Kubernetes. But the real problem is avoiding to select a multi-cloud technologies and then bind in some way our application to a cloud.

In the old days of Java there were a lot of people writing Java code then linking them to a Windows-only native code. The need to go “pure” Java was a discussion that many dismissed as “fanatic" and instead it was the core of the Java platform.

Today, I see people using Docker but then building their stuff with custom services of the cloud, binding themselves in many subtle ways to a cloud than another one.

What I instead recommend is to build always your applications in a way that can be deployed in multiple clouds with the same code base. It is not easy. Pressure is always to deliver quickly and “since we are using AWS why should we case of Google Cloud”?

The simple practical rule is: develop on a cloud and deploy on another. The point is: developer should not take for granted the environment is immutable. It is not. It changes very quickly and when it changes you are in trouble. Think to the "Parse" debacle.

Conclusion

Bottom line: there are already multi-cloud technologies available. Docker and Kubernetes are two, but more are emerging. I am watching closely the OpenStack for example. But whatever you do, thinks that things move quickly, and can be a lot expensive to move from a cloud to another.

It is generally not more expensive going multi-cloud, but it would mean to sacrifice some cool feature your Cloud provider offers and others do not. Usually, rarely they are really important, and there are always alternatives. But strategically thinking it will be the best bet you could do.