I think this targets a real painful need, managing an EC2 app on your own is not lacking frustrations, simple things like creating a rolling backup of instances needs complex shell scripts and cron jobs or 3rd party apps like http://www.skeddly.com, you need to be fluent in linux administration if you want to do simple things like increase your boot storage space (actually need to remove it, create a new volume from it, reattach it). Most developers will figure it out, but I would rather focus on development rather than infrastructure if I don't have to.
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
Yes. Elastic Beanstalk is great for deploying your code to EC2.
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.
Actually attended a local user group presentation on elastic beanstalk last night.
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.
I confirm all this. Elastic Beanstalk is so good, I don't even touch EC2 anymore. All my webapps are now being deployed through it. It costs more due to fact that each environment needs its own load-balancer even if only one server is involved which is extra $18/month but it is still worth.
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.
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!
This is a neat solution for a reality those of us who have been building web applications for a decade have faced: If you want your application experience (code + infrastructure) to be stable for a number of years, you have to be more and more responsible for your entire stack.
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.
At $9/month I suspect you are drastically under-valuing the service you provide. Sysadmin time is expensive, and your value proposition is the same as Heroku: pay us so you don't waste time sysadmining your boxes. Time is unimaginably precious for small SaaS shops, and if you deliver what you promise, it's worth far more than $9/month.
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?
Actually no I think $9/month is appropriate. A heroku dyno is about $35 a month, and you have a full on solid highly supported service. Here you pay $9/month + server fees which say with the micro instances comes out to about $14 bucks a month. So by doing it on my own EC2 with this service a small instance comes out to about $24.
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.
Fair points. We are a new service and are focusing on helping development teams at this point. Your point about the business is very valid and we are working on it to find the right price point.
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.
Your last point is DEFINITELY a +1 over Heroku. Although I'd be pissed to lose my deployment & monitoring tools and have to piece it all back together (especially after I thought it was "solved").
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!
I've actually been using this since open beta. This is for those like me, who can do devops when pressed to, but really hate it otherwise. Which is most web devs I know.
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.
Having a platform to simply deploy code is great, but there seems to be a lot of hate for sysadmins over the past few years.
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.
Depends on where you're living I suppose. In Chicago, a base of $100k/yr for a systems architect seems fair. In the Bay area and other areas that are more expensive, it will probably be more expensive, but I'm not as familiar with those markets. It certainly depends on the complexity of your product too.
Ah, yes. Did my run in trading. Pay (and experience) is great if you have the stomach for it. I found it soul-sucking and ultimately left. You are correct though, trading is extremely lucrative, not even getting into the other benefits.
Can you give a technical explanation of how this actually works? Heroku works by compiling your git repository with a buildpack into a "slug" and then booting that slug on a cookie-cutter LXC image running on an EC2 VM, according to process types you defined in your Procfile and the scaling you set through heroku's API, and then routing web traffic to your web processes. etc etc.
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?
How does the nginx fit in? Do you install an instance of nginx onto every single box? Or can you elect to use a web server box as your frontend nginx and proxy request back to a set of separate servers running instances of passenger?
At the moment nginx sits on every frontend box serving Passenger. Unicorn support is coming soon. Split of front end proxy and backend server is further down the line. Feel free to put it down in the Feedback panel on the site and vote it up! Thanks.
I have used this since it's been in beta because I know the guys behind the service. Besides being exceptionally dedicated and cool guys, the service is genuinely good. It definitely solved our problem of going to production with something like Heroku. It's a lot more cost/performance effective and also (as mentioned in one of the comments) you have full access to your box if you need it!
When you know what's in the pipeline, it's even more exciting. Keep up the good stuff guys.
Just looking at the stack docs put me more in mind of Engine Yard than Heroku: HAProxy, nginx, passenger, DB options etc.
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.
DevOps as a service, WebOps in the cloud or anything you'd like to call it. We made it because we had the same issues as all other devs with Heroku. I hope we built something useful.
Very impressive. Could you help with the pricing a bit more. The cost is $9 per server per month in addition to costs from the cloud provider with the first server free?
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.
For what it's worth, I misread the button at the bottom of the "How it works" page when I first scanned through; I thought it said "Try Cloud $6", but it actually said "Try Cloud 66". Maybe that's what they saw.
Are any of the following possible or planned for development?
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.
Yes and Yes! As a metter of fact deployment hooks (both for packages and scripting like Chef) are available as private beta. Once we are done with the tests they will be released.
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.
Just giving the github repo and the place we want to host, everything is taken care of! Pretty cool!
Before i deployed my app to amazon ec2, i had pretty bad time with rubber gem, then with chef-solo and then capistrano, i always thought of something like this. So, it should definitely many who want to go with IAAS services but don't want the hassle of deployment.
That's a valid point. Thank you. Will work on a better pricing page.
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!)
Nice. As a provider of unsupported hardware, I'd be interested in some "how to make it easy for us to support users on your hardware" page.
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.
Thanks! We are seeing a lot of folks using us to run their apps on dedicated on servers on Hetzner or OVH in Europe. If you are interested, drop us a line at hello@cloud66.com and we can talk about new providers!
Awesome idea solving a real pain. Timely too given recent headaches with AWS sneezes.. Every time AWS has an issue, our site on Heroku is affected. Can you speak to SLA, downtime/uptime of service?
We built Cloud 66 to combine the convenience of PaaS with control of having your own servers. Even if we are down, your servers will still be up on your own preferred cloud vendor serving your users! That's a win for everyone!
This is very cool stuff. Do you guys support (or do you plan to support) any type of cross-provider failover? I.e. if AWS goes down, auto re-deploy to Linode and handle the DNS re-routing, etc.?
Great point! Yes. We already configure DNS records for the stack (load balancers and servers). This allows us to take the same cut of code and build scripts and execute them against another provider like Linode or Joyent when AWS has issues automatically.
This is an awesome idea. I've been looking for something with the flexibility of managed infrastructure but the ease of use of Heroku for a while. I'll definitely be trying it out.
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!
No mention of what size instances are being created on aws seems a bit scary. Otherwise cool. I'd use it if it were self hosted and available for node.
Yeah I just setup two micro instances to play around with it. I'm thinking I'll setup something on DigitalOcean assuming I'm happy with what I'm seeing.
Does this have a comparable add-on or plugin architecture?
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.
That's a good point. Heroku is great because it takes away the pain through the add-ons.
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.
Not having looked at this extensively I don't see what about it is more compelling then just using my own servers with git-deploy or a similar infrastructure. If i am going to run Ops i want to run Ops. If I am going to outsource it I want to outsource it. This seems like a middle ground that doesn't add too many compelling features to the party.
Whoo, I was expecting a link to OpenRuko, an OpenSource clone of Heroku, working with all technologies supported by heroku, and with the same api. https://github.com/openruko
CloudFoundry is great to build a PaaS on your own servers and want to manage it. However if you really don't want to manage and run an infrastructure then you would probably don't want to run a system like CloudFoundry!
I assumed (perhaps wrongly) that if you don't want to deal with infrastructure you'd prefer PaaS solutions like Heroku and therefore you wouldn't want to manage not only a software package like CloudFoundry but also the servers that run it.
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?
For the first 30 days everything is free and no CC is required. After 30 days, you can have one server for free after entering your CC. This will only be charged if you add new servers to your stack.
for a still fairly new to intermediate developer like myself, this seems more work than running it on heroku. not a bad concept, but maybe for more advanced developers.
I see references to scaling web servers but not for dedicated database servers. Is this possible? I'm thinking specifically of hot standby PostgreSQL servers.
1. We support manifest files (in private beta now) to allow you just that.
2. Yes. Both on the server (as you would do normally on any linux box) and through our CRON app.
3. We provide minimal vital signs for all the servers: memory, disk and CPU.
4. MySql and PostgreSQL are supported. Redis is coming soon. Memcache is after that.
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!
Sounds great. The problem with dropping in via shell is that, launching servers become much problematic. I think if you can run custom chef/puppet scripts, that will solve this issue.
We monitor the software/packages/gem/libraries that we deploy and warn users when there is an update or security issue in the dashboard. For some we take control of the upgrade and for some we don't.
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.
We provision the servers to be as secure as possible at the OS level using open source and industry tested best practices. If you are running on a cloud vendor like AWS you can benefit from added security layer provided by our partners at Dome 9 to provide network level security.
Agreed. My first thought was: 'what is being done to secure these instances?' Transparency in security policies would be a welcome addition to your site!
OpenShift is a great solution to build your PaaS. Cloud 66 is however provided to you as a service. So if you like PaaS because you don't want to manage or run an infrastructure then you probably wouldn't want to manage and run OpenShift (or CloudFoundry) either.
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 /