[HN Gopher] Buy Don't Build
___________________________________________________________________
Buy Don't Build
Author : jrott
Score : 131 points
Date : 2020-12-12 16:22 UTC (6 hours ago)
(HTM) web link (jrott.com)
(TXT) w3m dump (jrott.com)
| blargmaster42_8 wrote:
| This an ad
| tus88 wrote:
| > It's usually a major mistake, that ends up costing a ton of
| time and money
|
| LOL this is hilarious. Because outsourcing to consulting firms
| (cough IBM cough) has never resulted in blow-outs and poor
| delivery.
|
| Buying almost always means being trapped in a snake-oil contract
| that requires ongoing consulting costs that quickly outweight the
| costs of the actual software.
|
| > This can be avoided by making sure that the key differentiators
| for your business are in-house.
|
| Oh....so you are saying we _should_ build now?
|
| Blogpsam.
| phsource wrote:
| I'm totally on board with the overall message that building (i.e.
| engineering) your own internal tools come with lots of overhead,
| but take issue with this one point:
|
| > My counter-argument to that is there is also lock-in with
| internal systems. The most common version of this is the keeper
| of the spreadsheet.
|
| The author then disparages spreadsheets as becoming the exclusive
| domain of one employee who wouldn't want processes to change.
|
| In reality and my experience, though, spreadsheets are one of the
| most versatile and accessible systems, and their close cousins
| (Airtable, Notion) great as well! You can customize it to your
| own processes and they're pretty universally understood, so the
| barrier to change is pretty low.
| jrott wrote:
| Author here I actually think spreadsheets are great because
| they are so accessible. What isn't great though is when there
| is a business processs that is a spreadsheet and knowledge that
| exists in one persons head.
| holri wrote:
| It is a management failure when this is in only one person
| head. Outsourcing tools will not solve internal management
| problems.
| rantwasp wrote:
| i don't think it's the spreadsheet itself. it's about the
| process and people who defend the process no matter what
| systemvoltage wrote:
| > their close cousins (Airtable, Notion) great as well!
|
| Their close cousins are locked, proprietary, slow, bloated,
| exceedingly complex, poorly designed (ui/ux), emojized, vc-
| backed feature extravaganza and have a subscription fee.
|
| Experts of Excel use keyboard exclusively, their keystrokes are
| a melody of efficiency, expressivity and productivity that is
| continued to be mocked in similar fashion as the 2007-era Mac
| vs. PC advertisements.
| cma wrote:
| Excel has a subscription fee as well.
| systemvoltage wrote:
| Yeah unfortunately. We still have a 2016 Excel license and
| will continue to use it.
| smnrchrds wrote:
| You can buy the 2019 version as well. So far, Microsoft
| has given their customers the choice between one-time
| purchase and subscription.
|
| https://www.microsoft.com/en-us/microsoft-365/p/office-
| home-...
| tenaciousDaniel wrote:
| I found Notion to be fairly simple to get started. Whereas
| when I opened Airtable my head exploded and I closed it
| immediately and haven't revisited it since.
| systemvoltage wrote:
| I agree. Notion is a lot easier to get started on. I also
| should mention that Notion/Airtable vs. Excel are somewhat
| different types of swissarmy knives to be used in different
| environments. One is used in the battlefield and space
| exploration, the other one in a children's playground.
| Jokes aside, Notion has some nice features like Wiki and it
| wears too many hats like a joker in a circus. I love the
| fact that I can write a recipe with tables and markdown ->
| publish it to the internet to be consumed. Can't do that
| with Excel.
| serial_dev wrote:
| And it's also important to keep in mind that if your team is
| using various external tools, there is a high chance that only
| a couple of people will actually know how those tools work and
| even less of them will be able or happy to use those external
| tools.
| crave_ wrote:
| It's also a strawman argument.
|
| The alternative could instead be a system with open standards
| that many vendors implement, and _only relying on standardized
| behavior_.
|
| This works to some extent with for example SQL or C, where you
| can migrate from one DB or compiler to another with limited
| effort.
| cortesoft wrote:
| All of this is true, but sometimes people forget that buying a
| solution doesn't mean there will be no work. Sometimes, the
| integration and maintenance of that integration ends up being
| more than building and maintaining your own solution, especially
| if you have to do any large changes to how your systems work in
| order to integrate.
| pjc50 wrote:
| Ah yes, this is how SAP and Oracle make their money: you "buy"
| a "COTS" solution, and then spend ten times as much having them
| build something for you .. which in the end you don't own.
| blackoil wrote:
| That is why likes of Office 365 are popular, each component
| individually may not be best, but you get dozens of apps that
| are active in one go, for most parts are integrated well and
| have a simple billing.
| mauriziocalo wrote:
| +1. And I'd add to that that sometimes there's significant work
| in the _pre-buy_ phase as well:
|
| - Researching what your options are / what's already out there.
|
| - Comparing different alternatives.
|
| - "Hopping on a call" with a sales rep to get a product demo
| (there's this super annoying trend where many SaaS companies'
| landing pages don't explain what they do and the only option
| they give is to "schedule a demo").
|
| For CRUD-like internal tools or simple 3rd party integrations,
| my experience has been that it's often much faster (typically <
| 1 hour) to build a production-ready app on Retool
| (https://retool.com) than it is to even get started with SaaS
| vendors.
| Scarbutt wrote:
| Many in the "serverless" all crowd are blind to this.
| victor9000 wrote:
| While I agree with this comment, if someone buys and ends up in
| the position you describe then they did a poor job at buying.
| dnautics wrote:
| there may be no options. For example, I (profitably) ran a
| small cloud. My supervisor kept questioning me "why don't we
| just use openstack instead of your software"? The answer is
| even in this article!
|
| > Most enterprise systems require an engineering team to keep
| them running.
|
| If we wanted a team of 3+ to run the cloud then we could buy
| openstack, or cloudstack, probably 2+, but that's also
| without pushing features. And suddenly we wouldn't be
| profitable anymore. I left, so I guess they will find out.
| aeternum wrote:
| Nowadays you're often buying SaaS so not only do you need to
| ensure the product is a fit currently but you must predict
| the fit going into the future.
|
| It's not an easy thing to do. I've found that open source
| libraries are often more stable, require less ongoing
| maintenance due to API changes and have better support
| lifetimes compared to the SaaS equivalent.
| jeromenerf wrote:
| Not always a poor job, but sometimes a bet that turns out
| wrong. I have seen great products and companies disappear in
| unforeseen mergers or API prices skyrocketing for instance.
|
| Risk is low for commodities, but high for anything
| "disruptive".
| JMTQp8lwXL wrote:
| The people that have to perform the technical integration
| between two independently developed products (and could warn
| that the integration work is more involved than starting from
| scratch) are a different group from who decides the
| acquisition is happening.
| q3k wrote:
| That's very true. Especially for tooling/products/services that
| sells themselves as shrinkwrapped products that only allow for
| a particular flow - sometimes reimplementing your own subset
| from scratch that's geared towards your usecase is less effort
| in the long run than hacking around a blackbox solution.
|
| I'd much rather occasionally work on feature for a well-
| engineered internal reimplementation than constantly fight with
| shellscripts wrapping around a solution with a huge impedance
| mismatch.
| themodelplumber wrote:
| Exactly. I've even had this happen with things like CSS, where
| a master stylesheet changes somewhere upstream on another
| server, and hundreds of hours of my own custom, vendor-
| supported modifications now make my web application or website
| look like doo-doo.
|
| Plus maybe I'm weird but I think it's enough to love the energy
| you can get from building something. It's fun. And considerable
| portions of work should be fun. Especially if you work for
| yourself, where building stuff for money, for other people,
| often isn't enough without a strong connection between the
| work, customer, and the subject's own interests and values
| system.
|
| (IMO a lot of those kinds of projects also build on the edge of
| one's core expertise, extending it outwards, almost like a
| recon mission, so it's less of a binary yes/no core expertise
| condition.)
| lexicality wrote:
| My job involves a lot of integration work so I'm probably
| biased, but I find successfully cracking open a poorly
| documented API and extracting all the data in a usable way to
| be deeply satisfying, especially if you can be confident
| enough in your edge cases that you think it'll run until the
| next unannounced and undocumented change comes along.
| yawnxyz wrote:
| or in Notion's case, a complete lack of documentation...
| marmaduke wrote:
| > I think it's enough to love the energy you can get from
| building something
|
| I think this is good if you can get there. The IKEA of
| software is pure dopamine. If had to grow and saw those trees
| less so. If you are pouring concrete and get it delivered,
| pure dopamine. If you have to crush the aggregate by hand,
| less so.
| NoOneNew wrote:
| True. At that, one thing about the buying vs building argument
| that's missing is picking and choosing your battles.
| Competitive advantage comes from that. Build what you are
| capable of producing effectively based on your environment.
| Obviously you can run into roadblocks, but part of being an
| adult is planning and adjusting based on your circumstances and
| needs, not along someone else's. Too many of these arguments
| fall into the realm of, "Everyone, listen up! I have the single
| solution for everyone's problem for all of eternity!"
| gentleman11 wrote:
| In unreal and unity, most of the third party code I've tried to
| use ended up unusable because of either bugs, performance
| issues, or limitations. There are great exceptions but it's
| been frustrating overall. The ones that do work, well, the
| documentation is often terrible and it takes longer to learn
| and integrate than it would to make your own. Finally, unity
| has a history of retroactively changing their terms of service
| to squeeze more money out of you for asset store buys, so it's
| scary to trust them. I write a lot more of my own systems now.
| CyberDildonics wrote:
| Unity also changes their APIs around with every tiny version
| increment, meaning that any app store package has to be
| constantly on top of installing new versions of unity and
| updating all the little parts that break every week.
| gfxgirl wrote:
| unity (and maybe unreal) have a real problem in that the
| majority of users are hobbyists, students, and new
| programmers. None of them are really willing to pay much for
| 3rd party code and they need $$$$$$$$$$$$$ of support because
| they are new.
|
| For example make a JSON serialization library and you'll be
| asked "how do I spawn enemies from JSON" which is arguably
| entirely orthogonal to your library but don't answer and get
| downvoted for bad support. Do answer and you'll just be asked
| more questions about how to adapt your example to their
| personal project and you'll have to teach them programming in
| the process.
|
| These incentives make it almost impossible to make money
| selling 3rd party code (plugins/add-ons). If you charge what
| it should really cost given the amount of work put in the
| market won't bare it. If you charge what the market will bare
| you'll go broke.
|
| Maybe Unity should split the market into "Pro" and "Hobbyist"
| and the Pro market would have prices more inline with what it
| actually costs. Check out the prices of libraries like
| Radgametools.com (you'll have to google the prices) for
| comparison.
| pc86 wrote:
| We recently purchased an enterprise scheduling software that I
| will not name (you may have heard of it, but it's unlikely).
| Told numerous times throughout the sales cycle by their
| architects and engineers that their API could do all the things
| we needed "easily" and that they could finish off the last few
| features we needed within 2-3 minor releases.
|
| Fast forward almost a year, at least 7 releases, and probably
| $200k of payroll on our end and their product barely runs, and
| doesn't handle all of our standard workflow, let alone edge
| cases. Best we can assume is they were writing the API from
| scratch because we needed it and didn't have the skill to do
| so. Documentation was offensively bad when it was correct,
| which most of the time it was not, to the point where there
| were several instances of the endpoints in the docs being
| wrong, causing us to call support to ask what the real
| endpoints were we were supposed to be calling.
|
| All this to say yeah, buying is great if the company is
| professional and has a well-documented product, and the sales
| and technical pre-sales folks know what they're talking about.
| But that isn't necessarily the case, even for six-figure
| purchases. And when it's not the case you can easily burn a
| non-trivial amount of money before you ever realize it.
| corytheboyd wrote:
| I have been in the boat of the company that ripped you off
| before. Sales will promise the world, product/engineering
| caves "just one last time" to help win the deal with the
| easiest shittiest thing. Years go by and things inexplicably
| break all the time.
|
| It's such an easy trap to fall into, because I hear similar
| stories all the time.
|
| I guess the moral of the story is to assume sales is lying to
| you until proven otherwise? Haha not sure, just do as much
| research as you can but you'll probably get burned anyway
| from time to time
| ethbr0 wrote:
| Why don't more companies mandate that their engineers talk
| to the company's engineers, alone, in an unrecorded room,
| before agreeing to buy?
|
| I mean... talking to people with every incentive in the
| world to stretch the truth and/or little technical acumen
| doesn't sound like a recipe for success.
| JoeAltmaier wrote:
| You get in a room with Intel, you have to sign a waiver
| that gives Intel total property over everything discussed
| in that room. Even your own products, if you happen to
| mention something about them. No sensible company will
| let their Engineers in an Intel conference room, if they
| have any sense.
| ethbr0 wrote:
| Granted! But it seems less of a case in the SaaS B2B
| horror stories that come up frequently.
|
| I'm assuming Salesforce (e.g.) isn't going to suddenly
| pivot into Lyft-for-dogs, or whatever the product is.
| pixl97 wrote:
| Because vendor companies have figured out you wine and
| dine the C level and pretend that engineers didn't exist.
|
| I'm pretty sure my company wouldn't put me on the front
| lines during sales for reasons like this
|
| Customer "How are you at X and Y"
|
| Me "Oh, our X is really good, on the other hand our Y is
| utter shite"
|
| Sales rep next to me: _evaporates_
| ethbr0 wrote:
| Isn't that a win for everyone except the sales rep
| though?
|
| If the deal closes, Z% of the company ends up being tied
| up in trying to kludge Y into doing what was sold,
| spiking engineer burnout and lowering morale, and
| furthering a negative relationship with sales.
|
| Plus you've now pissed off your new customer, by lying to
| them.
| rendall wrote:
| Alas. Then the company doesn't get the contract, while
| the next company who lied, with a bright white smile,
| does.
| corytheboyd wrote:
| I've been on calls almost like this. What you get are
| solutions/sales engineers accompanied by sales. They're
| all generally helpful, including the engineer to engineer
| conversations. I've even been in a position where a
| representative of a vendor worked directly with us for
| months, yet the same issues kept coming up ultimately
| leading to the project being scrapped. It's a weird world
| where everyone is trying to sell something to everyone, I
| really don't like it
| jrochkind1 wrote:
| Good article, I am definitely filing away to pull out in some
| future team discussions.
|
| This paragraph is confusing me, either it's missing a 'not' or
| something, or I'm just confused. Is anyone following?
|
| > The question you should be asking is what else could be done
| instead of tuning your own stuff or building a new internal
| system. The answer is usually spending more time coming up with
| the correct architecture instead of fighting fires or developing
| actual customer-facing features.
|
| Instead of building internal systems you would be coming up with
| the correct architecture instead of fighting fires or developing
| actual customer-facing features? Wait, what? there are too many
| 'instead of's in there and i'm not sure they are all meant how
| they are said.
|
| I think developing actual customer-facing features is the goal,
| but here it sounds like the thing you would like to avoid... and
| I'm not really sure about fighting fires (ideally you want a
| system where you do less of that, right?) or coming up with the
| correct architecture (?).
| jrott wrote:
| Yeah developing actual customer facing features is the goal.
| That paragraph needs to be edited
| [deleted]
| Silhouette wrote:
| The longer I run small businesses, the more sceptical I become of
| this sentiment. I wrote a cathartic rant here at first, about all
| the different ways external services have let down my businesses
| over a period of many years and how often our in-house systems
| have been the only thing that kept us going in those situations.
| But instead of letting rip and naming names in rather undignified
| fashion, I have decided to settle for just posting the
| conclusion.
|
| I _want_ to agree with the principle that you build what is
| essential to your business and you buy in the rest. As both an
| entrepreneur and a developer, I _want_ to focus on the unique,
| value-adding parts of whatever my business is doing. I _want_ to
| let someone else handle the mechanical stuff and the formalities,
| and I have no problem with paying a fair price for that.
|
| But that whole argument is predicated on the idea that
| outsourcing will get an overall better result than building in-
| house, so that in some way it saves time and/or money that you
| can better invest elsewhere. So many services we've used have
| changed or discontinued functionality and forced us to relearn or
| reintegrate just to avoid going backwards, so many services we've
| used have pushed their prices up in real terms while adding
| little of extra value to us, so many services only ever reach 75%
| of what we'd like from them and the missing 25% of functionality
| hurts more and more, so many services we've used _just don 't
| work_ so often that you wonder how they manage to stay in
| business at all, that I now find it hard to trust or expect good
| results from any external service at all.
|
| Sometimes you have no choice about outsourcing. No small business
| has the resources to do some things, particularly in heavily
| regulated areas like payments and tax, or in large-scale
| infrastructure like operating a data centre, unless that is part
| of the purpose of the business. So you choose the least of evils
| and hope for the best.
|
| But today, as someone just starting to set up another business, I
| am looking for services that handle _everything_ in a particular
| area where for practical reasons we can 't do it in-house. I want
| to specify what we need, and have it done and the results
| delivered. I don't want to care about anything in between. I
| don't want to be distracted by any related legal and regulatory
| compliance matters. I just want the job done, properly and
| legally, for a reasonable price. I have little interest in
| working with anyone offering less than that, unless I have
| absolutely no choice.
|
| Maybe this means I actually do agree with the original principle
| after all, and I've just learned from experience that an extreme
| interpretation of it is the way to go.
| CapitalistCartr wrote:
| Building anything is step 5 of a good process, not step one.
| Whether you buy or build is far secondary.
|
| First, check the motivations. Emotional or logical. If the
| driving motive(s) is ego, that's already a big, red flag.
| Consider running like a bull in reverse.
|
| Second,intel. Gather information about the situation; educate
| yourself. Find the apples on the road.
|
| Third, formulate a vision, an image of the final result that all
| the stakeholders (those whom you cannot ignore, no matter how
| hard you try) agree on. This is where beautiful diagrams are
| created. Which don't matter. All that matters is each stakeholder
| signs & dates it.
|
| Fourth, plan. Use your knowlege gained in step two to formulate a
| plan for getting from the current situation to the "vision".
|
| Fifth, execute said plan. Find more road apples.
|
| Sixth, debrief. Analyze the outcome. Get a drink with the ones
| who did the work.
|
| This can all boil down to just you spending 2-3 days running
| around doing it yoursels, or multiple teams spending most of a
| year herding cats. The important part is knowing the steps, and
| mentally looking for them. And for those who push to skip.
| rq1 wrote:
| Sorry but no.
|
| It's cost dependent and you should carefully study both options.
|
| It's part of the engineering: study fixed and variable costs.
|
| Outsourcing is cost effective when the market is mature enough.
|
| You should maybe not rebuild cloudflare's core services to
| operate a website.
|
| Depending on your scale, you certainly should build your own ML
| stack for instance.
| burnte wrote:
| Meh. In 2007 I wrote a webapp for a friend to help him manage his
| business. It's in PHP and other than a few fixes here and there,
| it's running just fine in 2020.
| say_it_as_it_is wrote:
| And then the day comes when you've been laid off and your lack of
| product development expertise keeps you from a world of
| opportunity.
| mlthoughts2018 wrote:
| I think all four points in the article are deeply wrong.
|
| 1. It is easy to run your own services. You should be investing
| in internal developer tooling that makes this easy, and in fact
| that developer tooling should sit in front of any vendor solution
| you ever buy so that the way it integrates with your alerting,
| monitoring, data exporting, etc., is completely standardized to
| be uniform with service delivery in any other system in the org.
|
| 2. and 3. You do need complete control over what the application
| does because it absolutely always is unique and special on a per-
| use-case basis every time. A good example is search. Anyone who
| thinks search is a commodity service you can just throw
| ElasticSearch or Algolia in front of is sorely mistaken and
| dangerously naive. Every different search use case is going to
| have different success criteria, different data privacy concerns,
| different timeliness and freshness concerns, etc. and you need
| business software to control these elements in ways that fit into
| standard internal product management and QA procedures.
|
| 4. Vendor lock-in is a critical problem. If you choose GCP vs
| AWS, you are defining _culture_ and you are defining
| experimentation and exploration that you _cannot_ do. You're
| essentially cleaving away many future possibilities from _even
| being testable_. It's much worse than just having a crufty old
| system to maintain, it's about brittleness and lack of ability to
| appropriately empower engineers to consider whatever part of the
| solution space _they_ decide is needed. Companies that "get it"
| will prioritize "ease of swapping" so that you can constantly
| improve and leverage autonomy without needless parochial
| constraints on what can be considered. Thinking, "yeah but just
| buying it solved our problem today" is such a death knell of weak
| leadership who cannot fathom strategy or how to leverage real
| solution ideation from their staff.
| blakesterz wrote:
| I think he's right, if you're at a small/medium sized place, all
| the reasons he lists there are solid reasons to buy and not build
| things for yourself. That being said, there's no reason to make
| that an absolute rule, I think it's ok to build some things and
| buy some things. Just think of all the things we've ended up with
| because someplace built some thing and it ended up being some big
| thing that we all know. Isn't that how Slack and Docker both got
| started?
| libria wrote:
| > The desire to build custom versions of everything seems to come
| from a few places: 1 [...] 2 [...] 3 [...] 4
|
| There are personal reasons as well:
|
| 5. Innate curiosity and excitement about technology
|
| 6a. Get experience
|
| 6b. Resume talking point
|
| Many of us picked a career in IT because just like building
| things out of Legos is fun, building a streamlined full CI/CD
| pipeline is fun, building a full stack application is fun, etc.
| Speaking of career, one needs to acquire experience in the new
| technologies to pad their resume and it's convenient to do it on
| company time.
|
| I'm not justifying putting your interests ahead of your
| company's, but understand that's what some of us do. I'd say #5
| and #6 are often stronger drivers for decisions than #1-4.
| simonw wrote:
| One thing to pay close attention to when making a build v.s. buy
| decision is the impact that billing models will have on your
| usage of a tool.
|
| Take logging for example. If you buy a log aggregation platform
| like Splunk Cloud or Loggly the pricing is likely based on the
| quantity of data you ingest per day.
|
| This can set up a weird incentive. If you are already close to
| the limit of your plan, you'll find that engineers are
| discouraged from logging new things.
|
| This can have a subtle effect on your culture. Engineers who
| don't want to get into a budgeting conversation will end up
| avoiding using key tools, and this can cost you a lot of money in
| terms of invisible lost productivity.
|
| Tools that charge per-head have a similar problem: if your
| analytics tool charges per head, your junior engineers won't have
| access to this. This means you won't build a culture where
| engineers use analytics to help make decisions.
|
| This is a very tricky dynamic. On the one hand it's clearly
| completely crazy to invest in building your own logging or
| analytics solutions - you should be spending engineering effort
| solving the problems that are unique to your company!
|
| But on the other hand, there are significant, hard-to-measure
| hidden costs of vendors with billing mechanisms that affect your
| culture in negative ways.
|
| I don't have a solution to this. It's just something I've
| encountered that makes the "build v.s. buy" decision a lot more
| subtle than it can first appear.
| gshulegaard wrote:
| I love this comment because it articulates a dynamic that I
| think is often overlooked much better than I could. I might
| even go a step farther and suggest that anything that is core
| to your business flywheel should be built and not bought (in
| general).
|
| Mostly because you don't want pricing to act as a disincentive
| to exercising the flywheel.
| telesilla wrote:
| We've often gone down the route of 'modify an open source
| project' for this reason. For the price of a developer, we get
| the product in perpetuity and don't have these exact
| limitations you specified of headcount or worrying about usage.
| For almost everything out there, you can find a version of it
| that's been made available with source code. Granted, unless
| you are essentially a software company this is probably
| difficult to maintain, given the additional level of expertise
| required.
|
| Another option we've found works is buy, to just get started,
| and invest moving forward in our own project. Getting something
| off the ground quickly tends to help us understand better the
| requirements.
| WrtCdEvrydy wrote:
| Honestly, I'm fan of the open source self hosted (especially
| if only some of the enterprise features are paid). We set it
| up, configure it, evaluate it and buy the enterprise license
| (it's usually a per-box license).
| tixocloud wrote:
| Very interesting perspective. Ran into the same issues where
| Salesforce was charging us by the number of columns we had that
| ended up forcing the team to overload a column with a JSON
| object so we could get it to work without overpaying.
| Integration and maintenance turned out it be a downright
| nightmare. Would be interested to hear various pricing models
| to understand the pros/cons for each especially in the
| logging/analytics space. Does per storage, per event, per user
| make sense in certain cases?
| nitrogen wrote:
| For things that are directly generating revenue, it makes
| sense to have per-X pricing because it aligns your vendors'
| interests with your own. In that case, you want to
| incentivize the vendor to maximize your usage, because that
| usage is making you money.
| [deleted]
| [deleted]
| mchusma wrote:
| The answer here is not so simple as "always buy". It depends
| heavily on context.
|
| I think there are some things that do make little sense for
| anyone to build unless it's super core. These tend to be low
| level, cheap developer tools that do a couple of things well.
|
| Trying to "buy and then integrate" larger pieces of software is
| often more work. Lots of people "buy" because they don't
| understand the problem. It's a mental opting out. This leads to
| disjointed experiences internally and externally.
|
| But it all depends on your situation.
| whoisjuan wrote:
| I own a Screenshot API service (shameless plug:
| https://getscreenshot.rasterwise.com/) and this exactly the
| argument that I make for small utilitarian services like mine.
| You shouldn't build them because buying them is several orders of
| magnitude cheaper.
|
| I have a small paragraph from a blog post where I explain this
| with some math that is probably crappy but captures the idea:
|
| _" When you spend time in areas that are not the core of your
| product, you're actually being financially inefficient. Taking
| screenshots is likely not a core task of your business so it
| doesn't makes much sense to waste development resources in this
| area.
|
| Here is a brief example of how inefficient it gets:
|
| A mid-level developer in a small market earns $90K USD per year,
| working 40 hours per week. His/her effective hourly rate is $47
| USD per hour.
|
| Writing a basic implementation of a screenshot utility will take
| at least 5 hours. But this is just a simple prototype. Many use
| cases will need to be addressed, and there's likely going to be a
| large amount of time spent in optimizing, securing, provisioning,
| testing, etc.
|
| A realistic utility that can be used for a development workflow
| is going to take at the very least 30 hours of development time,
| but likely more.
|
| Other un-accounted areas of development time are: documentation,
| training and maintenance.
|
| Given this scenario is very likely that writing a semi-good
| solution will take more than a week and maintaining it, will take
| at least an hour every month.
|
| This means that writing this solution will cost almost $2000 USD
| of development time plus another $500 USD or so, just to support
| it every year. And of course, this doesn't include the cost of
| the infrastructure you're paying to run it."_
|
| My argument is that the more utilitarian the service, the more
| cost-effective that is to buy it instead of writing it. Writing
| it could be simple but there's a drain in engineering resources
| when you try to maintain it in the long run.
| [deleted]
| ianmcgowan wrote:
| As an aside, love your Lincoln, Hamilton, Jackson pricing plan,
| super creative!
| whoisjuan wrote:
| Thanks! I wanted to do something creative with the pricing.
| :)
| ummonk wrote:
| I think the screenshot service is a perfect example of a
| service suited for buy don't build - it's something complex to
| implement but with a really simple API to integrate with.
| mewpmewp2 wrote:
| That's cool. How much money do you make with that service?
| whoisjuan wrote:
| About $500 USD/month. Haven't put too much effort to promote
| it though.
| monadic3 wrote:
| This doesn't account for vendor incompetence at basic customer
| support, which is far and away the largest reason to avoid
| renting commodity services. Being able to debug and fix things on
| demand without waiting on another party is massively valuable.
| zmmmmm wrote:
| It's interesting that the whole article is pitched around a
| context where there is a basic assumption that there is a whole
| engineering team, devops etc., and the question is about how
| their time is best utilized. But if you chose to buy instead of
| build _everything_ most of that would not exist.
|
| So there's a paradox I see which is akin to the credit system
| where only people who don't need credit are offered it: you can
| only "afford" to buy instead of build when you _have the
| engineering competence to build_ - that 's when you can
| intelligently choose not to.
|
| On the other hand, if you lack the internal competence to build
| and for that reason choose to buy? That's when all the bad things
| happen. You're going to get screwed by your vendor - they are
| going to know you aren't technically capable of supporting
| yourself, they will give you stupid timelines, blown out costs,
| unreasonable constraints ("it has to have a 16 core, 256GB RAM
| server or we won't support it") etc etc. You _will_ end up with
| the worst case of vendor lockin and a system everybody hates.
|
| So one of the pitches I make when people are making this decision
| is that you should be building at least some things, because the
| strategic cost of not doing that affects everything else you do.
| figers wrote:
| A huge customer went with our custom build software because we
| controlled everything, all built in house, we could integrate
| with them exactly how they wanted vs a competitor who bought
| their technology platform and couldn't control the changes asked
| for...
| bird_monster wrote:
| I work at a small startup. My boss comes from only enterprise
| level companies. My boss believes literally everything we touch
| has to be custom, and we have to make it. It's an incredibly
| exhausting process of getting in front of and/or retroactively
| nullifying any planning the company does based on his
| suggestions, because most of the time they're quite harmful to
| our startup's tech. I've gone to our CEO about it and he agreed
| that we have to curtail this behavior whenever we see it. It's
| just an extra layer of "stuff" I have to think about.
|
| No, we don't need k8s, Kafka, a home rolled CDN, custom
| authentication, etc.
| bobbydreamer wrote:
| This blog has only one article
| rachelbythebay wrote:
| It's not buy vs. build. It's _rent_ vs. build.
|
| Unless you are actually purchasing whatever it is you're using...
| and I'm guessing they aren't doing that.
| doonesbury wrote:
| Interesting read. Coincidentally this is a current conversation
| at our office (10K+ FTEs): use/extend open-source or develop
| institutional proficiency at aspects of distributed computing?
|
| Ours is the usual case: we have homegrown brokered message queues
| plus Kafka and 21 more. We have homegrown single-master
| replicated DB, but also use DB2, Oracle, Postgres, MySql. We have
| private in-core caches with speciality code to knit together data
| and also use Memcache, Redis. Some of that code is installed from
| DPKGs; some if it slightly edited code and installed as service
| so internal users aren't bothered with the icky-details.
|
| We have the Jekyll & Hyde behavior mentioned in OP's write-up and
| from commenters: on stuff considered core to the company and
| clients for a sufficiently complex system, we're not going to
| rely on 3rd party trouble ticketing systems and support. It's in-
| house. But that resolve falls away in stages and never lasts. We
| also have people who strongly push the business practical side:
| we're not here to write Azure or Kafka. We're here to make
| business apps. Get focused, and get client focused. That comes
| with an interesting blend of boredom and brand awareness gone
| wrong: I looked around & I saw or heard people in Dept X are
| working on caching solutions so ... what'd be the point of you
| doing it?
|
| Now, here's the interesting question: suppose we needed a
| distributed ledger (without blockchain) or we needed 2PC for some
| homegrown caching. Now what? Do we write that in-house as a
| reusable components? Dig it out of PG or MySql code if they have
| it and we know were to look? Suppose we make a business case to
| upgrade a cluster to kernel bypass NICs. Should we go into Redis
| and self-modify the code to support that I/O path? No? Frankly,
| what then is the purpose of a CS guy/gal with a MS in distributed
| computing otherwise?
|
| My own perspective on this:
|
| - The first 1/3rd of this back and forth is the proxy
| conversation that flies above reality which is more about risk
| management and perception of failure i.e. company reputation &
| gossip mongering.
|
| - The second 1/3rd of this is what people talk about because we
| can't talk about the underlying CS concepts. Most company
| employees usually have no ability to formally describe, or
| otherwise even sketch 2PC giving pseudo-code for it on a
| whiteboard. Or take this another way: see if you can get your
| lead on your homegrown replicated DB to explain how it works and
| why it works like we'd see in a senior level CS class: clear,
| specific, and yet abstract enough not be talking about
| superfluous implementation details. Can the audience understand
| it?
|
| - Insufficient grounding in customer needs so one can better
| determine what clients really need, and what's lacking in the
| current offerings. Failure here will send you on goose chases to
| no where.
|
| Gedanken experiment: you and I start a new software company
| broadly in distributed ledgers, caches. We are able to get 25% of
| MS' distributed computing leads --- not all --- but none of these
| guys and gals are slouches. What now? Do we write it in house or
| expand and extend some IBM offering? The the difference is we
| have talent, and there's some reason to believe they can deal
| with a distributed system's worth of risk.
|
| To end this with humor, here's a nice analogy I once heard: On a
| Saturday, mom and dad were sick of the noise of their three kids.
| And the house was a mess. So they send them outdoors to work
| their energy off. At sunset the house is clean, and they're
| sitting on the porch watching the sun go down over some wine.
| They see the kids coming back: they are filthy dirty. They see
| work: all 3 kids needs baths. The clothes have to be washed. And
| they'll probably destroy the bathrooms they just cleaned. So the
| father looks at the mother and says: As I see it, we could clean
| these kids up or make a new one. Not sure if making a new one is
| wisdom, but it's a hell of a lot more fun.
| lawwantsin17 wrote:
| More nonsense for non-tech founders posing as nonsense for tech
| founders. All of these points leave out developer happiness and
| buying just does equal good knowledge. It equals Googling around
| a black box.
| jvanderbot wrote:
| Build the secret sauce, buy the packets.
| philjohn wrote:
| Also worth noting that "buy" in this context can also mean using
| a piece of open-source software, not just buying something
| commercial.
| [deleted]
| zapataband1 wrote:
| There are some good points in there, but it's worth noting
| build/deploying is becoming easier than ever. For a simple static
| site you could pay 300$ a website-builder-thing or you can build
| an app inside a docker container and your host will reboot it for
| you if it crashes. I use a docker-compose.yml file and I was able
| to quickly download an open source service that automatically
| renews my SSL cert. But yeah it depends on the scope, and the
| project, and what skills you have freely available or wouldn't
| mind learning.
| zapataband1 wrote:
| good real-life example i just ran into: i host my own website,
| and now I want to run a newsletter/email campaign. I don't
| desire doing this work and it's cheeeaapp/free from certain
| services that guarantee high delivery.
| temporallobe wrote:
| This is not a universal truth. I've worked with COTS products
| that required a ton of work to customize and get working properly
| - sometimes costing as much in time and manpower as it would have
| been to build the same thing from scratch. Often this happens
| with managed server all-in-one "business solutions" systems that
| let non-developers build UIs and reports (and
| charts/visualizations, etc.). Nearly 100% of the time this is
| inadequate and often completely fails, requiring management to
| bring in actual software engineers to "fix" things and eventually
| just rebuild an entire dashboard from scratch using real
| development tools and techniques. Many of these kinds of shops
| underestimate the importance of strong software engineering
| practices and fail to understand the complexity of their own
| requirements, much less the complexity of their data.
| lexicality wrote:
| One of the few things I appreciate from my abusive first boss was
| making me acutely aware of the value of my own time.
|
| He was incredibly stingy with money and always wanted to know how
| much it would cost him to have his engineering team implement
| something vs how much it would cost to buy it and integrate it.
|
| Admittedly he was pathologic about this to the point of having us
| create a timer that counted in pounds sterling that he'd start
| running at the start of every meeting, but I feel like it made me
| way more efficient with my time (and hate long meetings)
| FpUser wrote:
| 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.
| lexicality wrote:
| > frankly I do not see any advantage of hosting on say Azure
| over hosting myself.
|
| In my opinion, cloud hosting only makes sense if your systems
| are architectured around being hosted on the cloud.
|
| If you can build your application in such a way that it runs
| in the free tier of serverless, then it's going to be
| considerably more cost effective than renting a dedicated
| server - but if you can't, then it absolutely won't be.
| FpUser wrote:
| >"If you can build your application in such a way that it
| runs in the free tier of serverless"
|
| Serverless - that would be vendor/architectural trap.
| Besides free tier does not come anywhere close to be able
| to serve my applications. They serve real medium/big size
| businesses.
| lexicality wrote:
| I'm sorry, I'm confused as to what your point is
| FpUser wrote:
| You mentioned serverless and architecting for it. I
| consider it vendor and technological lock in with no
| benefits. You might have a different opinion but to each
| their own.
|
| You also mentioned free tier. To me it is irrelevant as
| the amount of resources it gives is useless for me.
| human wrote:
| I had a similar client early in my career. Working for him was
| a love/hate relantionship. He tripled my hourly rate telling me
| my time was highly valuable but then had very high standards
| and aggressive timelines.
| coward8675309 wrote:
| 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.
| jtsiskin wrote:
| I thought one of the main advantages of "running your own
| (Kubernetes cluster|database instance|pubsub system)" was for
| exactly that reason - so that "you can replicate across cloud
| providers or in your own datacenter or on your own server in
| the closet".
| ummonk wrote:
| The problem happens when Ops software tends to be GUI-based and
| overly complex, and you just want some programmatic / command
| line tool you can properly integrate into your software /
| processes.
|
| It's often simpler to take open source software and adapt it to
| your needs than to buy commercial software.
| blindm wrote:
| Some people take lifetimes, even multiple reincarnations to come
| to the conclusion that they are buyers, not sellers. Some people
| are born marketers and are very good at persuasion, hyperbole,
| and other tools to sell a product/service.
|
| Others are natural consumers: they develop tastes and grow to be
| rabid shoppers. It's good to sit in the middle of these two
| opposites, but often better to decide which extreme you want.
|
| I know I've made the decision too late in life, when I wasted a
| vast portion of it trying to sell some product/service/idea when
| really I just wanted the latest Porsche!
| dasil003 wrote:
| I'm sure a lot of people would love to go all-in on the buy
| side. Where do you get the money to buy something if you don't
| sell anything though?
| blindm wrote:
| > Where do you get the money
|
| In this case we assume there is a cashflow of some sort. How
| the cashflow comes into being is a public matter for most,
| but sometimes a private matter. It is assumed that a certain
| amount of disposable income can be used to acquire tastes and
| become a 'shopaholic' of sorts.
| wenbin wrote:
| Totally agree.
|
| Some engineers love to say "I can build this over a weekend". But
| the main cost is almost always on the maintenance side.
|
| I forgot where I saw this number - in the entire lifecycle of a
| piece of software, (on average) maintenance cost is at least 8x
| of the initial dev cost.
|
| Yes, buying a solution also costs time (and $$$) to integrate and
| maintain, e.g., using a 3rd party API - time to write code, time
| to set up monitoring / alerting, error handling... There are
| always exceptions, edge cases, special situations...
|
| But in general there are fewer and fewer things that a web
| company needs to build from scratch. It takes less engineering
| time to launch a web product than before, thanks to all those out
| of box solutions, e.g., SaaS, apis...
|
| I like building a software/web business today than 10 years ago
| :) One-person (or tiny team) web businesses will be very common
| (I'm running one [1]), and running an API business is not bad
| because it actually saves customers time & money(vs building one
| in-house) [2] thus they are willing to pay a small fee (compared
| with hiring one or more full-time engineers).
|
| [1] https://www.listennotes.com/blog/the-boring-technology-
| behin...
|
| [2] https://www.listennotes.com/blog/how-i-accidentally-
| built-a-...
| satyrnein wrote:
| I think "maintenance" somewhat mischaracterizes it. In my
| experience, it's often that an engineer can build the typical
| use case over a weekend, but will have to continue pouring in
| more dev time while it's in production to handle a huge number
| of edge cases that weren't properly handled originally. That
| work is only "maintenance" because you already claimed the work
| was completed, and finance has it marked as having been put
| into service, so you can't capitalize further costs against it.
| wenbin wrote:
| Yea, in software development, it's always work in progress.
| There's not a clear finish line.
|
| The word "maintenance" can't perfectly capture the meaning of
| all the continuous development, small incremental
| improvements, bug fixes, operational tasks...
| effnorwood wrote:
| But muh open source. Build don't buy.
| woleium wrote:
| 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.
| drej wrote:
| I used to have a boss who took this logic to an extreme and
| basically preached "always buy, never build"
|
| Problems mounted - cost, security, integration issues,
| performance, ... - we couldn't do anything about any of that,
| because we just wrote glue code to combine all the SaaS stuff.
|
| I think about that job from time to time and I have two theories
| as to why this guy was like this - a) lack of trust/knowledge his
| engineers can build stuff, b) bragging about using a shiny-new-
| tech is better than talking about writing a Python script that
| saves data to Postgres.
|
| All in all - good points in the article, but there is more to the
| decision (as hinted in the summary), building stuff is not just
| about scratching one's itch.
| [deleted]
| dilyevsky wrote:
| Buy if you want to save money, build if you need it to work.
| thinkharderdev wrote:
| These sorts of discussion always seem somewhat confused to me
| because "buying" vs "building" is not a binary choice. It is more
| often a choice between:
|
| 1. Buy some platform/framework which you will then need to hire a
| small army of costly consultants to integrate and customize for
| your particular business need. Or
|
| 2. "Build" your own solution by orchestrating a bunch of open
| source technologies to solve your problem.
|
| Moreover, it is not quite clear up front whether 1 or 2 will be
| costlier in terms of development effort and overhead.
| recursivedoubts wrote:
| _excellent_ point
| dvtrn wrote:
| It would seem to me there are still two choices to make,
| meaning it's still a binary choice-merely with more caveats and
| words involved to describe the options?
| thinkharderdev wrote:
| Yeah, that was phrased somewhat awkwardly. The binary choice
| I was rejecting was between
|
| 1. "Buying" a solution that solves your problem exactly and
| doesn't require engineering resources to implement and
| maintain
|
| 2. "Building" a solution where you have to solve every
| problem from scratch where you don't have any particular
| expertise.
| localhost8000 wrote:
| I understand your general point of there being a continuum of
| paying for building blocks to be integrated. But,
|
| > is not a binary choice
|
| Then, offering two options. :)
| thinkharderdev wrote:
| Haha, yes that it is a bit awkward
| bdcravens wrote:
| Sometimes though we are dishonest about #1, and we want a
| deeper level of integration or polish than is necessary.
| barnaclejive wrote:
| This is 100% correct
| Raidion wrote:
| I think it's a matter of unknown future needs that's the
| problem. If you want to do feature flags, you can basically
| build a service that stores key value pairs segemented however
| you please, throw it behind redis cache, and call it a day.
| This is faster and probably cheaper than buying a SaaS!
|
| However, if you want a bunch of neat features, custom rollouts,
| and all that stuff, you're simply not going to be able to get
| the same value (unless you have HUGE scale) building it, and
| should just buy it.
|
| Most organizations aren't comfortable saying "this is all we'll
| ever need" and are worried about both building, buying, and
| then migrating, which can be significantly more expensive than
| either of those options in a vacuum.
| Aeolun wrote:
| In my experience, integrating a thing like feature flags is a
| major pain if you do not have control over the
| implementation. It ends up being kludges and suboptimal
| choices everywhere.
| crocktucker wrote:
| s/binary/simple/ ... and you're on to something.
| jiveturkey wrote:
| cost is often not clear up front, but neither is benefit!
|
| this is where experience matters.
| api wrote:
| This is _usually_ true except for two cases:
|
| 1 There is some other expense you can save significantly on by
| DIY. An example would be DIY k8s on bare metal via bare metal
| providers for a massively bandwidth intensive service where
| paying AWS or GCP outbound data rates would be thousands and
| thousands a month.
|
| 2 You are at sufficient scale that there is an economy of scale
| that can be accessed. This overlaps a bit with the first point
| but can also happen if you are just big enough. The first point
| is more about some special need.
| dmantis wrote:
| The very important point of today's world - data protection - is
| not covered at all.
|
| For customers, it's better to give their data consciously to one
| provider within one chosen jurisdiction than moving personal
| data, documents, activity logs, etc within multiple 3rd parties,
| as well as to do due diligence on any web service they provide
| any data.
|
| Please, respect your customers and don't share their activity
| when it's not necessary and cost just a few hundreds bucks per
| month.
|
| Treating humans as "units" instead as people with rights is a big
| problem of IT businesses.
| x87678r wrote:
| This is where free & opensource has really changed the world. Its
| not buy vs build any more its download vs buy vs build and its
| best to use a free package that is out there. Its incredible what
| is available now, in the future I wonder if anyone will need to
| build anything.
| einpoklum wrote:
| This is Capitalist logic, and more specifically - an argument for
| the concentration of capital in the computing/IT sector.
|
| We, software developers and users - people and small
| organizations - should adopt the opposite slogan:
|
| __Built, Don 't Buy. __
|
| When we build, we improve our knowledge and understanding of
| systems. We help affect them, through engagement with their
| developers or through modification and forking. When the
| challenges and overhead of building exceed our abilities - this
| will drive us to:
|
| 1. Strive for better-fitting software - easier to use, deploy,
| build and maintain; and
|
| 2. Cooperate and collaborate with related organizations and
| communities/groups of developers and enthusiasts, either to share
| knowledge on how to get things done more easily, or to distribute
| the load of work between many parties, each of which can't do it
| on their own.
|
| Even if a lot of FOSS contribution these days are made at for-
| profit corporations - the above is key to the future of both
| software freedom and social freedom.
| mirekrusin wrote:
| Nonsense without a context.
|
| Sometimes "building" means writing 6 shell scripts (each <10 LoC)
| and "buying" means getting CKA/CKAD certificates for all people
| involved and spending half a year on training.
| hootbootscoot wrote:
| Mmmm probably depends upon what _it_ is. Core competencies of
| your business? Probably not the best thing to use an external
| service for. (Assuming your core competency is not cloud
| computing & storage) Your core will need to constantly be
| extended, honed, refined, redefined, poked at, prodded etc...
| veesahni wrote:
| 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
| fuzzy2 wrote:
| I'm a little confused. When I have to build software (for a
| client), it's usually to support some business process or make it
| automated or whatever.
|
| What am I supposed to buy, except some PDF/Excel/whatever library
| every now and then?
|
| But maybe I'm just not the target audience for this article.
| satyrnein wrote:
| Yeah, doing work to automate some idiosyncratic process, either
| for clients or internal users, may be different. You do have to
| be careful you're not slowly implementing a CMS, CRM, email
| marketing tool, etc, feature by feature, though.
| z3t4 wrote:
| I think there is a balance in the "Yak Shaving" business... There
| is a swaying "the best code is the code you did not write".
| leowoo91 wrote:
| I have to disagree.. Not everyone has enough time to learn
| "ready" systems either, they can get pretty overwhelming. When I
| decide to build instead of buy, it's mostly because I don't
| believe in the design of the product that is favored by thousand
| people with reason being "it just sounds cool".
| lexicality wrote:
| This works great until you hire a second person who now has to
| figure out how your system works from the documentation you
| wrote, rather than the documentation and blogposts on the
| internet written by the thousands of people who thought the
| other thing was cool.
| human wrote:
| From an engineer perspective there is a learning opportunity that
| can't be underestimated. If you have free time to build it's
| always interesting how much you can grow by doing it yourself.
| However, if you are working for a startup and time to market is
| essential, than buy it for sure.
| didip wrote:
| I agree.
|
| If you are in decision making position, I struggle to see why
| would you want to spend so much energy installing Prometheus +
| Grafana stack instead of just using DataDog.
|
| Even worse if your company attempts to build Prometheus/Grafana
| from scratch. Just why? What a huge waste of money.
|
| If it contributes to your core business then ok, I can see why
| you may want to build custom solutions.
| rantwasp wrote:
| i think there is a huge difference between using prometheus and
| paying for datadog. the article argues for not building
| prometheus which makes sense in 99.95% of cases.
|
| btw, the build vs buy should be a topic of discussion whenever
| people want to build something. at an absolute minimum they
| need to understand (and use) what's already out there before
| they embark on the journey of building themselves
| YetAnotherNick wrote:
| > so much energy installing Prometheus + Grafana stack instead
| of just using DataDog.
|
| Because it could be done in few commands the second time. And
| learning is only possible when wasting time on this kind of
| things, rather than trying hard to custom fit your usecase
| using some buyable tool.
|
| That being said, I kind of partially agree with you and the
| author though. Don't maintain service just to feel that you are
| in control, but with the exception that if you are doing it for
| the learning purpose.
| flumpcakes wrote:
| On premise Prometheus/Grafana could be lower than 5% TCO
| compared to DataDog, at least at places I have worked, and I am
| including employee time. This isn't particulary a discussion
| about cap ex. vs. op ex. either.
| lhopki01 wrote:
| Interesting you should bring this up as we are currently in the
| process of moving from Datadog to Prometheus/Grafana. What
| we've found is all the time you save in not setting up
| Prometheus we lose in support tickets to Datadog to get them to
| explain undocumented functionality and hidden "magic" they put
| in place. With Prometheus/Grafana the answers are always out
| there because of the sheer number of people out there. We've
| even resorted to sending known metrics on known intervals just
| to understand what Datadog does differently for monitors vs
| graphs. Also the majority of the time for a monitoring system
| is not spent on setting it up but rather on generating the
| dashboards and alerts.
|
| Also with all buys systems there is a hidden costs in managing
| the legion of user accounts to access these new services. It's
| rarely as easy as just setting up SAML or single sign on.
|
| The final thing that people never talk about is cost. Yes there
| is the cost of an engineer to set it up but often that costs is
| cheaper than the bought service. This is especially true of pay
| per api call type services.
| recursivedoubts wrote:
| Every build v. buy decision should ask: "Is this a place where we
| want to bet on our ability to derive competitive advantage."
|
| If the answer is no, lean towards buy. If the answer is yes, lean
| towards build.
|
| For ops, netflix would say "yes" whereas most companies would say
| no.
| taylodl wrote:
| _Systems of Differentiation_ should employ a build-first
| strategy. These are the systems that differentiate you from your
| competitors, they are your competitive edge. As such you
| typically need tight control over these systems and don 't want
| to rely on 3rd parties - either vendors or contractors.
|
| _Systems of Engagement_ & _Systems of Record_ should employ a
| buy-first strategy. These are typically more operations-focused
| systems and as such you 're usually better off buying them, but
| not always (see below). It's possible that some of these systems
| may also be _Systems of Differentiation_.
|
| What is a buy-first strategy? It means consider buying first. How
| much would your operations be impacted by the necessary changes
| to your workflow? How much customization will be required in
| order for it to be usable and how are those customizations
| maintained throughout product upgrades? How much integration is
| required with existing systems? Buying software is rarely a buy,
| deploy, and done proposition! Usually the TCO is lower if you
| buy, but not always - depending on how much customization and
| integration is required.
| bdcravens wrote:
| The phrase AWS came up with for this, "Undifferentiated Heavy
| Lifting", is quite apt.
| taylodl wrote:
| I should have pointed out this is the strategy that should be
| employed by an established company. If your company is just
| starting out then buy everything if possible - your competitive
| edge is the fact you're small and nimble. You can respond to
| market changes faster than the established companies can. Over
| time you'll recognize what are to become your _Systems of
| Differentiation_ and then and only then should you consider
| building that yourself. When you 're starting out you typically
| don't have the time or capital to wait and build the software
| you may need. For such companies doing business and generating
| revenue _now_ is more important than having a perfect
| application portfolio. And yes, this is why systems are never
| as perfect and pristine as developers would hope.
| je42 wrote:
| You can only buy stuff if you know that stuff is aligned with
| what you need.
|
| Further, you need to consider that the stuff you buy also needs
| to aligned with your needs over time.
|
| However, you also need to consider this when building stuff.
|
| The alignment is the tricky thing it is easier to achieve when
| building in-house as long as you engineering is up to the job.
|
| Also, note that building in-house doesn't mean engineering "from
| scratch". Usually it means use lower level components over higher
| level components/services.
| magicalhippo wrote:
| It's all trade-offs. At work a customer could only send some data
| via mail, our integration could only accept via SFTP.
|
| I had just had a look at Azure and had seen their Logic Apps, and
| quickly whipped up one which downloaded the mail and uploaded the
| files to SFTP. Nice.
|
| Until a few months ago when it suddenly stopped working because
| for some reason Azure doesn't like the key exchange algorithms
| Bitvise SSH server provides. Or at least, that's as far as I've
| been able to determine. Zero logging on the Azure side so no clue
| what's wrong.
|
| After spending hours trying to figure out what went wrong, I made
| my own program that does the same. It took a bit longer than the
| Logic App, but at least I can fix it when it breaks...
| bdcravens wrote:
| The hardest part of learning to not look through your developer
| eyes. Often the 80% solution is "good enough" for your customers
| or your stake holders, and they'd never appreciate the extra 20%
| a fully custom solution provides.
| papito wrote:
| The most egregious cases of violating this involve trying to
| create your own CMSs, search engines, and God forbid - databases.
| There are of course, exceptions. AirTable wrote their OWN
| database engine, but they knew what they were getting into, and
| they did it right.
___________________________________________________________________
(page generated 2020-12-12 23:01 UTC)