There's a few options out there. You can treat DO as a compute-only EC2 if you'd like. I work on a project called Rubber [1] that can provision servers and templates for you. DO is one of the supported providers. We've taken care of a lot of the annoying stuff for you, like mapping security group rules back to iptables, setting up DB replication, off-site backups to S3, and so on.
You'd likely be able to do the same with chef, ansible, puppet or whatever else. I don't have deep experience with those options, so I can't really speak to them.
I haven't used Cloud66, but I've seen them come up a few times. I think the biggest difference is Rubber has templates for common pieces of software and deployment scenarios. Since it's based on the role-centric system Capistrano provides, you can do things like set up several "app" machines and then a "web" machine, which runs HAProxy and automatically routes requests over those "app" instances.
But, I think we fill that niche between hand-holding and trusting devops/sysadmins to do what they think is best. We try to handle the monotonous tasks for you (configuring DNS, setting up backups, configuring load balancers, etc.) out of the box, but give you a great deal of flexibility to influence that. Almost everything is bash and ruby with a healthy set of utility functions.
I admit, it occupies kind of a weird middleground. If you use Heroku because you're not well-versed in sysadmin tasks, there will be something of an uphill battle (but a great learning opportunity). If you want to outsource everything, it's not a great fit. But, if you want a lot of flexibility, have unique app contstraints, want the abilitity to switch betweeen cloud providers and not deal with everything from scratch, it's a pretty good fit. I've personally used it with EC2, DO, vSphere, Vagrant, and leased hardware. It's nice being able to treat them basically uniformly.
Checkout visualops.io. We are language-independent devops automation service.
Similar value with Heroku: autoscaling, auto-healing, push-to-deploy, but not blackbox. Instances runs in your own account. Even if we go down, your app will not be impacted.
Nope. It's got a Ruby inclination, but it's something we're divorcing ourselves from. Deploying Sinatra and other non-Rails, Ruby apps is pretty straightforward. Deploying non-Ruby apps is certainly doable but currently requires a bit of creativity (I've deployed Java and Scala apps with it).
It also spins up other server types like Selenium. (I do alot with Selenium, and even have an accepted pull request in Rubber's Selenium implementation)
You'd likely be able to do the same with chef, ansible, puppet or whatever else. I don't have deep experience with those options, so I can't really speak to them.
[1] -- http://rubber.io/