At several recent meetings people have asked “Why is PaaS is better than shared hosting or Virtual Private Servers (VPS)?”
Shared hosting and VPS have been around for a long time and served us well, so why change something that works? Well, imagine you are driving an Audi A8 from 1997…wouldn’t it be nice to upgrade your ride to the most recent version? Sure, it will cost you something, but it will be more luxurious and many manual actions will now be automated. We can look at PaaS in a similar way. It will cost you something to move from shared hosting or VPS to PaaS, but in return you’ll get a great deal of luxury you have not been accustomed to until now.
Here are five reasons why PaaS is a better solution.
1. Security (shared hosting)
With shared hosting, everything runs in one shared environment. Best case scenario you get your own system user and your application is slightly isolated. In the best case SELinux policies are in place to secure your applications. In many cases, shared hosting providers nowadays run a single Apache server to serve PHP applications for many clients. What could possibly go wrong? It’s just simple PHP. Well…you know…A LOT!
Sure there are (even prominent) PaaS providers who do not focus much on security. One possible example is multi-tenant databases. SQL databases have proven to be quite solid in this area, however, many newcomers (especially among the NoSQL crowd) do not have a proven record for such installations. Generally, for most PaaS offerings, it’s a question of money, not technology. By providing multi-tenant servers (application, database, etc.) the provider saves resources and thus money. This opens up a possible attack vector.
OpenShift strives to provide as secure an environment as possible. Security is one of our top concerns. Sadly we have frequently requested features from users we can’t put into production now for security reasons. OpenShift tries to be as flexible as possible and provide great features, but this cannot come by lowering the security of users.
So, what does OpenShift do? Well, as mentioned above, OpenShift does not provide multi-tenant servers. Yes, the cost is slightly higher, but it closes a possible attack vectors that could affect users. Whenever you deploy to any gear (server), it’s yours alone and no one else can access it. This also provides OpenShift with the possibility to expose per-user configuration for the server. For example, take the JBoss Application server. The whole standalone.xml file is accessible and editable by users, and thus the user is in full control of the application server. OpenShift could share one instance for many users, but isn’t this approach better?
All processes deployed by a user on OpenShift are isolated in something that we call a gear. It’s a container where your servers are isolated from those of other users. This provides you with higher security because programs run by one user cannot interfere with any programs run by other users. Even though these processes are run on a single operating system, they cannot see each other.
Every container has restricted system resources it’s allowed to consume. If a process misbehaves in the container, it can’t go outside the container to affect other containers. OpenShift attempts to temper the process (eventually kill it) so it does not steal resources from other processes.
Finally, all files are secured using SELinux with a quota to prevent containers from consuming all the disk space in the system. Every container has its own enforced quota. SELinux isolates file-system resources from users, so data from one user cannot be seen by any other user on the same system.
PaaS systems, compared to shared hosting, provide a higher degree of security. In my experience, when shared hosting provides this kind of security, it’s more of a platform than shared hosting. You should keep a close eye on the security-related aspects of your PaaS system. Do not believe marketing hype and do your own research. Security (which goes hand in hand with resource allocation) is one of the most important considerations when moving to production. Do not underestimate it.
As I usually say, “There is no absolutely secure system. It’s just a matter of the resources the attacker can commit to the attack.” OpenShift raises the required cost of attacks again and again to give you peace of mind.
2. Multi-tenancy (VPS)
In the previous section I explained how multi-tenancy is bad and now I am listing it as a positive? Is this a contradiction? I don’t think so and I will explain why. I believe multi-tenancy at the application level is a security issue. If you believe multi-tenancy at the operating system level is a problem though, then you need to use VPS and that’s it. If you believe multi-tenancy at the hardware level is a problem, then you have to get rid of virtualization. Nowadays, virtualization is considered stable and secure. Operating level virtualization (containers) have evolved to the point where we believe they are secure too.
When OpenShift started, there was no standard for containers so we implemented our own. Now, there is Docker, which is globally accepted as a standard. OpenShift and Red Hat are committed to it. Docker is an intergral part of the next major release of OpenShift, but that’s still in the future. Today we use SELinux, cgroups, Linux quotas, and kernel namespaces to separate containers from each other. These technologies are battle-tested and secure. We believe this combination is secure and it’s why we use multi-tenancy at the operating system level.
Multi-tenancy at the operating system level provides resource savings. The density of applications deployed on one operating system is much higher when using containers, because you can reuse the same system with many of them. It’s like virtualization, but with applications instead of operating systems. With higher density comes lower cost.
PaaS saves you money by providing a higher density deployment environment compared to running a VPS for every application. But I can hear you arguing already…”I can deploy my own containers on my own VPS and get the same benefits”. Hehe, got ya! Right? No! Let’s move to the next point.
3. System management (VPS)
PaaS bring the benefit of outsourcing system management. PaaS manages the operating system so you don’t need to. You just use it, as a service. Well, if you are curious dig into the source code and see for yourself how the platform works. What? Did I hear you correctly? Your platform is not open source? Please, do yourself a favor and move to one that is.
Yes, you can run your own system, manage the containers, and be in full control… but is it worth the time and energy required? A lot of development effort is going into different PaaS systems that are open source. I can only speak authoritatively about OpenShift, to which you are invited to contribute. Don’t like something? Want to see something implemented? Send OpenShift a pull request and you can get it. OpenShift is very open to contributions and provides a very permissive license (Apache2) so everyone to benefits from collaboration.
But back to system management. With a VPS you need to manage and maintain the system: update packages, apply security patches, etc. None of this is needed with PaaS. PaaS comes with pre-configured environments, which you are free to change or reconfigure, and handles all the aspects of managing them. You as a customer have only one task–developing your application–the platform takes care of the rest.
Here’s how simple it is to deploy a PHP application with OpenShift:
rhc app create testapp php-5.4 mysql-5.1 cd testapp # copy my code here git add -A . git commit -m "Adding my application" git push
That’s all. Now you have a running application in the cloud. How difficult would this be with a VPS? I will leave this to you as homework, but I am sure that even with some configuration management tool like Puppet or Salt, it would be much more complex than this. And don’t forget, you still get the benefits of multi-tenancy and security.
Let’s look into the future of your project. You’re starting out small now but maybe you’ll capture attention and become popular. Your audience will grow, and you will need more resources for you application. How simple is that?
Shared hosting requires you to move to bigger boxes and scale vertically, with your provider supplying bigger and bigger boxes until there is no more room for growth. Not a bright future, right?
With VPS, you can get bigger and bigger boxes and again scale vertically until you hit the same problems as shared hosting. With VPS you can also scale horizontally. You surely know how this goes –add a load-balancer and sync the files. Hmm, well, now the database too, so let’s set up some replication. Oh snap, let’s do some sharding. Oh, I need some shared storage. And on and on it goes. You will hit the system configuration problem–do you really need or want to handle all this stuff yourself?
Most PaaS systems allow you to scale your application with a command line tool or web interface. The platform deploys and configures new containers, starts the application, and reconfigures the load-balancer to make use of the new deployments. With databases, the platform configures the new node for your system, reconfigures the cluster, and syncs your data. Keep in mind all this done for you by by issuing a few command like “scale up” or “scale down.”
Some platforms (like OpenShift) auto-scale your application. You set the limits on how the platform utilizes your resources and it does its best to scale your application up and down to accommodate incoming load from users. With OpenShift, you set scale up and down events specific to your needs.
5. Encourages Best practices
I believe encouraging best practices is the important aspect of PaaS. It makes you think differently and encourages you to build applications with scalability and elasticity in mind. Sometimes this takes more time and increases complexity, but it saves you pain in the long run.
If you read the previous sections carefully, you’ll notice I never mentioned vertical scaling for PaaS. This was intentional. Vertical scaling is something that should be avoided on PaaS (or as it’s fashionable to say now — at internet scale).
File systems are one of the most challenging things to scale. OpenShift allows you to use the file system for persistent data if you create a non-scalable application. This makes sense–if you do not scale the app, you do not need to scale the file system–ergo, there is no problem. Once you enable application scaling things change.
Imagine deploying your application four times with a load balancer in front of it. Let’s say you have sticky sessions and every request goes to the same node. Whenever a user uploads a file it’s written to a file system. With the sticky sessions, the single user sees a consistent state. Without them, even the same user will see inconsistencies since a request could be sent to different nodes and the file would only on one of them.
One solution is a shared file system. For a long time we’ve have NFS, and now distributed file systems are all the rage with Gluster (Red Hat project) and Ceph (recently acquired by Red Hat). These systems allow us to have a consistent file system distributed among the nodes. There are reasons (currently) why these file systems can’t be used with PaaS without experienceing adverse performance, security or both. So, how can PaaS be better with these limitations?
PaaS is better because it encourages developers to think and work differently. There is no need to save a file to a file system, you can use external service like S3 by Amazon and outsource the file management to a specialized provider. Service like this can handled storage magnitudes larger than you’d ever want to manage–TBs or PBs–while also giving you integrated CDN providing a better user experience. With this approach, you’re closer to a service-based architecture and your application is more environment agnostic.
Hopefully I’ve managed to persuade you to try PaaS (preferably OpenShift ;). With OpenShift I am confident you will discover the benefits for yourself. In this article I covered only a few benefits I thought were most important. I wish you good luck choosing your next deployment environment.
- Sign up for OpenShift Online and create an app.
- Promote and show off your awesome app in the OpenShift Application Gallery today.
Stay informed and learn more about OpenShift by receiving email updates.