3 ms·

Do you run Postgresql, MySQL, or something else? What led you to your choice? Because one is inherently better than the others for what you want to do? That's w

by scurvy 11y ago

Do you run Postgresql, MySQL, or something else? What led you to your choice? Because one is inherently better than the others for what you want to do? That's why you stick with a single cloud provider. You want the vendor lock-in. You go whole hog into using everything that they provide. Once you start mixing and matching the best of breed across cloud providers, you've lost. Once you start coding to the least common denominator amongst cloud providers, you've lost. To really succeed, you must choose the best cloud offering and then use everything that they offer. Otherwise, why are you running stuff in the cloud anyway? Also, steer clear of "cloud neutral" services and products that will magically move data and services across cloud providers. Interop is the last thing on any proprietary vendor's mind. An example. You have a pair of border edge routers. Do you buy 2 Junipers, 2 Ciscos, or 1 Juniper and 1 Cisco for fear of a bad vendor bug taking out all the routers? I'll tell you which one I would not choose. The .com TLD nameserver requirements used to mandate dual vendor setups. They sure did learn their lesson.

antsar 11y ago
> They sure did learn their lesson. Is there any relevant reading material? I would have assumed diversification to be a good idea for such critical infra.
- scurvy 11y ago
  I don't know if there is any reading material. I heard the story from someone who was on the front lines in the outage, directly dealing with the situation. Vendor diversification is a bad thing for critical infrastructure when interoperation is required. "It's a Cisco problem!" says the Juniper rep. "It's a Juniper problem!" says the Cisco rep. You're stuck in the middle. It's terrible. You can only hold one vendor's feet to the fire and they won't care at all if you're in a heterogeneous environment. Remember all the middleware products and companies from the late 90's? Neither do I.
X-Istence 11y ago
Comcast as a company purchases from two vendors to avoid lock-in and to get the best prices. Juniper and Cisco, although last I heard Arista was also starting to be used. Dual-sourcing makes sense in a lot of cases.
- scurvy 11y ago
  You can definitely dual source for separate parts of your network. Just don't dual source for the component in the same deployment. You do not want to run a Juniper and Cisco router in a pair, both talking with each other running IS-IS, VRRP, etc.
mwcampbell 11y ago
Based on your other comments on this thread, you seem to have real expertise in operating this kind of infrastructure. Nevertheless, this particular comment makes no sense to me; I'm not even sure if you're serious. It does make sense to standardize on one open-source database package (MySQL in the case of my employer). But that's software that I can take with me anywhere. And it's open-source. So the risks of vendor lock-in don't apply. > Otherwise, why are you running stuff in the cloud anyway? How does it follow that if I don't lock myself into one cloud provider all the way, it's not worthwhile to use the cloud at all? Maybe using cloud providers is worthwhile simply because, at a certain scale, they're less expensive than leased dedicated servers, never mind the up-front cost of buying and colocating hardware. Also, it's easy to provision cloud VMs on demand, then throw them away when you're done with them. Those are good reasons to use cloud providers without locking into just one. It seems to me that the best approach is to use only the subset of features that are common to DigitalOcean, Vultr, and maybe Linode, and abstract over those multiple providers with software like Ansible that can access multiple provider APIs. I am indeed suspicious of proprietary solutions for deploying and migrating across cloud providers, such as Cloud66. But that's only because using one of those solutions would itself be an instance of vendor lock-in. If there were an open-source package with similar functionality to Cloud66, I would probably use it.
fanf2 11y ago
I thought the .com servers had been running Verisign's proprietary Atlas software since almost forever - 15 years?
- scurvy 11y ago
  I was referring to routers. They have to buy routers from someone.

by scurvy 11y ago

antsar 11y ago

> They sure did learn their lesson. Is there any relevant reading material? I would have assumed diversification to be a good idea for such critical infra.

scurvy 11y ago
I don't know if there is any reading material. I heard the story from someone who was on the front lines in the outage, directly dealing with the situation. Vendor diversification is a bad thing for critical infrastructure when interoperation is required. "It's a Cisco problem!" says the Juniper rep. "It's a Juniper problem!" says the Cisco rep. You're stuck in the middle. It's terrible. You can only hold one vendor's feet to the fire and they won't care at all if you're in a heterogeneous environment. Remember all the middleware products and companies from the late 90's? Neither do I.

X-Istence 11y ago

Comcast as a company purchases from two vendors to avoid lock-in and to get the best prices. Juniper and Cisco, although last I heard Arista was also starting to be used. Dual-sourcing makes sense in a lot of cases.

scurvy 11y ago
You can definitely dual source for separate parts of your network. Just don't dual source for the component in the same deployment. You do not want to run a Juniper and Cisco router in a pair, both talking with each other running IS-IS, VRRP, etc.

mwcampbell 11y ago

Based on your other comments on this thread, you seem to have real expertise in operating this kind of infrastructure. Nevertheless, this particular comment makes no sense to me; I'm not even sure if you're serious. It does make sense to standardize on one open-source database package (MySQL in the case of my employer). But that's software that I can take with me anywhere. And it's open-source. So the risks of vendor lock-in don't apply. > Otherwise, why are you running stuff in the cloud anyway? How does it follow that if I don't lock myself into one cloud provider all the way, it's not worthwhile to use the cloud at all? Maybe using cloud providers is worthwhile simply because, at a certain scale, they're less expensive than leased dedicated servers, never mind the up-front cost of buying and colocating hardware. Also, it's easy to provision cloud VMs on demand, then throw them away when you're done with them. Those are good reasons to use cloud providers without locking into just one. It seems to me that the best approach is to use only the subset of features that are common to DigitalOcean, Vultr, and maybe Linode, and abstract over those multiple providers with software like Ansible that can access multiple provider APIs. I am indeed suspicious of proprietary solutions for deploying and migrating across cloud providers, such as Cloud66. But that's only because using one of those solutions would itself be an instance of vendor lock-in. If there were an open-source package with similar functionality to Cloud66, I would probably use it.

fanf2 11y ago

I thought the .com servers had been running Verisign's proprietary Atlas software since almost forever - 15 years?

scurvy 11y ago
I was referring to routers. They have to buy routers from someone.