5 ms·

I would only use a Google, Microsoft, _whoever_ API if I was paid for integrating and maintaining it. I would never rely on such a thing in a personal project/v

by cm3 10y ago

I would only use a Google, Microsoft, _whoever_ API if I was paid for integrating and maintaining it. I would never rely on such a thing in a personal project/venture. Time and again paid and free web services are getting shut down without a replacement. The reputation is already such that nobody can trust a service to be there in 2 years. Another reason to build more decentralized solutions while we can. I was delighted to read that Berners-Lee and Cerf advocated just that recently.

Aissen 10y ago
You mean like Parse was paid for ? It's not necessarily a silver bullet.
- kowdermeister 10y ago
  Relying on third parties is never safe. I think these services are great for fast prototyping, but eventually you should move on to build your own stuff.
  - TeMPOraL 10y ago
    I agree. We need a shift away from the whole SaaS idea. It plays nicely with ultra-short-term market thinking, so people buy into that, but it is bad long-term. Any service you use is giving away control to a third party. It's true in life as well. Some services are easily replaceable - if the barber shop next to you closes down, there's always another few streets away. But some services are not so easily replaceable, and it's the case of most of them on-line due to the very bad state of software-software integration (i.e. having people to write complicated translation layers). If you depend on such services for your business and they decide to shut down, you're screwed. If we want to move computing forward, we need more products and less services. More software that one can download and host themselves.
    - michaelbuckbee 10y ago
      For lots of businesses the choice isn't between SAAS and download+install, but SAAS and not having an app at all. It's a real cost+risk to maintain, update, secure, backup and troubleshoot an application internally and in most bottom line terms is less expensive as a SAAS than an internal application.
      - TeMPOraL 10y ago
        Yeah, but the end result is a string of services depending on services depending on services, and a very fast-moving ecosystem of fragile, throw-away solutions. Sure, it makes some people some money, and there's a perfectly rational short-term market reasoning to do your product this way, but is this the world we want to live in? I think this is one of those cases where to make real progress, you have to go against the gradient of economic considerations.
    - kowdermeister 10y ago
      SaaS is not bad at all, but when it's misused. Current example is ticketing. Two of my clients need a solution to manage ticketing and subscribers. They went with Eventbrite, even tough it's a bit expensive. It saves them tons of time and money. Sometimes it makes little sense to develop such a system for somebody if they have 2 events / year. Often, third parties are much better in quality, than an in-house dev could create. I would only pick a third party service if it has many competitors, so easily disposable. I've been screwed by this before, I built on an API before and the legal team shut down my API key for bullshit reason. 1 year of devtime went down the drain :) Long story short, SaaS is bad for mission critical features, otherwise great helpers on the short / mid run.
      - TeMPOraL 10y ago
        The distinction of core/critical and non-critical aspects of your business is a good one. I'm not saying "don't use SaaS at all" (even though I dislike the world of short-lived, data-siphoning services we've created). But betting the life of your business on a third-party service makes sense only if the expected life of your business is shorter than the expected life of the service you want to use. And I think we could all use more longer-living solutions.
        Godel_unicode 10y ago
        To quote Joel Spolsky "If it's a core business function -- do it yourself, no matter what" http://www.joelonsoftware.com/articles/fog0000000007.html http://www.joelonsoftware.com/articles/fog0000000007.html
    - carterehsmith 10y ago
      I guess it depends? Consider, for example, payment processing - super hard to do properly by yourself. Which is why this is only done by large companies with lot of funds, e.g. Paypal, Stripe, etc. The chances of them going titsup are low. If they do, you switch to another one.
      - TeMPOraL 10y ago
        A special case is a special case. Payment processor going "titsup" would be a literal disruption of market; if they'd all close down, I'd be worrying about getting more shotgun ammo to protect my canned food. But besides that thing that's to a living company like a heart to a living body, I think we could do with using less services and more products just fine.
- cm3 10y ago
  I wrote "paid and free web services", so Parse would be a similar risk. To force someone to operate a paid service as long as you want it, you either need a really good contract or laws, but that's not a generally applicable solution. The better solution is to lessen reliance on services like that and prefer stuff we can run independently.
- kedean 10y ago
  I think he meant unless he was being paid by someone else. As in, he would avoid a google API unless some sort of client or employer was paying him to use it.
eru 10y ago
Google actually deprecated this over four years..
- cm3 10y ago
  I know, but not all software is written and maintained such that this is enough to adapt. Whether that's good or bad is a different question.
  - lallysingh 10y ago
    Four years? Any software that assumes that a networked third party service will be up (any unchanged) for years later is ridiculous, and it's development is bad.
    - cm3 10y ago
      Is it bad? Yes. Does this happen? Also yes. Maybe you're assuming that there isn't software which gets written and installed but only touched sporadically. Web services will be integrated in some web site and forgotten about. Sometime after the service is shut down some user of the site might notice. It's not the case that all users of a web API are developers like the HN crowd and in the loop of things. To be clear, I'm not saying people should expect different support times, just that one shouldn't rely on a third party when it's all over the network and you have no local copy of the code to potentially operate for longer than officially supported.
      - lallysingh 10y ago
        > one shouldn't rely on a third party when it's all over the network and you have no local copy of the code to potentially operate for longer than officially supported Agreed.

