Threads for titanous

  1. 1

    Anyone able to compare this against Deis Workflow, Dokku, or some of the other open-source container-based PaaS systems?

    1. 2

      Hey, I’m one of the creators of Flynn.

      Obviously I’m biased, but here’s my take:

      Dokku is architecturally very simple, just a bunch of bash scripts, because it only focuses on single-host use cases.

      Flynn is natively highly available (though you can run it in a single-host configuration) and has a larger technical scope, covering everything from the details of how container are run all the way up to the user interface used to deploy applications. We also run highly available databases within the platform, in addition to stateless webapps. As a result of working to build an easy to use unified solution, we’ve ended up building many components from scratch specifically for Flynn and have very few dependencies.

      Deis is designed to use commonly used off the shelf components, and has a focus on stateless web apps. Currently Deis is built around the Kubernetes and Docker ecosystems.

      Flynn’s approach has given us more flexibility, but it has taken longer, so Deis has often reached various milestones faster.

      It’s a frequently asked question so hopefully in the future a well-informed user that has experience with various platforms can write a detailed teardown/comparison.

    1. 1

      I was very surprised by the lack of testing braches in a staging environment before pushing to production. My guess is that Github must be very confident in their continuous integration tests to let so many branches go straight to production.

      1. 1

        They’ve stated that they have at least one other person do a code review before deploying. When you have a comprehensive test suite, and do a bit of QA testing locally, it’s totally reasonable to push to production after a code review and the build is green.

        The trick is to do many small patchsets and deploy often. This makes reasoning about the change easier. I tend to only use staging when testing data migrations. New/beta features can be pushed out behind a feature flag so that they can be tested in production by beta testers/staff.