Over 7 years, 100s of VMs atm. Tried to get into AWS and GCP few times over the years just for the resume-building and fun, didn't see the point. While I can understand they fit some use-cases, I think a good rule of thumb would be - if you don't know why exactly you need AWS/GCP/Azure, go with DigitalOcean. I worked at 2 companies that, if they went with AWS as they've planned, they would've gone under three times over, mostly because of the egress. If you're startup and DO's services are mostly there for your use case, it's antithetical for you to go with AWS/GCP.
Just switched to AWS from DO after 5 years. DO was working great, but needed a more managed solution (am very familiar with the sysadmin, but just wanted to reduce workload) so went with AWS Fargate and happy with it so far.
It's not a personal project, but for work. Basically to run our mobile backend (nginx, spring boot, mongodb, rabbitmq, etc), staging and production. And all that needs redundancy of course.
Me too, but they recently let me down with their managed Redis . They clearly mention that their offering has daily backups, but it actually doesn't (had to contact support to find out, though). Had to migrate away from them because of that.
Hey, Kamal from DigitalOcean here. I'm sorry that happened to you! You're right, managed Redis Databases do not support backups[0] currently. I found the page on the website that says they do and let the team know. They will correct it asap.
Hey Kamal, good to see you here. I'm sorry to hijack this thread, but I'm hoping someone from DO could provide an official response to this often-cited post on HN regarding security issues on your K8S offering: https://news.ycombinator.com/item?id=22490390
Is there a chance you could poke someone into looking into this?
I'm the tech lead for Kubernetes at DO. Just wanted to jump in and provide some clarification around the security issues you brought up.
The blog post you're referring to came out in December 2018, shortly after we released DOKS as a Limited Availability offering. By the time we announced our General Availability release in May 2019, we had done the following:
1. Changed our node bootstrapping process so that etcd information is no longer necessary in the metadata API, and removed said etcd information from metadata.
2. Firewalled off etcd so that it's accessible only inside the cluster.
3. Shifted how we run the CSI controller component so that a DO API token no longer needs to be stored as a secret in the cluster.
4. Switched from Flannel to Cilium as the CNI plugin, which allows users to configure network policies. We don't configure any network policies by default, but the option is there for users who want to use them.
These changes fix the vulnerabilities explained in the blog post. We do have further hardening measures planned, including limiting the scope of API tokens (one of the suggestions from the blog post, and also an often-requested feature from DO customers), but that's a big project so we can't provide a firm timeline for it at this point.
Hope this clarifies the current situation. If you or anyone else finds new security issues with DOKS (or other DO products) we would love to know about it. Our security team is always accepting vulnerability reports via their disclosure program: https://www.digitalocean.com/legal/contact-security/
Hey, I ran this by the DOKS team and they confirmed that this was taken care of a while back. Just to clarify, that issue existed while the product was in Limited Availability (think alpha). Nodes are now bootstrapped in a different way that eliminates the need to expose sensitive info in metadata or anywhere within the cluster itself.