# PaaS, or "Platform-as-a-Service" explained

In this article, I introduced the concept of "Platform-as-a-service" as being: a cloud hosting solution thanks to which a developer will be able to deploy an application without worrying about the infrastructure used underneath the platform provided.

Which is a simplified definition that is perfectly valid, but...

But if we stick to this definition, it's hard to grasp the advantages and constraints of this solution. So that's what we're going to do today.

How PaaS works

"Platform-as-a-Service" is a hosting solution that deploys code for you.

You don't have to deal with the machine, nor the operating system, nor even the runtime environment (web server, proxy, virtual machine like the JVM, etc.), but simply with your application, your code.

Everything is managed for you. Or almost.

It's when creating your "application" on the hosting service that you'll be able to define your requirements:

• The language used
• The number of machines and their capacities
• The location of the datacenters
• The associated domain names
• The environment variables

And you can even attach modules to it (often third-party services) for log management, sending emails, data/file storage, etc...

Advantages

Besides the obvious simplification in terms of deployment, since you don't have to worry about your runtime environment, the main advantage lies in the scalability of your application.

Horizontally (more machines) or vertically (bigger machines)

Whereas on more "traditional" hosting (a VPS or dedicated server, for example), you would have had to order a new machine, reinstall your environment, migrate your application's code, configure a load balancer to manage the load, etc...

Changing the scale of your PaaS-hosted application amounts to clicking a button, waiting a few seconds for the redeployment, and that's it!

The icing on the cake: deployment can be done directly with Git! You add the application's remote at the host, do a git push, and the application deploys.

Constraints

For your application to work properly, it needs to be "stateless." This means you shouldn't store data or files inside or alongside your application.

Otherwise, on the next application update, everything disappears!

This is a prerequisite so that the host can easily migrate your application from one machine to another, or clone it to deploy it across several different machines.

The second constraint is that most hosts don't give you the IP addresses of your machines (which makes sense, since they can change at any time). So you'll have to make do with the domain name provided by the host, or your own custom domain name.

This covers 98% of typical use cases, but if your other systems require a fixed IP to whitelist, or for A DNS records, then this becomes a constraint to take into account.

Working around the constraints

The solution to work around the "stateless" constraint is to use a database external to your application, a service often offered by the PaaS host, which also allows you to scale your database, as some services support this.

If your application needs to store files at runtime, then you can use an external storage service like S3 (Simple Storage Service) by creating a bucket and using the available APIs, or by directly mounting this bucket as a virtual file system using solutions like S3FS.

These are of course examples of solutions to these constraints, but far from the only ones possible

Which hosts

More and more hosts are offering the PaaS solution, notably the American cloud giants:

• AWS Beanstalk
• Microsoft Azure
• Google App Engine
• Heroku

But we also have our own French PaaS cloud host called Clever-Cloud! And it has nothing to be jealous of compared to its American counterparts, the service is amazing, I invite you to try it out: https://www.clever-cloud.com/