I think the basic concept to understand is that of the 'dyno'. Although a term from the Heroku platform, I believe it applies to most of the other platforms too. A dyno is a container (sort of like a VM but without hardware virtualisation, see LXC or OpenVZ) that isolates system resources. You can have multiple dynos on any given server and you can have lots of servers. Each dyno contains the entire environment needed by any given app, so it'll contain the specific binary version of ruby or node for example and it'll also have unique copies of all the dependencies, managed via bundler or npm for example.
Scaling your app simply means having more running dynos that are load balanced by a centralised load balancer used across the entire platform. So yes, interestingly there is a lot of duplication of the code base.
Services, like databases, are managed on their own separate servers/clusters and allow multiple connections and can be scaled/sharded separately from the dyno farms. Therefore they can be monitored, maintained, upgraded, etc, separately as well.
I'd personally prefer to not adopt Heroku's nonsensical superhero terms, since we already have common terms for these things that make sense -- application containers, applications.
PaaS is "platform as a service". A way of automatically deploying, updating, and managing applications inside of application containers running on a cluster of machines, using either processes, virtualization, or OS-level process containers.
Amazon BeanStalk does this for Java by using Tomcat running in a EC2 VM, and exposing the servlet interface such that one can deploy Java webapps directly to BeanStalk.
Google App Engine did the same thing for Java, and with some custom packaging for Python.
The whole idea is to get rid of all the textual OS configuration files and vestigal limbs of UNIX and get down to the simple bare metal fact that we tend to treat the OS as a hardware abstraction layer for a single application.
Oh, that makes sense, thanks. I was under the impression this managed everything (including DBs and other services), so I was wondering how this was possible.
I guess this ties in with another post I saw the other day, which was a lightweight container format you could add your environment to and deploy (and sounds like a game-changing idea). If we have a functional, standardized, self-contained container format that provides reasonable security and that you can install an environment to and just deploy to a server, it would pretty much mean that you can pick your app up and copy it to another host and be running in five minutes.
Comments
I think the basic concept to understand is that of the 'dyno'. Although a term from the Heroku platform, I believe it applies to most of the other platforms too. A dyno is a container (sort of like a VM but without hardware virtualisation, see LXC or OpenVZ) that isolates system resources. You can have multiple dynos on any given server and you can have lots of servers. Each dyno contains the entire environment needed by any given app, so it'll contain the specific binary version of ruby or node for example and it'll also have unique copies of all the dependencies, managed via bundler or npm for example.
Scaling your app simply means having more running dynos that are load balanced by a centralised load balancer used across the entire platform. So yes, interestingly there is a lot of duplication of the code base.
Services, like databases, are managed on their own separate servers/clusters and allow multiple connections and can be scaled/sharded separately from the dyno farms. Therefore they can be monitored, maintained, upgraded, etc, separately as well.
I'm a small-time contributor to http://github.com/openruko, an opensource Heroku clone.
I'd personally prefer to not adopt Heroku's nonsensical superhero terms, since we already have common terms for these things that make sense -- application containers, applications.
PaaS is "platform as a service". A way of automatically deploying, updating, and managing applications inside of application containers running on a cluster of machines, using either processes, virtualization, or OS-level process containers.
Amazon BeanStalk does this for Java by using Tomcat running in a EC2 VM, and exposing the servlet interface such that one can deploy Java webapps directly to BeanStalk.
Google App Engine did the same thing for Java, and with some custom packaging for Python.
The whole idea is to get rid of all the textual OS configuration files and vestigal limbs of UNIX and get down to the simple bare metal fact that we tend to treat the OS as a hardware abstraction layer for a single application.
Oh, that makes sense, thanks. I was under the impression this managed everything (including DBs and other services), so I was wondering how this was possible.
I guess this ties in with another post I saw the other day, which was a lightweight container format you could add your environment to and deploy (and sounds like a game-changing idea). If we have a functional, standardized, self-contained container format that provides reasonable security and that you can install an environment to and just deploy to a server, it would pretty much mean that you can pick your app up and copy it to another host and be running in five minutes.
That is correct :) Are you thinking of the post about http://docker.io? If so, I concur: Tsuru + Docker seem like they would be an awesome match.
Yep, that's the one! Man, I'm so excited about docker, even if I have to deploy it manually.
I definitely want to try tsuru + docker, yet this week :)