The general debate in software development is to use off-the-shelf tools and services that increase developer productivity, or low-level tools and specials that provide more control and potentially better performance and flexibility. Focus on whether to use the solution. It can be reduced to the decision to build or buy.
These two approaches are at the core of many of the current ideological conflicts in the technology industry.
• Cloud or proprietary hardware
• Use high-level dynamic programming languages for application development, not low-level languages.
• Self-hosted and managed services
• In-house dedicated tools and software solutions as standard services
Conflicts are presented in a simple way by simply choosing whether to use the client library or access directly through the application programming interface when using development tools. Using Influx DB as an example, this article describes some factors to consider when choosing between client libraries and direct use of the API. As we’ll see, this potential trade-off between developer productivity and efficiency, flexibility and control can be found in other areas of software development.
Standard discussion topic
Here are some of the main points raised on both sides of the discussion regarding construction or purchase.
Equipment purchase discussion:
• You can focus more on your core business.
• Teams can move and add resources more quickly.
• A more efficient, cost-effective, ready-to-use open source tool or custom managed service.
• As hardware resources have become much cheaper and developer time has become more valuable, we need to prioritize increased developer productivity.
The general argument for this is that this idea led to “software eating the world.” Many older companies that saw software as a cost center for outsourcing have been taken away by tech companies that took software seriously and saw it as a competitive advantage.
To protect against the use of turnkey solutions, companies like Instagram and Drop box (and many others) are pioneering cloud services, allowing them to focus on their products rather than their infrastructure.
Team building discussion:
• Save money by eliminating service providers that charge extra.
• Building on your own experience has long-term benefits.
• Tools can be designed for specific business needs, as opposed to more generic tools that can be inflexible.
• Fewer external dependencies and avoid lockups and security issues.
The general argument for this aspect is that value propositions to users of many tech companies are irrelevant to how technology works behind the scenes. Additional criticisms include advice to “do not reinvent the wheel” and diagnosis of “not invented here” syndrome. Most users don’t care how things work behind the scenes. They want the end result to work properly.
Amazon Web Services, on the other hand, has been able to grow as a business thanks to the in-house knowledge that Amazon has developed to bring its own services to market. This insider’s knowledge ultimately led to the $ 1 trillion cloud computing market that revolutionized the tech industry. If Amazon follows common sense and tries to outsource these operations, it won’t be the leader in the cloud industry today.
Client Library and API
To make things a little more concrete, let’s look at a very simple example that shows the positives on both sides. Developers are the main target of InfluxDB, the time series database, Influx Data. It provides direct access to the database through the client library and API, giving developers the best possible experience for their use cases.
The client library provides out-of-the-box guidelines to help developers get started reading and writing data quickly. Developers don’t have to think about batching requests, retrying failed requests, handling asynchronous requests, etc. Using a client library makes sense for developers who want to try out Influx DB or quickly integrate it into their time series data storage application.
On the other hand, developers who need more flexibility and control can interact directly with the Influx DB API. Client libraries are not suitable because some companies have a lengthy process of adding external dependencies or already have an existing internal library to handle communication between services. There are many companies that have built their products as extensions or platforms based on Influx DB, made possible by the flexibility of the API. However, this requires a little more effort than using the client library.
On a micro scale, using Influx DB as an example, you can see that the best options vary depending on the situation. For companies that use Influx DB to monitor parallel tasks that are not an integral part of their software or product, client libraries make sense as they enable rapid integration and developer productivity.
On the other hand, if your company uses Influx DB as a core part of its product, or you need more flexibility for other situations, you can use the API. Influx DB aims to give developers the best of both worlds by offering options.
There is more than one correct answer
As much as people would like to have a definitive answer to questions like this, the reality is that it all depends on individual companies and their position in the business. Two main factors to consider:
1. Are software projects important to your core business values?
2. Can your company benefit more from building custom software in terms of product and market compatibility?
For startups that are still trying to find product and market compatibility, speed is the most important factor and it makes sense to focus on it. For a more established business, building custom tools, making software more efficient, and moving to your own hardware will give you an edge over the competition.
