Buy Don't Build

The way I put this to clients is that you should own the bricks that your product is made of and not worry so much about the mortar. The bricks are the SQL queries, the logic inside the container images you run, the data stored in the tables and storage buckets. Oh yes, and the business relationships and brand equity.

As long as you're wiring those things together in ways you can replicate across cloud providers or in your own datacenter or on your own server in the closet, you've achieved the sweet spot in terms of deployment portability.

Running your own (Kubernetes cluster|database instance|pubsub system) on a cloud provider is crazy given that you now have at lease $150K+/yr piece of overhead in the form of at least one (dev)ops person. Save that expense for when or if you decide your needs have become predictable enough that you can start building your own software/hardware/network infrastructure.

Unless advanced devops fu is an important part of your company's mission or valuation, don't do it unless its saving you a lot of money over the alternatives.

A lot of the maintenance issues change with low code solutions, as do a bunch of other assumptions made in the article. We will be seeing a lot more low code developed without rigor by end user teams in coming years.

I think you had great boss (assuming he did not start timer each time you stopped typing on keyboard). Those endless meetings become unproductive pretty fast. I suspect that in big part they become a self sustained cancer used to justify time and salaries of unproductive company members.

As for the subject itself: frankly I do not see any advantage of hosting on say Azure over hosting myself. Either requires a good deal of maintenance. And no you can not really rely on Azure doing it for you.

Uptime for me is probably just as good on my servers as each one I have in my office also has ready to use up to date shadow copy located elsewhere. Azure is way more expensive of course.

The amount of hardware/processing power I have on my own server would cost me a fortune to have on Azure. Scalability does not matter much either because:

I am not Google and do not have to serve the rest of the world.

On top of that my servers are usually high performance native C++ applications that can handle thousands of requests per second sustainably and without breaking a sweat.

Vertical scalability with modern CPUs and multilevel storage is absolutely insane.

For Enchant [0], we followed the "buy don't build" philosophy a lot in the early years. However, the biggest challenge has been reliability.

For example, a service provider will have a 5H outage without any clear indication about what's going on or when it will get resolved. This leaves us in a difficult position to raise an incident with an unknown ETA where we can do nothing but wait. Then when it's all resolved, we either don't get a post-mortem or a hand-wavy one.

Or a service provider will lose data, which may have been minor to them but critical to our operations. And all we get from them is an "oopsie!"

So over time, we've ended up insourcing mission critical pieces (within reason) since we can engineer solutions with guarantees that are inline with customer expectations and our own targets.

Separately, in some cases, buying and integrating turned out to be a ton more work than what building in house would have been. Because when we build in house, it can be built to meet our full requirements in the first place.. whereas when buying, we may find ourselves working around limitations in the APIs provided to us.

0: https://www.enchant.com - shared inboxes, knowledge bases, live chat