by cm3 10y ago

Aissen 10y ago

You mean like Parse was paid for ? It's not necessarily a silver bullet.

kowdermeister 10y ago
Relying on third parties is never safe. I think these services are great for fast prototyping, but eventually you should move on to build your own stuff.
- TeMPOraL 10y ago
  I agree. We need a shift away from the whole SaaS idea. It plays nicely with ultra-short-term market thinking, so people buy into that, but it is bad long-term. Any service you use is giving away control to a third party. It's true in life as well. Some services are easily replaceable - if the barber shop next to you closes down, there's always another few streets away. But some services are not so easily replaceable, and it's the case of most of them on-line due to the very bad state of software-software integration (i.e. having people to write complicated translation layers). If you depend on such services for your business and they decide to shut down, you're screwed. If we want to move computing forward, we need more products and less services. More software that one can download and host themselves.
  - michaelbuckbee 10y ago
    For lots of businesses the choice isn't between SAAS and download+install, but SAAS and not having an app at all. It's a real cost+risk to maintain, update, secure, backup and troubleshoot an application internally and in most bottom line terms is less expensive as a SAAS than an internal application.
    - TeMPOraL 10y ago
      Yeah, but the end result is a string of services depending on services depending on services, and a very fast-moving ecosystem of fragile, throw-away solutions. Sure, it makes some people some money, and there's a perfectly rational short-term market reasoning to do your product this way, but is this the world we want to live in? I think this is one of those cases where to make real progress, you have to go against the gradient of economic considerations.
  - kowdermeister 10y ago
    SaaS is not bad at all, but when it's misused. Current example is ticketing. Two of my clients need a solution to manage ticketing and subscribers. They went with Eventbrite, even tough it's a bit expensive. It saves them tons of time and money. Sometimes it makes little sense to develop such a system for somebody if they have 2 events / year. Often, third parties are much better in quality, than an in-house dev could create. I would only pick a third party service if it has many competitors, so easily disposable. I've been screwed by this before, I built on an API before and the legal team shut down my API key for bullshit reason. 1 year of devtime went down the drain :) Long story short, SaaS is bad for mission critical features, otherwise great helpers on the short / mid run.
    - TeMPOraL 10y ago
      The distinction of core/critical and non-critical aspects of your business is a good one. I'm not saying "don't use SaaS at all" (even though I dislike the world of short-lived, data-siphoning services we've created). But betting the life of your business on a third-party service makes sense only if the expected life of your business is shorter than the expected life of the service you want to use. And I think we could all use more longer-living solutions.
      - Godel_unicode 10y ago
        To quote Joel Spolsky "If it's a core business function -- do it yourself, no matter what" http://www.joelonsoftware.com/articles/fog0000000007.html http://www.joelonsoftware.com/articles/fog0000000007.html
  - carterehsmith 10y ago
    I guess it depends? Consider, for example, payment processing - super hard to do properly by yourself. Which is why this is only done by large companies with lot of funds, e.g. Paypal, Stripe, etc. The chances of them going titsup are low. If they do, you switch to another one.
    - TeMPOraL 10y ago
      A special case is a special case. Payment processor going "titsup" would be a literal disruption of market; if they'd all close down, I'd be worrying about getting more shotgun ammo to protect my canned food. But besides that thing that's to a living company like a heart to a living body, I think we could do with using less services and more products just fine.
cm3 10y ago
I wrote "paid and free web services", so Parse would be a similar risk. To force someone to operate a paid service as long as you want it, you either need a really good contract or laws, but that's not a generally applicable solution. The better solution is to lessen reliance on services like that and prefer stuff we can run independently.
kedean 10y ago
I think he meant unless he was being paid by someone else. As in, he would avoid a google API unless some sort of client or employer was paying him to use it.

eru 10y ago

Google actually deprecated this over four years..

cm3 10y ago
I know, but not all software is written and maintained such that this is enough to adapt. Whether that's good or bad is a different question.
- lallysingh 10y ago
  Four years? Any software that assumes that a networked third party service will be up (any unchanged) for years later is ridiculous, and it's development is bad.
  - cm3 10y ago
    Is it bad? Yes. Does this happen? Also yes. Maybe you're assuming that there isn't software which gets written and installed but only touched sporadically. Web services will be integrated in some web site and forgotten about. Sometime after the service is shut down some user of the site might notice. It's not the case that all users of a web API are developers like the HN crowd and in the loop of things. To be clear, I'm not saying people should expect different support times, just that one shouldn't rely on a third party when it's all over the network and you have no local copy of the code to potentially operate for longer than officially supported.
    - lallysingh 10y ago
      > one shouldn't rely on a third party when it's all over the network and you have no local copy of the code to potentially operate for longer than officially supported Agreed.