I want it to be known that Solomon and Sebastien are awesome. They set us up with hosting for our project when we applied to YC several months ago and Solomon took several hours of his own time to really sit down with me to walk us through getting setup. Their system is really kick-ass and amazing. We were working with Django for our framework, and configuration for a project is really straightforward. It was awesome not to have to worry about server configurations at all and just focus on getting work done.
I think this is the first YC company with french founders so congratulations to the team for that, and most importantly congrats for your launch I look forward to test it! Dotcloud seems awesome!
Is there any reason you're running an outdated version of Nginx (0.7.65 vs 0.7.68 vs 0.8.54)? It's one major revision behind current and a few minor behind stable. Which brings me to a question I had lingering in my mind, what is your "software" upgrade process since users have no control over it?
Another question, do you cache non-static objects (cookie based caching when proxy_pass'ing)? If so, how are you handling the different cookies for each particular app? Can this be turned off?
- 0.7.65 is the version currently used in ubuntu lucid. We use it only as a proxy.
- On services like python-wsgi we currently use 0.8.52 and we will soon upgrade to 0.8.54
- On the ruby-passenger service we follow the nginx pulled by passenger
So it's always dependent of the context. The idea is to keep the stacks stable and secure at all times.
Once we have tested and approved an upgrade we create a new revision of the corresponding service and deploy it across the platform. If the upgrade requires downtime we schedule a rolling maintenance window and notify users.
On caching:
We don't cache by default (but this could change). Users have the option to add caching services like varnish.
As a developer struggling to also be a sysadmin I find this very interesting. We were just about to start looking for a sysadmin to manage what we're doing, so it will be interesting to see how DotCloud works. We're Python focused, so this looks to be right up our street. Curious to know what others do in terms of managing the servers etc - do you think that it could be dangerous to rely on a service like this? Do you think its better to understand from end-to-end what you're using and why?
I HIGHLY recommend Dotcloud. We have been using them for a couple of months and its insane how easy it is to get setup. The Dotcloud guys have done a spectacular job in making it painless to use their system. Ours was a Python/Django app and just took a few lines of configuration to get up and running.
Cassandra and Hadoop alone need a good chunk of domain knowledge to keep them running smoothly. Seeing them listed casually next to so many other deployment stacks makes me feel slightly dizzy.
I'm definitely looking forward to see if you'll be able to pull this off.
You're correct, there's a beefy learning curve to properly configure, fine-tune and scale each of these components. Our job is to tackle that learning curve so you don't have to.
As a developer, you get a little more value out of that deal every time you want to play with something new.
It works for us, because after a while you start seeing patterns in proper automation. There are only so many ways to store, modify and move bits around.
I like the courage trying to manage this. Two thumbs up.
To be honest, I am skeptical, that a newcomer startup can do the heavy lifting of supporting such a big stack. Each of these has a lot of specialities that need to be known and to fight.
Background: Our stack uses appjet, nginx, varnish and couchdb. Each of these has different challenges. Think of optimization, scaling, resource limiting, leveling, monitoring, statistics and enforcing governor limits/notifying customers. We needed over a year to establish this. I don't want to sound negative, just think about all this, what we needed learn.
If you think about it, isn't it incredible that you had to invest so much time and money in building out your infrastructure? How many web businesses had to re-invent the wheel to get to the same result?
Yes, it's hard work for us. But 90% of the work is the same across all deployments. We take advantage of that fact to offer massive savings in engineering and sysadmin time.
Congrats to the dotcloud team! I already had the luck to work with seb and sam from the dotcloud team and I can testify that they are extremely skilled and reliable guys. They won't fail you nor your servers :)
My 2 cents
Fantastic idea; wish I had thought of it. I'm very curious to see how efficient your "glue" code is between the components. It's one thing to have a modular hands-off system, it's often another to have that system perform reasonably well. What level of system administration do you expose/hide to the developer? How do you plan to make money?
Our focus is on giving control a developer needs: how do I install language-specific packages? How do run my tests? How do I pass settings to my app? How do I run that custom build command?
We don't offer root access. But we're working on customization tools that will make you forget you ever had to ssh into a server directly.
As for pricing: we're already charging a few test customers, and will expand paid plans to all beta users very soon.
Heroku has a fixed stack with tiers that they could tune, tweak and horizontally scale. Is that what dotcloud provides for each of the listed technologies ?
very interesting. I am interested in seeing how it actually works though. Its still behind the doors. Hope to get invite. (btw, heroku is not just deployment platform, it helps u scale as well. Interested in seeing if dot cloud helps in that fashion)
I like the strategy of using other YC companies as alpha customers. If any of the companies on the platform get traction it looks pretty good for DotCloud as well.
We're taking one step at a time. First we'll give you metrics to help you decide when to scale up or down. Eventually we'll offer to take that decision for you, with a configurable ceiling.
In our experience, for most customers 10-second manual scaling is just as good as auto-scaling.
Database migration is a complex subject:-) You have full control over you database (with sql prompt and everything). That means that you can use any migration tool you like.
If we start seeing a recurrent pattern we'll try to automate.
[+] [-] shykes|15 years ago|reply
Also open to suggestions for a "Offer HN" post :)
[+] [-] spahl|15 years ago|reply
[+] [-] geuis|15 years ago|reply
I want it to be known that Solomon and Sebastien are awesome. They set us up with hosting for our project when we applied to YC several months ago and Solomon took several hours of his own time to really sit down with me to walk us through getting setup. Their system is really kick-ass and amazing. We were working with Django for our framework, and configuration for a project is really straightforward. It was awesome not to have to worry about server configurations at all and just focus on getting work done.
[+] [-] ramoq|15 years ago|reply
[+] [-] bjonathan|15 years ago|reply
Cocorico :)
[+] [-] jjoe|15 years ago|reply
Is there any reason you're running an outdated version of Nginx (0.7.65 vs 0.7.68 vs 0.8.54)? It's one major revision behind current and a few minor behind stable. Which brings me to a question I had lingering in my mind, what is your "software" upgrade process since users have no control over it?
Another question, do you cache non-static objects (cookie based caching when proxy_pass'ing)? If so, how are you handling the different cookies for each particular app? Can this be turned off?
Regards
Joe
[+] [-] spahl|15 years ago|reply
- 0.7.65 is the version currently used in ubuntu lucid. We use it only as a proxy.
- On services like python-wsgi we currently use 0.8.52 and we will soon upgrade to 0.8.54
- On the ruby-passenger service we follow the nginx pulled by passenger
So it's always dependent of the context. The idea is to keep the stacks stable and secure at all times.
Once we have tested and approved an upgrade we create a new revision of the corresponding service and deploy it across the platform. If the upgrade requires downtime we schedule a rolling maintenance window and notify users.
On caching:
We don't cache by default (but this could change). Users have the option to add caching services like varnish.
[+] [-] inovica|15 years ago|reply
[+] [-] geuis|15 years ago|reply
[+] [-] moe|15 years ago|reply
Cassandra and Hadoop alone need a good chunk of domain knowledge to keep them running smoothly. Seeing them listed casually next to so many other deployment stacks makes me feel slightly dizzy.
I'm definitely looking forward to see if you'll be able to pull this off.
[+] [-] shykes|15 years ago|reply
You're correct, there's a beefy learning curve to properly configure, fine-tune and scale each of these components. Our job is to tackle that learning curve so you don't have to.
As a developer, you get a little more value out of that deal every time you want to play with something new.
It works for us, because after a while you start seeing patterns in proper automation. There are only so many ways to store, modify and move bits around.
[+] [-] sbisker|15 years ago|reply
If someone can tell me which YC batch they're a part of, I'll edit the title - this is the first time I'm hearing about them.
[+] [-] spahl|15 years ago|reply
[+] [-] js4all|15 years ago|reply
To be honest, I am skeptical, that a newcomer startup can do the heavy lifting of supporting such a big stack. Each of these has a lot of specialities that need to be known and to fight.
Background: Our stack uses appjet, nginx, varnish and couchdb. Each of these has different challenges. Think of optimization, scaling, resource limiting, leveling, monitoring, statistics and enforcing governor limits/notifying customers. We needed over a year to establish this. I don't want to sound negative, just think about all this, what we needed learn.
[+] [-] shykes|15 years ago|reply
Yes, it's hard work for us. But 90% of the work is the same across all deployments. We take advantage of that fact to offer massive savings in engineering and sysadmin time.
[+] [-] thibauld_|15 years ago|reply
[+] [-] jsarch|15 years ago|reply
[+] [-] shykes|15 years ago|reply
We don't offer root access. But we're working on customization tools that will make you forget you ever had to ssh into a server directly.
As for pricing: we're already charging a few test customers, and will expand paid plans to all beta users very soon.
[+] [-] dtran|15 years ago|reply
[+] [-] citricsquid|15 years ago|reply
Edit: now it's gone... that was strange. I'm sure I saw a gold name!
[+] [-] kalessin|15 years ago|reply
[+] [-] spahl|15 years ago|reply
[+] [-] datums|15 years ago|reply
[+] [-] spahl|15 years ago|reply
For example:
- for django you will have an easy way to add more instances
- for mysql more slaves
- for celery or resque more workers
[+] [-] ameyamk|15 years ago|reply
[+] [-] shykes|15 years ago|reply
You can scale up any component in your stack by cranking up the number of instances. We automatically provision and reconfigure instances for you.
[+] [-] Skywing|15 years ago|reply
[+] [-] barrydahlberg|15 years ago|reply
[+] [-] shykes|15 years ago|reply
Would you be willing to host a production .Net app on Mono?
[+] [-] okaramian|15 years ago|reply
[+] [-] pbiggar|15 years ago|reply
[+] [-] shykes|15 years ago|reply
In our experience, for most customers 10-second manual scaling is just as good as auto-scaling.
[+] [-] minalecs|15 years ago|reply
[+] [-] shykes|15 years ago|reply
We would love to hear your suggestions at [email protected].
[+] [-] grigy|15 years ago|reply
[+] [-] spahl|15 years ago|reply
If we start seeing a recurrent pattern we'll try to automate.
[+] [-] ajaimk|15 years ago|reply
[+] [-] shykes|15 years ago|reply