lvangool

Moving data is always the trickiest part! We get a lot of Heroku customers who need help with their data migration. My honest answer is there will always be some downtime while the switch over is happening, but we know of a few ways to reduce it. Unfortunately Heroku PG databases don't allow outside replication setup, so we can't really baseline your data and then close the replication gap with a shorter downtime. But we do support multi-DB solutions so we can run against an old and new DB at the same time while data is gradually being moved over. If you're interested, ping me at hello-at-cloud66.com if you want to discuss further :)

This precisely the niche Cloud 66 tries to fill, it caters for the growth businesses, providing initial ease but without sacrificing control. This allows companies to grow without being forced out before they are ready. (Disclaimer: I work for Cloud 66)

Ps. anyone running debian strech can get this via stretch-backports:

  echo "deb http://ftp.debian.org/debian stretch-backports main" | tee /etc/apt/sources.list.d/stretch-backports.list 
  apt-get update
  apt-get -t stretch-backports install git

Its there - thanks ;)

Hmm - the "official" git PPA isn't updated yet: https://launchpad.net/~git-core/+archive/ubuntu/ppa. Wonder if this due to dependencies or oversight?

Hey @hardwaresofton check out Cloud 66 https://www.cloud66.com/containers - Caveat... I work there :)

We're using weave a lot at Cloud 66; we find for the majority use-case inter-container comms at this throughput is sufficient; for high throughput endpoints like DBs there is an argument for not putting them in containers in the first place… (but thats another discussion)

I guess where we are attempting to be different is we are providing this functionality in a vendor agnostic way (ie. also for Linode, Joyent, Telefonica - Digital Ocean and Rackspace coming soon, and support for standalone servers in Hetzner, or your private cloud, or even under your desk for example)

As well as just supporting your preferred vendor (based on price, location, guaranteed location, SLA etc) it means that we can offer you a way to switch between vendors if that vendor has some down-time, or doesn't meet your changing requirements as you move forward.

Also, we are really trying to be as application centric as possible - everything stems from your application code - and then provide the ongoing management tools you need on top of that (for easy scaling, backups, scheduled tasks, migrations, reporting etc)

Great feedback from everyone! We didn't get a whole lot of sleep last night!

Yep thats also already on our roadmap!

Yep - we've got Django in our roadmap too!

Thanks for the question - there is a little more detail here: https://www.cloud66.com/help/cloud66_stack

Happy to answer specific questions

Yep! Digital Ocean just released the bit of their API we needed - so yes they'll be supported soon!

Actually you get to choose what sizes you want (whichever cloud provider you choose). See here: http://blog.cloud66.com/post/39922150128/custom-server-sizes...

Excellent article - being in a startup myself this is always in the back of my mind. An approach we are adopting is to purposefully not capture explicit details of the conversations, rather just discussing each conversation openly afterwards, and allowing our own minds to map-reduce to the important points. When those points become fairly static, then I believe we are there.

Interestingly I was discussing this with some friends last night (trying to solve the worlds problems on the back of a napkin as always :) One suggestion was to try and crowdsource deliveries in cities, ie. have depots centralised around public transport areas. But how to deal with security?