You’re always married to your infrastructure. That’s like developers writing “repository classes” just in case one day they want to switch from Oracle....
Statistically no one ever switches out their architecture. The risk is to great, the reward is too small, and the number of potential regressions is too high.
How did all of those people who wrote thier website with Angular 1 fare?
Are you going to rebut all of my comments about risk management in this manner (antagonistic, usually vendor lock in, but it's been about other risks as they relate to cloud infrastructure)? Because I work in risk management for a financial utility, this is what I do for a living: ensure developers and other practitioners don't make poor architectural and technology decisions.
One of your own comments [+] exemplifies the consequences of making a poor technology choice ("Amazon has been trying to move off Oracle for 5 years and it’s still expected to take two more. Moving off of an infrastructure is hard......"), and I'm pretty sure the cost of that choice and the resulting migration to remediate is expensive AF.
Was it a poor choice at the time? Apple decided to base the ITunes Store on WebObjects in 2001. They certainly didn’t have “vendor lock in” since they owned WebObjects, how does that decision look now in 2018 that they are still running on WebObjects?
You’re always stuck on your architecture and you’re always at risk of a technology becoming obsolete.
Look at all of the companies that are still stuck with an older version of the JVM because they are afraid to upgrade - and thier whole stack is open source.
Unless you personally audited every single line of source code your developers wrote, I guarantee you that your architecture is tied to some assumption that will make it hard to migrate in 5 years.
We audit every single line of code written by our developers. We audit every line of libraries they use. We audit their architecture, their infrastructure, and their plan to move from cloud to bare metal at anytime. Our applications run for decades at a time.
We automate wherever possible, of course, but there are some tasks humans are required for.
It doesn’t hurt for developers here to heed the warnings from professionals who deal with this every day. While the scale is orders of magnitude different, the underlying fundementals are the same.
And you can 100% guarantee that all of your infrastructure dependencies won’t be obsolete in 5 years or any company or open source project won’t be abandoned and that every vendor you depend on will always be acceptable and that you can switch with low friction and no downtime?
Does your company have the luxury of building everything in house?
Yes. And we can if we want to, yes. We’ve taken over open source projects we rely on, but most anyone can do that. We’ve built open source versions of seven figure commercial software just to ensure we have the skills in house to do it.
You don’t need to have thousands of employees or billions of dollars in revenue to accomplish 60-80% of what I’m describing. I’m simply arguing to take measured steps at critical junctions in your software’s lifecycle.
I can tell you with 90% confidence that if you’re working for a financial institution that offers bill pay, your entire bill pay infrastructure is dependent on a third party provider. I know the provider.
If you offer an iOS app, you’re dependent on closed source software. Your project management software would be a beast to migrate, etc.
Are you really suggesting that every company should “take over” every open source project they depend on and build “open source versions of commercial software?”
I’m no more saying it was a bad idea at the time than Apple basing iTunes and later the App Store on WebObjects. If I’m consulting a startup that needs to move fast and get off the ground, I’m not going to tell them to worry about “vendor lock-in”. I’m going to tell them to use a cloud provider, use whatever “proprietary lock in” technology they need to to help them move fast and get funding and later if they grow big and they see thier needs change, then maybe suggest an alternative when it makes sense to hire a bunch of internal netops people to babysit servers.
But get a developer who knows there way around AWS/Azure and hire a third party company that can do some of the heavy lifting will save a lot money.
Yeah I consider myself one of those people. I think I can go toe to toe with most “AWS Architects” that only know netops especially since most of them don’t know development or devops on AWS.
I was turned off from Oracle over 15 years ago when I couldn't find a price on thier Webster - buying anything from Oracle is like dealing with a car salesman. At least MS gives you upfront pricing. There are some nice features of Sql Server if you're using other peoples money. But it wouldn't be my first choice.
