Yeah, vendoring doesn't fix this problem as the sibling comment says. To be clear, I'm aware the team is aware of the inadequacies of the current system and is working on fixing it -- just saying that this doesn't work well now :)
Governments and other bigco's are still as willing as ever to lock themselves into vendors. I don't see this changing soon at the OS level when they can't even sort themselves out at the application level.
We’re not buying into IBM mainframes anymore and although there are still customers tied to Oracle databases, vendor lock-in just isn’t that big of a deal anymore.
I want to say I know the pain of vendor lock-in. We use an open source PaaS solution and it works well for the most part but the solution doesn't really scale the way I want it to be, and doesn't provide all the utility I consider to be crucial for a successful PaaS. Whether moving away from it has always been an interesting discussion at work. So I and my collagues are careful now with what to include in our technology stack pofotilo. I can't just have someone randomly decide to add a Redis to the dependency when the purpose is just a key-value store for some trivial task.
Anyway, the problem started with bad management to be honest, which I don't think my case is too rare to hear. When the first project rolled in, we ran PaaS on a single provider, but more projects joined, it was time to choose another vendor because of better equipment and better deals. Yet, none of them really provide good resiliency.
With the third vendor probably around 12-18 physical servers were purchased and managed by the vendor. It was openstack. That version of OpenStack at the time was not compatible with AWS, which later becomes our 4th vendor, and runs our dev environment. You want to run additional performance testing, well, we can't get the same elasticity as AWS because we only have so many physical servers to provision VMs, but that's where our real data lives. So we had to do our QA on AWS and doing the data copy can take a whole business day. The script we wrote for Amazon doesn't work on OpenStack. Security, network, I/O metrics are not consistent across vendors. That adds complexity to code. I know exactly how to abstract things, but just trust me :-) it really makes code hard to maintain, and really painful to integrate with multiple vendors. As a matter of fact, I don't like working with AWS API (with boto) myself because API response formats are inconsistent!
Finally, we got rid of one of them, then two and finally we are on the final stage of consolidating everything on AWS and focus on infrastructure automation and lower the number of chores.
Like many projects out there, things usually start out real nice, but then once you get too busy fighting fire here and there, you will accumulate some debts. If one is not careful, the debt can backfire and we had our lessons. There is no resiliency in most of the other vendors because they require you to purchase more servers and they themselves have hard time to go true elasticity. AWS, at least, for the most part, doesn't run out of instance availability that often (it happened a few times to our EMR processing). I do have some issues with AWS myself, but so far, AWS seems to be the only true cloud provider you can hang on to for several years.
Before building a grand multi-vendor infrastructure, build on a single-vendor well, then decide on the next step.
I found the article's stance on vendoring to be quite restrained. I can't wait until Dep becomes _the_ solution. That and getting rid of GOPATH (I work across multiple machines, and need to bootstrap new environments regularly).
reply