A huge dimension concerning the decision on using "unvetted" and/or "cutting edge" technology is how MISSION CRITICAL the system you are creating is...
Building a new social media app as a startup? _Depends on the data you're storing for users and how you market the stability of the system to your user base.
Building a new Government healthcare system? _You better use properly vetted technologies.
This includes using cloud service providers as well.
Some systems simply need to be old school. Old school tech relies on structured data that can prove better for security and for testing. Methods that have been in place over years are not only more reliable, the ways of fixing problems when they occur are well documented as well. Countermeasures to security threats are also well documented for older solutions, yet we also have to acknowledge, the Internet in itself is still a relatively new thing for business and commerce, so things these days are really declared as "Legacy" by companies and individuals who are selling alternative solutions as a part of the "new money marketing" pipeline, not because they are truly "out of date" or "no longer viable"... I am not defending nor advocating COBOL or mainframe systems with that statement though... (Just to be clear).
With newer concepts/solutions like blockchain, using unstructured data, and even cloud hosting, they are vetted to an extent, but they introduce very new threats into the stability of mission critical systems, and they are not perfect solutions. These newer solutions also by nature dictate costly refactoring for many that locks buyers into platform-specific situations that they can't easily migrate back if the ideas don't work out well, and compromise of data integrity or security for mission critical systems is more costly than ever as data builds...
Not every solution should enlist "cutting edge" solutions as their backbone. Even a gradual approach may be a more reasonable option (like introducing new technology in "siloed" and/or "smaller" aspects as a part or feature of a traditional system before a complete refactor (for example).
There are some really good reasons why COBOL programmers still get paid a lot of money to this day, even though I am not one mind you.
> There are some really good reasons why COBOL programmers still get paid a lot of money to this day, even though I am not one mind you.
I haven't found this to be true. It's one of those things that gets repeated, but as a former COBOL programmer, let me tell you that's not where the money is.
Building a new social media app as a startup? _Depends on the data you're storing for users and how you market the stability of the system to your user base.
Building a new Government healthcare system? _You better use properly vetted technologies.
This includes using cloud service providers as well.
Some systems simply need to be old school. Old school tech relies on structured data that can prove better for security and for testing. Methods that have been in place over years are not only more reliable, the ways of fixing problems when they occur are well documented as well. Countermeasures to security threats are also well documented for older solutions, yet we also have to acknowledge, the Internet in itself is still a relatively new thing for business and commerce, so things these days are really declared as "Legacy" by companies and individuals who are selling alternative solutions as a part of the "new money marketing" pipeline, not because they are truly "out of date" or "no longer viable"... I am not defending nor advocating COBOL or mainframe systems with that statement though... (Just to be clear).
With newer concepts/solutions like blockchain, using unstructured data, and even cloud hosting, they are vetted to an extent, but they introduce very new threats into the stability of mission critical systems, and they are not perfect solutions. These newer solutions also by nature dictate costly refactoring for many that locks buyers into platform-specific situations that they can't easily migrate back if the ideas don't work out well, and compromise of data integrity or security for mission critical systems is more costly than ever as data builds...
Not every solution should enlist "cutting edge" solutions as their backbone. Even a gradual approach may be a more reasonable option (like introducing new technology in "siloed" and/or "smaller" aspects as a part or feature of a traditional system before a complete refactor (for example).
There are some really good reasons why COBOL programmers still get paid a lot of money to this day, even though I am not one mind you.
Choose wisely my friends.