What is our primary use case?
I have used Azure Block for two or three projects. It's used to store images or videos for multi-tenant applications or a particular tenant. We recently did one project for multi-tenant products.
Any customer registered to the website can sell their product on a small scale without a website or server. It was like a platform as a service multi-tenant product. With the site ready, they can post any images or videos to Azure Storage Block. They're creating a subscription site for each unit.
For example, if you register on that website, you can allocate the memory size based on license cost: premium, gold, etc. We allocated some memory, and you can navigate to the site whenever you're ready. We provide a unique ID and an encryption key.
You can create several users for your subscription. For example, if you're an owner of this subscription, you can assign users a status as contributors, readers, or administrators. You can add images or videos through a Block via an administrative portal with a mobile or Angular application. That image is rendered to your website or any products they need. We can use that signature access key for authentication. We enable our product based on the site subscription ID.
There are different tiers, and you can create a container to solve this. First, we create a block and containers, then allocate images to that container. Once we make the container blocks, we get a primary and secondary access key. After you get the details, you can do the same for Azure. If you want to use your middleware, you need to add a library, so you can contribute a URL shared access key. You need to access it via UCA. You can upload via UCA binary format data or a content file. That is where we can upload any data with Block Storage.
When you access a unit to pass that Block ID, you can download it using ByteArray. You can send that ByteArray streaming data to your Angular application on mobile. They can convert any videos, images, or documents to display them on your mobile application. However, a security breach could allow a hacker to download anything for a particular user, so we recommended middleware for interacting with Azure Block Storage.
There are different approaches. We can use it for proper container image names or containerization with a shared activity URL. We need to consider the client's mission. If a client uses Azure Key Vault, any authorized person with the shared key can access confidential data on a centralized system. Our service can access that key to connect users to Azure Block, whether on your application, Angular, or any other web application. It will not provide users credentials or a URL directly.
What is most valuable?
Azure Block Storage lets you customize code you can use on that endpoint. If you want to write a logic for something, Azure Function can be used to deploy that application.
We need to write code and plan for deployment. You can write a function in C# and use that server or any VM or Kubernetes container. If you want to release any APA or application with AKS, there are Kubernetes cluster master nodes. We recommend doing it manually if it's a simple POS or something. I strongly recommend using DevOps Tools Continuous Integration if you're an enterprise.
What needs improvement?
One thing that needs improvement is authentication. They need to improve the integrated Azure Active Directory for the enterprise level. For single sign-on, we can try any authentication or portal for Block Azure Function AKS. For example, if you're an administrator or user contributor, you will generate a token, then your internal middleware connects to any Azure Cloud service. You need to generate different credentials for each service. We cannot use the same token.
Some services like Azure Key Vault support a single token for access that you should be able to use for the Kubernetes site, but some services are not supported. Authentication should be centralized. My understanding is that the data on this file path is streaming. Whenever you get this data, it is converted to streaming ByteArray and Base64. The file path is another security vulnerability.
Azure Block Storage is mainly used for streaming data nowadays. Companies are moving to digital platforms. They stream data from IoT, mobile, offline sources, and other systems. There are different styles and formats, including unstructured, semi-structured, relational, and platform data, so we cannot use a single database for all requirements.
We cannot say to a client, "Sorry, I need only to support this product in JSON." If we say that, competitors will dominate us. We must be prepared to accept any kind of free input or solution from clients. Then the Block supports any semi-structured data or structured data. If you go with File Storage, queuing or messaging will support storage, and the Block will support videos or images.
For how long have I used the solution?
I have been using Azure Block Storage for more than three years.
What do I think about the scalability of the solution?
Azure Block Storage is scalable. It's widely used for Kubernetes for memory profiles. We recommend auto-scaling for scalable or regional models. All the Azure Blocks should be identical, with the same configuration. Each starts with a memory size too high for one Block container or another.
That is challenging to accomplish because everything should be identical. The blocks should be identical if you want three, five, or six nodes.
How are customer service and support?
We have an internal support team that provides support to our clients. When we are designing a solution and run into something they can't handle, we open a ticket with the Microsoft team. We work closely with them. They'll give me some confirmation of whether it's feasible.
If yes, we can update management about whether this is possible. They are charging per solution on the global partner level. Once approved, we work with Microsoft to come up with a solution, PoC, or sample code.
How was the initial setup?
Creating blocks or containers is easy. We can deploy according to a rule-based access controller policy. For example, when you are adding some documents for your owner or administrator, but somebody accesses your log or something, it prevents them from deleting or it or modifying that content because it might be sensitive.
Creating the block itself is straightforward. Then we create a shared access policy to allow us to manage access directly. If I'm doing development, I can limit it so that we can make it read-only. That is possible, but we need to plan accordingly.
What's my experience with pricing, setup cost, and licensing?
Azure Block Storage pricing charges differently for hot and cold storage based on our business scenario. For example, data that isn't frequently accessed costs less. Data that is accessed often costs more. Storage on the cloud is cheaper.
Which other solutions did I evaluate?
AWS has a similar solution for S3 Bucket that will support any document images, videos, etc. They have a platform supporting authentication but a different approach. The AWS and Azure solutions are about 80 percent the same. The difference is the migration process. We can migrate our data or documents with the trickle-based or Big Ben model and access any application via their APA, their authentication model.
We cannot jump in because even Kubernetes is also on the cloud. We can plan the image, optic tree, and master node and then reuse the maximal level, but we cannot recreate that.
What other advice do I have?
I rate Azure Block Storage eight out of 10.
Which deployment model are you using for this solution?
Public Cloud
If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?
Microsoft Azure
*Disclosure: My company has a business relationship with this vendor other than being a customer: Partner