As I’m currently thinking of creating a new app which requires a cloud service (or at least an online service 24/7), I thought about what are the long term constraints I want to have when signing up with a cloud provider. These are the topics to consider IMHO.

First things first

There are many cloud providers, and they all come with different services, different capabilities, different prices.

The most obvious difference between a standard hosting and the cloud is that all providers have different data centers in different locations. The different locations are great to be able to serve your customers with lower latency, but it may not be a priority for you at the beginning. Being hosted at home may be an option in the short term. In the long term, if your company is a success and you have thousands of employees, you don’t want to rely on an external provider, you want to have your own data centers.

All the cloud providers also provide a free tier, meaning that they can provide you with some free stuff, like any good drug dealer would. I’m actually using this metaphor on purpose, you will see why later. The free tier is very great to try things and test things. Using a small micro instance is great to see if a service works as expected in your ecosystem. It won’t be enough to performance test it, of course, but at least you can see if all the connections are working and if all the APIs are sound.

Keeping services small

It’s very tempting to have one service doing everything for a backend. It’s even difficult sometimes to split it in pieces, functional testing may still require several services talking together (to test authentication, you need to create users, which is another service of the backend, and to test the latter, you need the authentication layer as well).

Let’s say you need to save files on a server, and you use one of the MongoDB facility, gridFS. It’s a good idea to store this in another database than your user data, with a different user. At the beginning, you will probably use the same instance to store both of them, but having them in different databases will allow you to split them to scale them differently, and of course if you want to change one of them, you don’t have to impact both of them anymore.

And if your service needs to be changed because one of its dependencies is not maintained anymore, it’s less work to do if the service is small.

Don’t get locked in with one cloud provider

This is actually trickier than it sounds. They all provide some facilities that are only available with them. It may be their ML services, but also their serverless tools.

What happens if they get dropped? Google is known to kill very popular products ALL THE TIME. What happens if you find a better deal for your services with another provider?

Only use services that you can easily port from one cloud provider to another. Select cloud solutions that allow you to use different workflows (for instance, there are cloud services that provide you the option of running Tensorflow, scikit learn… instead of locking you in their own small solution).

This is why I talked about drugs before. These services are easy to use, but they lock you in for all eternity. Beware of them! Choose carefully with a long term plan.

To be continued

My adventures in the cloud are just at their beginning, stay tuned for more episodes!