“Build vs. Buy,” these choices seem to be constant in the lives of many DevOps Architects. End of the day, it all comes down to your business priorities and company vision.
For many companies, it makes sense to leverage software/tech that other companies have already created since they’ve invested thought, time and resources into making something that’s capable, resilient and performant. Buying tech/tool is almost always cheaper than developing an equivalent tool yourself.
Top comments (9)
This is a hard one, depends of many factors: what is the piece of technology you're trying to build or buy, time to market constraints, the quality of the off the shelf solution, company support, long term strategy and of course budgets.
There are things I would definitely "buy" or use like a web framework or a crypto library or those building blocks. Same thing, for example, for a imaging service, there's no point in building your own unless it's the actual core business (but even then, you could go the Heroku way and build layers upon layers to provide added value)
But sometimes is faster to build something in house or you have to do it because you inherit legacy code that you know could be better if only you could replace it with that library that everyone uses but there's no time or money to do it...
The cost of adopting "external" technology instead of building your own is the lock in in some cases (but who's going to write an alternative to Google BigQuery eh? :D) and in other cases the cost is just too high to justify the vendor solution: not all software is 10$ per month.
Another aspect of the build vs buy is the updates and maintenance. In house software requires maintenance but external one requires to be updated and monitored for security fixes and feature upgrades which can be a cost in itself.
I wonder what will happen if we all go the serverless route (which for a lot of use cases may very well be the ideal solution).
Whenever possible, and key to the whole discussion, it's important to build our own interfaces so that we can change between build vs buy if it comes to it. If you're decoupling things wherever possible then we don't have to make the perfect choice before we have all the info.
Today I might want to "buy" my "product recommender", but tomorrow I might want to build it. As long as I build with the mindset that I could swap out the internals for something else, I'm going to be safe.
Decent software design for the win :-)
I did something similar a couple of years ago. We had to switch from Parse to another provider for push notifications because they were closing shop so I did something like that, in case we had some issues with the new provider (Azure) and indeed those troubles came. The final switch to AWS SNS was definitely easier :-)
But are you considering the cost and effort involved?
I think building a good interface makes it easier to choose, perhaps, the fastest/cheapest option now, while opening up for the more solid option later.
Being good about having good patterns for interfaces within your app doesn't seem so much a "cost" as much as a good "habit" to be disciplined enough to undertake.
Yes, you pointed out well, updates and maintenance is another aspect we should be looking at:)
It can make sense to roll your own X in many situations, but the important thing to remember is that you have your own goal to reach and time you spend developing X is time you're not putting towards that. If someone else does X better than you could and there's no pressing reason to avoid it (expensive, difficult to integrate, etc), buy it.
there is a very interesting speech of Patrik Kua on Evolutionary Architectures where he address this question. If I remember correctly he says that if a product/tool is business strategic and it will change frequently it is a good choise to build it internally. He address other 3 situations, but I can't remember all of them right now.
Maybe the context was not exactly this one, but I think he shared a good insight on the matter anyway.
here is the video: youtu.be/8bEsNT7jdC4
Whatever tech is a differentiator between you and your competitors, you definitely build. (If another company can just buy a product off the shelf to become your competitor, then you aren't adding much value.) Everything else is fair game to buy unless no existing options suit your needs.