Gateway Deprecation Implications for Azure Customers

As we noted back in April, MinIO will be deprecating the gateway functionality in a few weeks time. As Harsha wrote at the time, the gateway had served its purpose and was no longer viable.

While all gateway users will need to make some decisions, there are some Azure gateway users (for the cloud) and this post describes what those are and how to think about them.

The entire concept of the gateway started with Azure. Microsoft came to us and asked if we would create the duality for S3/Blob API. It was a fairly heavy lift for MinIO but we felt that it would benefit the community and grow the adoption of MinIO in the process. Over time, it became impossible to guarantee the consistency and completeness in this model. Too many key features, such as replication and immutability/ransomware protection depend on versioning which conflicts with the  inline translation of the objects. Encryption, compression, and several other important features were disabled as well. S3/Blob API duality approach came to a halt beyond basic object operations. Thus, the decision to move away from the gateway model.

In the server model, all objects get written on MinIO and the S3 API is the only method supported. Applications that depend on the Azure Blob API will need to be rewritten to speak the S3 API in order to become cloud-neutral.

Here is how to make that transition:

Start MinIO on Azure by either rolling your own Kubernetes or VM instance or choosing the marketplace option:

Once your MinIO instance is set up, you can use the minio-client to either mirror one bucket at a time - for example mc mirror -w <source alias>/<bucket> <target alias>/<bucket> or simplify the whole process by copying the entire namespace - mc mirror -w <source alias> <target alias>.

After the data has been copied, you can verify it with mc diff <source alias> <target alias>.

Point the application at the new endpoint.

In return, the user will get the full functionality of the MinIO binary - from inline erasure coding, bit rot protection, object locking, active-active multisite replication, encryption, monitoring, lifecycle management and more. You can continue to use the Azure infrastructure elements, you just replace Blob with MinIO as the object store. You can even use the transition feature in MinIO to tier objects off to the blob store, for example for data that has aged beyond a threshold you determine, for example.

If your applications or the services you consume have hard dependencies on Azure Blob API then, MinIO Gateway will not be a viable choice going forward.

While we recognize that for some enterprises the deprecation of the gateway is suboptimal, we are comfortable that we have provided enough transition time (July 2020) to accommodate the community.

As noted in Harsha’s post, commercial customers will be supported with custom builds as they transition.  If you have any questions on your transition, feel free to ping us on the general Slack channel. There is no SLA and limited troubleshooting but we are here to answer general questions.