Is your application cloud-ready? 3 questions

This is a recurring question in our daily routine at Getup; there is some confusion about whether or not it is necessary to make modifications to the code and software architecture to migrate and run in the cloud.

The answer to this question could be "it depends", and it wouldn't be wrong.

Let's assume your application doesn't pass the 3-question test below, but you want to migrate anyway because, even if your application is not Cloud-Native, there are still benefits to be considered (provisioning agility, improving availability, outsourcing infrastructure management, …). So, even if you don't achieve all the benefits, in this case it can still make sense to migrate as is.

Cloud Native: 3 questions

However, if you really want to take advantage of Cloud-Native features such as automatic scalability, better software rollout and rollback cycles, the use of CI/CD, and get a better return on investment, then you need to answer yes to the 3 questions below.

1. Is the data separated from the code?

2. Are authentication sessions stored centrally?

3. Are configurations stored using envvars?

Data is separated from the code

By data, I mean any type of persistence. You need to separate the data from the code (images, uploads, pdfs, …). Running in different environments will allow you to scale the application and distribute the workload, improving performance, reliability of the environment, and savings, allowing you to provision resources dynamically and only when necessary.

A very common option is to use Object Storage to save persistence, for example Amazon S3 or Azure Blob Storage.

Sessions stored centrally

One of the advantages of moving an application to the cloud is being able to scale or grow horizontally and balance the load among servers. In such an environment, users can, and probably will, land on different servers.

To avoid authentication issues, it is recommended to store it in the browser, in a database, or in memcache.

[Update] TOP Contribution from Elton Minetto from Coderockr

When we launched the new version of Planrockr, we chose another path, which is to have no user session. We are using JSON Web Tokens, and this way the application becomes even more scalable and easier to migrate to the cloud, use containers, and achieve the 12 factors.

Configurations by envvar

It is common practice for developers to use different environments to develop, test, and run their application. Each environment tends to have its quirks, such as different numbers of distinct components (database, cache, storage path) and specific configurations — for example, a stronger password in production than in development.

With this in mind, it is important that these variables can be easily changed, as they are part of the system configuration.

A scalable application should store these configurations in environment variables, with its data accessible at runtime.

Bonus: Does your application have a good architecture?

Well-designed applications with good code run well anywhere. The same goes for the opposite: if your application does not have a good architecture and has performance bottlenecks, consider resolving these issues before moving to the cloud, otherwise, you will only be moving the problem to a new address.

Examples of tools that can help are Newrelic and Opbeat.

Certainly, there are other points to be considered, but these are the main ones and a good starting point.