The cost of vendor lock-in
There is no single day without some drama in the programming world. This time it's about Unity.
Unity is a game engine, and a framework to develop games. I don't develop games anymore, but game development has a special place in my developer-heart. I think every software engineer attempted to build MMORPG at least once in his life.
Recently, Unity announced a price change. They will be charging their users based on amount of installs. Here is the announcement from Unity, for you to read: Unity plan pricing & packaging updates.
But I'm not here to talk about Unity in particular. I'm here to talk about cost. And not the monetary cost. But rather the cost of vendor lock-in.
Many individuals, and companies, don't realize about vendor lock-in. They'd happily outsource their "dirty" job to third party PaaS. AWS is a good example. It's an incredible suite of software, but it has its limitations.
First of all—it's impossible to migrate from it. While under the hood they use standard tools, they are wrapped in such a nice package that infects your code base. And suddenly, you find yourself working with SNS/SQS API, rather than standard MQTT protocol.
Secondly, their knowledge is not transferable. Becoming a generalist DevOps engineer—is a good investment in yourself, because you can find a job in many companies. Being an AWS engineer, limits your knowledge to this specific product and companies that work with it.
Lastly, these companies need to make money. And making money for them, might mean raising prices. Which for you translates directly to increased expenses, because you can't easily migrate away from these tools.
I'm not saying that you should avoid tools that make your life easier. What I am saying is that you always, always, always need to take vendor lock-in, and it's price, in account when making a decision.