Buy vs Build
Engineers, you owe it to yourselves to be thoughtful about the software you work on. Many of us have built bespoke platforms only to get burned out on the cost of maintaining and supporting them over the years, and there are other ways to learn about big systems that don’t require building everything from scratch. Bring your own creativity to the build vs buy discussion, and meaningfully engage with the question of where you want to focus your time and talents. You may find that you could have a more lucrative career if you become skilled at using and extending popular platforms, and there is no shortage of interesting work to be done in this space. Just don’t be the person who builds a glass sword.
https://skamille.medium.com/why-is-it-so-hard-to-decide-to-buy-d86fee98e88e
Every time we move up the ladder to a higher-order system, we have to make some tradeoffs. When we use a library, we lose some flexibility. Maintaining the library’s order is no longer our problem, but we have to live with their decisions unless we want to maintain our own fork. When we use a managed service, we lose even more flexibility – we lose the ability to change the system’s order altogether. Our system becomes harder to test, since it isn’t self-contained, which makes development slower and riskier.
There are big tradeoffs in terms of flexibility, development speed, testing, and more, and they all add up. But on the other hand, there’s the colossus that is entropy working every single minute of every single day to erode everything we dare to build. When I take stock of it, I’d prefer just about anything to fighting the second law of thermodynamics and the inevitable heat death of the universe.
Lock-in isn't just a function of the platform you use, but also of your application design. Expressing major design decisions using patterns significantly reduces
https://www.enterpriseintegrationpatterns.com/ramblings/loanbroker_gcp_workflows.html