EC2 has an auto pilot option, but if I remember correctly it's more targeted for multiple instances, no auto scaling up or down only scaling out.
Developers need to focus on developing, it's always nice to have a developer who can also do the ops part, but I think no one will miss doing the plumbing work if they don't have to.
p.s. I would add a tweet button, this is tweet worthy and you should make it easier on people to both follow and spread the word
Few minor glitches:
- SSL mixed content warning on /how and /about
- / is different than /home (pricing link)
- logo redirects to /home instead of /
However Cloud 66 doesn't end at the end of deployment. It actively manages the app by monitoring the processes, making it extremely easy to add load balancers, scale web servers or background processes, add SSL certificates, schedule backups with one click and a lot more.
It is also not limited to AWS and supports Linode, Joyent, Telefonica Cloud with Rackspace and Digital Ocean coming soon.
This is on top of having all this on your own servers if you would like to have dedicated or colocated one in a data centre for whatever reason.
Elastic Beanstalk not only handles auto scaling. You can set limits that enable it to launch a replacement server if your pages start responding slowly.
The new console lets you easily add SSL certificates and schedule backups. I was pleasantly surprised how much Amazon has added to it in the last few years.
If you deploy code that crashes webapp, just revert back to previous version. Problem fixed in a minute on all your servers.
And you don't even need to do that actually, spin new environment with new set of servers. Upload new version to new environment, do the testing, then promote this environment to production status (takes a few seconds), and terminate previous production environment.
Perhaps other companies can offer service like this too, but my platform of choice is ASP.NET which narrows the field quite a bit.
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!
A reality is what's popular today in how a Cloud, or bare metal is used will be outdated in a few years and it creates technical debt in the future.
It amazes me how developers can obsess over development practices, frameworks, etc and without a thought look at the ugly underbelly of their app that grows as their code and userbase does.
Many developers on HN don't seem to have a relationship with a codebase for more than a few years (I could be completely wrong), but that is the perspective I'm speaking from.
It's great to see this kind of tooling that's focused not on management of infrastructure by abdication, but more of a middle ground.
Juju also has me excited, I think it's part of the future in a way VMware and virtualization first emerged 10-12 years ago.
Not to nay-say, but if you don't price according to value delivered, you don't stay in business long. Your income should grow faster than the infrastructure that you need to run the business.
It's also not clear what company is backing this service and how you're structured. Are you VC-backed? What happens when the money runs out, am I left holding the short end of the stick?
Only thing is though, here you have the option of choosing a larger instance type and by percentage the charge may be to low. To combat that I suggest a more tiered pricing.
I think the best point about our service is that since we don't own the infrastructure, you can always pickup the servers in the worst case scenario of us going out of business.
Just sayin', this is a tough business, and people get very cranky when things break. :-)
All that said, this is a huge space for new business, and I'm glad to see you guys throw your hat in the ring. Definitely an interesting take on things. Best wishes!
The neatest thing is being able to transfer your stuff to another provider within minutes. I haven't tried the manual thingy yet, seemed like too much fiddling, really.
The cost in my case isn't significant, less than an hours worth monthly. I'd have wished for more frameworks as RoR isn't really my weapon of choice.
Heroku and the like are fine for prototyping and small apps, but when you start developing complicated and/or popular apps, at some point you are paying a service tons of money to avoid optimizing at the systems level.
I'm a "devops" sysadmin and sitting with my developer every day makes us both so much more effective. "Hey sysadmin, if 1000 requests to this module in my app happen it breaks, can we figure out why it crashes the server?". To which I reply, "yes developer, after we ran some tests, it looks like your code is so efficient and effective, that there aren't enough available tcp/udp ports to support the number of requests it is able to handle. I can increase them on your default AMI if you like. It will result in a 3000% increase in the number of active users we can sustain on a given instance".
The no-ops position is: Let's just pay for more servers.
The DevOps position is: Let's optimize.
The difference may seem small, but if you are paying $20k a MONTH for your Heroku bills, not to mention supporting 3k servers for your app on AWS (or insert provider x), do you still think hiring a $100k/year sysadmin is such a bad decision?
The devs can still develop a method to quickly deploy code... or just use Asgard, and avoid all of the chaos that can happen if something goes wrong. The sysadmins understand your code and how it is interacting with the server. You don't end up paying tons of money to support a very basic application that has simply never been optimized.
Sysadmins in a devops world do not usually have any control over when builds can be pushed - they assist with optimizing. So if something breaks, the blame falls on devs, not ops.
Unoptimized app (rapgenius example): $20k/mo = $240k/year
Sysadmin: ~$100k+/year and a minor (given devops mentality) increase in deploy time = priceless
Not all cases are the same, but the start-up mentality doesn't usually work at scale.
Can you explain with some technical depth how you are actually deploying/configuring the app, what languages/libraries are supported, where/how DBs & external services are run/connected to, how web traffic gets routed/proxied to the apps, etc?
Happy to answer specific questions
When you know what's in the pipeline, it's even more exciting. Keep up the good stuff guys.
And that's a good thing. I realise Heroku is devsexy but having compared the two for a serious production app for bigco (a contest that EY won hands down) this architecture is long-term more resilient and adaptable.
So to me it's a sort of Engine Yard, BYO VMs. Ok. What is that, Devops as a Service? Nice look, btw.
Do you guys have any plans to support OpenStack clouds?
BTW your FAQ still lists $7
Yes. The $9 per server per month gives you: starting your app by provisioning, configuring and deploying. Monitoring and managing it as well as on going scaling, backup, add-ons, load balancers and other management features like continuous deployment or central logging features.
1. Hooks in the server configuration process that would allow you to do custom package installation and configuration. I know you can deploy to your own servers, but I'd rather specify configs in my app somewhere and have Cloud66 apply them as needed, a la chef recipes or puppet patterns.
2. Hooks into the deployment process to perform additional deployment related tasks.
As for hooks: We have hooks and API to start a deployment after your git commit or CI gives us a go ahead and are working to add post-deploy hooks so you can chain up the deployment to other systems you have.
Also, is there any Redis support?
For the reference, any server: virtual / physical or any size. Since we don't sell the servers, we only charge for provisioning, deploying and configuring as well as the on-going management (scaling, monitoring, backups, add-ons) per server.
Redis is coming soon (we use it ourselves and deploy our stack with Cloud 66 - so really keen to get it working so we can deploy and managed our own stack fully automated with Cloud 66!)
I really do think that there is a place in the market for something like this, and the more providers you support, the better off both you and your customers are.
1. node.js support is coming soon!
2. We're going to have at least one self-hosted real-time push solution in our app store (think Socket.io or Faye).
3. The whole reason we started Cloud 66 is to give developers more control over what traditional PaaS doesn't let you do. It's your server, you have full root shell access to it. If we don't do it (yet), you can always do it yourself!
One of the main bonuses of Heroku is not necessarily the web/worker process management but the easy ability to manage: email, SSL, nosql, and tons of other misc stuff you need for an app.
With limited dev resources, its way easier to just let Heroku handle all that config. The default app setup and sys admin is not as big a deal.
Cloud 66 however doesn't end at the end of deployment. It actively manages the app by monitoring the processes, making it extremely easy to add load balancers, scale web servers or background processes, add SSL certificates, schedule backups with one click and a lot more.
It also has an app store which is growing. We would love to hear you feedback about those features.
My app won't take the load in my current VM unless we run nginx / unicorn.
When you don't want to run the servers yourself, you can use services like appfog and nodejitsu (there may be more like those), which run a CloudFoundry stack.
When you decide "Hey, I want to run it on my server(s)", then you just setup their open source stack (there's even an automatic setup process for this) on your server and you're running on your own machine.
I assume I can't do that with your service, can I?
Yet when I visit my account (signed up a while ago) it's forcing me to a credit card page regardless of which option I choose?
Or maybe will wok on top of the heroku buildpacks?
2. Can I choose the linux distribution?
3. Can cron jobs be set up?
4. What about stuff like scout/monit etc ?
5. What about redis/memcaches/mysql/postgres?
However, it is always good to remember, all the boxes are yours and you have shell root access to them. So if we don't support something right now, you can always jump on the box and do it yourself the the Pro way!
We don't want to push our users to fixed upgrade windows, so we let them choose when it's convenient for their business to have the updates and then act accordingly.
Sorry, couldn't help it ;)