Hacker Newsnew | comments | show | ask | jobs | submit | gabrtv's commentslogin

> The services are considered to be in a trusted network and are accessed by a private token passed in the ‘Authorization' header plus the user id of the requester in an ‘X-USER’ header.

This reads like the user ID is exposed in a header without any sort of encryption.


What does 'trusted network' mean to you?

A lean quick service is not going to want to wait on encryption handshaking.


On modern hardware, I believe AES and SHA-384 are very cheap. But yes, in a private network it's overhead.


I'm a big believer in "Readme driven development" [1]. It's critical you go through the exercise of 1) explaining what the software will do and 2) how it will be used with concrete examples. The value of this documentation will always outweigh the time spent writing it.

[1]: http://tom.preston-werner.com/2010/08/23/readme-driven-devel...


Not many PostgreSQL DBaaS offerings out there. This is great news.


Deis maintainer here. We understand Deis can be a bit heavy for those who don't want a multi-node HA setup. For the 'humble web developer' we strongly recommend Dokku. In fact, we're now sponsoring that project: http://deis.io/deis-sponsors-dokku/


This is exactly why we sponsor Dokku: http://deis.io/deis-sponsors-dokku/ Go Dokku! :)


No. As a PaaS designed to run enterprise workloads with high availability, Deis has a 3-node minimum.

If you're looking for a similar workflow but with a smaller footprint, Deis now sponsors the Dokku project: http://deis.io/deis-sponsors-dokku/


Short answer: Deis is easier to install/operate and it's designed to leverage Docker from the ground up. You won't be promoting Docker images through a CI/CD pipeline with Cloud Foundry any time soon.

Email me for a longer answer: gabriel@opdemand.com. ;)


Your point is taken: some of the underlying technologies we use are still under active development. That said, we've worked with enough production Deis deployments to know that etcd and fleet (for example) run much better than some might think.

As early adopters of these technologies, we have strong relationships (and often formal L3 support) with the teams involved. We are often the first to report issues as well as the first to test fixes. You can view this announcement as a vote of confidence in those projects and our ability to roll out fixes as bugs surface.

Hope to see you back in the #deis channel soon!


Deis and Kubernetes are solving different problems. Deis is a PaaS that provides a developer self-service capability a la Heroku. Kubernetes is a declarative container manager that provides lower-level orchestration features. Both are complimentary. For example, Red Hat is using Kubernetes to deliver their OpenShift v3 PaaS. We've explored a similar integration with Kubernetes but are currently more focused on integrating with Mesos a next step.


Project creator here. It's been a fun 16 months getting to this point. Happy to answer questions.


Great work! I played around with deis a few months ago and it was the first PaaS I was able to get up and running and actually, you know, deploy an app to!

Couple questions:

1. What about storage? I know you use ceph for the Docker registry, etc. Is that exposed so that apps can somehow use it?

2. When I tried it, performance was kind of lacking (for things like pushing apps and making config changes). Was this just a limitation of my setup (I used 3x2GB DigitalOcean nodes) or something you guys are working out?

Thanks again!


Hi, I'm also a maintainer :) to answer your questions:

1) we expose ceph in the router, so your apps could use it. This will have to be managed by you however as we don't have a user story for plugging apps into backing services asides from `deis config:set`[1]... Yet.

2) Performance is still something we're working on. When you deploy an application using a Heroku buildpack[2], your app is compiled into a container which sits on top of Heroku's cedar stack, which is around 800MB[3]. It's a beefy stack so fleet will take some time deploying that image. This should only occur the first time it's scheduled onto a new host as future images will just use the cache for that image, significantly speeding up deployment times. If you deploy an app using a Dockerfile and it's been optimized correctly (we have an app sitting under 5MB for test purposes)[4], deployment times should be very speedy.

Hope that answers your question!

[1]: https://github.com/deis/deis/issues/231

[2]: http://docs.deis.io/en/latest/using_deis/using-buildpacks/

[3]: https://github.com/progrium/cedarish

[4]: https://registry.hub.docker.com/u/deis/example-go/


I'm not a huge Drupal or Wordpress fan but I can see how people would want to deploy either of those CMS options. I would be interested in hearing your thoughts regarding this discussion:



This is one of the general problems about PaaS. One of the tenets of 12 factor is that "12 factor processes are stateless and share nothing. Any data that needs to persist must be stored in a stateful backing service, typically a database"[1] which is why we want to avoid persisting state in the container.

Content Management Systems like Drupal or Wordpress typically store file uploads or configuration files directly onto the filesystem. With Deis or any other PaaS, this filesystem is ephemeral unless there is a shared filesystem mounted inside the container, typically via SSHFS[2] or some other remote filesystem.

We want to tackle this problem with a service gateway[3] for apps to attach backing services like a shared filesystem, but for the moment there's always S3 :)

[1]: http://12factor.net/processes

[2]: http://fuse.sourceforge.net/sshfs.html

[3]: https://github.com/deis/deis/issues/231


I'll skip abstract questions and jump right to our concrete situation. We have a bunch of services (Go app, RethinkDB, redis, haraka MTA, server for an Angular app) running in Docker containers on Hetzner servers. Is Deis compatible with our use case?


Since the router only does http right now (or so it seems) it probably isn't a good fit for you, or at least not for all services. I'd be really keen on trying Deis with RethinkDB if it got TCP support.


Thank you!


What does Deis do about app logs? This is a main problem I have with Dokku at the moment.


application logs are aggregated and shipped to a logger component[1]. if you scale processes and run `deis logs`, you'll see the log output of every running process for that app.

[1]: https://github.com/deis/deis/tree/master/logger



Applications are open for YC Summer 2015

Guidelines | FAQ | Support | Lists | Bookmarklet | DMCA | Y Combinator | Apply | Contact