![]() The adapters translate the generic API calls to storage specific calls. There is an adapter for every supported storage type (Amazon, Google, Backblaze and local disk) and based on the configuration the appropriate adapter will be used. Our simplified bare-necessity API is defined in a thin wrapper that forwards all API calls to adapters. In addition to the reasons mentioned above (abstraction and simplification), we wanted a tool that made it possible to use storage on a local disk and storage in the cloud interchangeably.ĭuring development, we often use local disk storage to save network calls but we want to be able to seamlessly switch to a cloud service on the production server. However, S3 still is a rather comprehensive API. We can discern a tendency of convergence towards S3 and while this may or may not be good news, at least it unifies the APIs of some storage providers. And Backblaze has recently added an extra S3 compliant API to their B2 service ]( ). Google offers tools ]( ) that are currently only available for Java or Python. There are cloud services that use a different API, such as Google Cloud, Microsoft Azure and Backblaze B2, but they also provide tools for easy migration from S3. As a consequence, the S3 API has more or less become the standard for cloud services. Today S3 is still one of the most popular cloud storage services.īecause Amazon S3 was the first cloud service that got widely adopted, other cloud services implemented the S3 API in their services to be compliant with S3 and make it easier for customers to hop over to their services. The first completely web-based commercial cloud storage was "PersonaLink Service" by AT&T in 1994 ]( ), but the use of cloud storage really took off since Amazon launched S3 in 2006. Keywords are abstraction and simplification, as mentioned in the title. That is why we've decided to write an abstraction layer for the APIs of the most-used storage providers that exposes only a limited set of common storage actions.
0 Comments
Leave a Reply. |