3 ms·

I think your experience is interesting, because it seems like approximately the same small fraction of individuals as companies commit to "vertically integrated

I think your experience is interesting, because it seems like approximately the same small fraction of individuals as companies commit to "vertically integrated software"--that is you own everything top to bottom. That is to say almost nobody does it. For an individual that's excusable, it's a mountain of expertise and effort, although I imagine it pays off rather well in skills learning. For a company, not so much. Companies (and governments) have the ability to acquire the expertise they need to vertically integrate. Some do so when they see value in it, but it's rare. Why do so few make the choice?

okwhateverdude 2y ago
> Why do so few make the choice? Because it is risky. The more esoteric the knowledge gets, the further it moves away from your core business, the more in-demand the skills are. As an example, maintaining your own metrics and timeseries storage. It takes quite a few skilled hands to do this in house and probably only feasible for larger companies anyway. Or you can simply hand this problem over to DataDog. While they are pricey, it is potentially pricier to build your own internal DataDog-like system, especially if you consider the opportunity cost of pulling your most skilled engineers to build it instead of building your product that your customers are paying for. Companies are perfectly willing to pay a premium to not worry about something, and that includes not worrying about your very skilled engineers leaving and then needing to scramble because no one else understands what has been built.
- jcgrillo 2y ago
  There are three big risks I see in depending on vendors: 1. You aren't average. Market forces might not align with your use case. The pricing model might change, or it might happen that you find out later it doesn't scale well for your business. 2. They might leave you suddenly. For example, all the google "products" (quotes because there is actually only one--ads) that have disappeared over the years. Even when an open source dependency suffers a cataclysmic licensing event, you can still fork it and carry on, provided you've both chosen your dependencies wisely and hired the people capable of maintaining them. 3. By choosing a vendor you're making a commitment to ossifying a part of your stack. The observability example is a good one here. At the companies I've worked for who do all their logging, metrics, alerting, etc in-house, developers aren't afraid to use the tools. The tools adapt to the requirements, whether it's cost efficiency, features, whatever. At the companies where we've used vendors everyone's perpetually afraid of increasing the monthly bill, and nobody has a say in deciding what goes on the product roadmap. To be clear, this might be the right trade.
axegon_ 2y ago
Not necessarily. In my experience large corporations have a ton of internal tooling that no one knows about, even internally. Say in a company with 6000 employees scattered around the globe, tough luck knowing whether some developer made a one-off tool to debug something and used the company's LDAP to authenticate, and then the app connects to some db full of stuff. Years back I stumbled upon such a tool that had a web shell that allowed you to do pretty much anything using some dev's account - anyone with a company email could access it. This is far more frequent than you might think in large corporations. In small companies, typically everyone has access to everything and if that isn't the case, more often than not, you will ask someone to go and fetch something for you and the third time around, they will get fed up with it and give you full access so you don't bother them anymore. 6 months down the line, everyone has access to everything. Or if a small to mid-sized company sees people that clearly know what they are doing, they commonly give them full access to everything so they can get on with it. Like at my current job I've had root access to everything, everywhere since day 1.

okwhateverdude 2y ago

> Why do so few make the choice? Because it is risky. The more esoteric the knowledge gets, the further it moves away from your core business, the more in-demand the skills are. As an example, maintaining your own metrics and timeseries storage. It takes quite a few skilled hands to do this in house and probably only feasible for larger companies anyway. Or you can simply hand this problem over to DataDog. While they are pricey, it is potentially pricier to build your own internal DataDog-like system, especially if you consider the opportunity cost of pulling your most skilled engineers to build it instead of building your product that your customers are paying for. Companies are perfectly willing to pay a premium to not worry about something, and that includes not worrying about your very skilled engineers leaving and then needing to scramble because no one else understands what has been built.

jcgrillo 2y ago
There are three big risks I see in depending on vendors: 1. You aren't average. Market forces might not align with your use case. The pricing model might change, or it might happen that you find out later it doesn't scale well for your business. 2. They might leave you suddenly. For example, all the google "products" (quotes because there is actually only one--ads) that have disappeared over the years. Even when an open source dependency suffers a cataclysmic licensing event, you can still fork it and carry on, provided you've both chosen your dependencies wisely and hired the people capable of maintaining them. 3. By choosing a vendor you're making a commitment to ossifying a part of your stack. The observability example is a good one here. At the companies I've worked for who do all their logging, metrics, alerting, etc in-house, developers aren't afraid to use the tools. The tools adapt to the requirements, whether it's cost efficiency, features, whatever. At the companies where we've used vendors everyone's perpetually afraid of increasing the monthly bill, and nobody has a say in deciding what goes on the product roadmap. To be clear, this might be the right trade.

axegon_ 2y ago

Not necessarily. In my experience large corporations have a ton of internal tooling that no one knows about, even internally. Say in a company with 6000 employees scattered around the globe, tough luck knowing whether some developer made a one-off tool to debug something and used the company's LDAP to authenticate, and then the app connects to some db full of stuff. Years back I stumbled upon such a tool that had a web shell that allowed you to do pretty much anything using some dev's account - anyone with a company email could access it. This is far more frequent than you might think in large corporations. In small companies, typically everyone has access to everything and if that isn't the case, more often than not, you will ask someone to go and fetch something for you and the third time around, they will get fed up with it and give you full access so you don't bother them anymore. 6 months down the line, everyone has access to everything. Or if a small to mid-sized company sees people that clearly know what they are doing, they commonly give them full access to everything so they can get on with it. Like at my current job I've had root access to everything, everywhere since day 1.