Relying On Outside Tech, Good or Bad?
In my opinion, the most important aspect of deciding whether or not to use outside tech is that you have carefully balanced and are aware of the risks involved.
In my opinion, the most important aspect of deciding whether or not to use outside tech is that you have carefully balanced and are aware of the risks involved. Many companies nowadays seem to think a quick path to success is building their offering completely dependent on someone else's technology. On one hand it can save a lot of time. However, it can also lock you in to a situation that you won't realize the downside of until it's much too late. Knowing where you sit on this boundary is crucial to the long term success of what you are building.
A perfect way of framing how to think about this is similar to an idea Scott McNealy, co-founder of Sun Microsystems, presented at this RedisConf keynote (as well as many other places beforehand). His argument is that one of the main benefits of open source software is that it has a very low barrier to exit. According to him, the highest cost of any technology you use is the cost to move off of it. He then points out that unfortunately most companies only think about the initial expense and ongoing maintenance costs. These are only a small fraction of the overall picture, but they will trick you in to being trapped in a much more expensive situation down the road.
Here's Scott himself discussing this topic:
There are a couple of main technology categories where a decision of whether or not to rely on outside systems is necessary. Let's dig in to them.
Infrastructure
With offerings like Amazon Web Services, Windows Azure, and Google Cloud Platform, I think most people would agree that using your own infrastructure nowadays is a pretty bad idea.
That being said there are still ways I'd argue you can become too engrained in one cloud provider. As an example, using a service like AWS Elasticache, while just a managed version of open source software, is acceptable to me. If push comes to shove you can always roll your own instance with Redis or Memcache installed, swap the URLs in your codebase, and escape any vendor lock in. However, a service like Lambda is a little closer to that line of discomfort. While Lambda may be great and powerful, it's not necessarily a minor task to port functionality built on top of it to other platforms. This then means your barrier to exit with this service would be higher than is comfortable.
So what can be done? Containers can help greatly with regards to infrastructure lock in. The ability to build once and then run anywhere is very powerful and freeing. I believe this portability is one of the main reasons they've become so popular in deployment strategies.
Sarah Novotny, who leads open source strategy at Google, attributes a main piece of the success of Kubernetes to this in From open source to sustainable success: the Kubernetes graduation story:
Google worked with the CNCF and the Kubernetes community to initiate the Certified Kubernetes Conformance Program that aims to cement the portability and ubiquity of this platform.
APIs
The use of outside APIs to build a company is just like any other symbiotic relationship. It's okay to become involved with the other half as long as you don't become dependent on them.
In recent history there is no shortage of companies shutting down their API once they've become big enough such that they no longer need the ecosystem enabled by that very API. Twitter and Instagram are quintessential stories of this situation. When this happens it's not the companies providing the API that suffer most. It's any and all companies whose core offering relies on data or services offered by that API.
This isn't to say that using APIs in any situation is bad. They exist solely for outside developers to build on top of them, so they obviously have some benefit. In many cases they can provide an extraordinary extra suite of functionality you'd never otherwise be able to offer. However, keep in mind that just as you are making whatever decisions necessary to build your technology so is the company offering that API. If their success depends on restricting access to their API, there is nothing the consumers of that API can do that will matter.
Generally, relying on outside APIs as a core part of your business is a really bad idea. They should augment your offering, not establish it. The most important question to ask yourself before integrating with a third party is, "Can my business survive is this entire offering disappeared tomorrow?" If it can, you move forward.
Summary
Using technology built and owned by other companies has gotten the tech industry to where it is today. The phrase that we are "standing on the shoulders of giants" is certainly accurate here. However, in doing so we walk a fine line of dependability that can be detrimental to the success of our own technology if we aren't careful. Various pieces of the technology building process have different elements to consider. As long as you understand what those are and how they will affect you long term, you are safe. The moment you become dependent on someone else's offering you are creating a time bomb situation for youself and your company.