
Introducing PaaSTA: An Open, Distributed, Platform as a Service - nhandler
http://engineeringblog.yelp.com/2015/11/introducing-paasta-an-open-platform-as-a-service.html
======
xchaotic
Can't wait until it evolves into code Spaaghetti ;)

------
tekacs
Looks very interesting, especially if community involvement ramps up to patch
over the relatively rough[0] open sourcing that's happened here.

The blog post seems more descriptive of 'what' and not 'how' any of this
works, so this page may be more informative:

[http://paasta.readthedocs.org/en/latest/installation/getting...](http://paasta.readthedocs.org/en/latest/installation/getting_started.html)

[0]: not a bad thing! raw code is better than no code!

------
ealexhudson
Be interesting to compare this to mantl.io, which I think has a bit broader
reach in terms of components but is otherwise very similar.

These projects could really take off if that initial "bring it up" stage is a
bit easier - deploying turn-key apps is great, but there's not much reason an
opinionated stack itself can't be turn-key too.

------
smanuel
> It is not optimized to be simple to deploy for operators. [1]

Isn't the whole point of a PaaS to be easily deployable so that I don't have
to learn a bunch of other tools, that depend on a bunch of other tools,
that... You get the point.

[1]
[http://paasta.readthedocs.org/en/latest/installation/getting...](http://paasta.readthedocs.org/en/latest/installation/getting_started.html)

~~~
michaelbuckbee
I don't think this is for devs who want an alternative to Heroku, Modulus or
whatever PaaS you prefer, but to people who want to build their own PaaS for
their internal developers.

~~~
smanuel
> but to people who want to build their own PaaS for their internal developers

I don't understand this. Can you elaborate?

~~~
michaelbuckbee
So, the use case for Heroku is straightforward: you have a webapp that you
need to get online. You signup, do a 'git push heroku master' and your
application is online.

Say instead that you are Yelp, you have a couple hundred developers all of
whom are clamouring for the same ease of deployment that they can get with
Heroku but that's not appropriate for a whole bunch of reasons (lots of
internal apps for accounting or credit stuff, a custom HR app, who knows) and
at Yelp's scale it is cost effective to start having devops/sysadmin type
people on staff instead of just rolling that into your Heroku costs.

So the answer is that you use something like this deployed to your own
hardware in house, or you use Deis or Convox or some other Docker solution to
deploy to AWS or a bunch of Virtual Private Servers or something. This gives
you a good management and deploy experience at a fraction of the cost (not
counting that you have to buy your own hardware and also pay a competent
Devops person $100k+ a year).

~~~
jacques_chester
I'm late to this thread, but an easier solution is to take a full-featured
PaaS and install that instead.

I work on Cloud Foundry. Some people use OpenShift. Both are featuresome and
don't require much more than to install them and start pushing apps.

------
henryaj
> At Yelp we believe in not reinventing the wheel where possible.

Then... why invent your own platform instead of just using Cloud Foundry[0]?

[0]: [https://www.cloudfoundry.org/](https://www.cloudfoundry.org/)

~~~
sciurus
It seems like they value the flexibility to mix and match and change
components over time, rather than the simplicity of adopting an integrated
solution like CloudFoundry or OpenShift.

