I’ve been looking around for a decent Azure Storage client library that I can use to interact with:
Azure Blob Storage
Azure Queue Storage
Azure Fileshare
Azure Table Storage
So, I decided to create one not that I really need the library but it is a great opportunity for me to learn Elixir.
Self-proclaimed: I am an Elixir noob so you might find my code a bit raft, however, I did manage to get it going. It will be an honor if I could get to hear your critics on how I implement stuff.
I will look at if we can make a similar pattern to ex_aws where we have the core request logic in a separate lib (similar to what you did with request here).
First goal would be to build in support for the «fallthrough» config of aws where it looks in the following order:
app config
env vars
credential endpoint
Nr 3 has a similar variant for app service and functions in managed azure ad identities which is similar to iam assignable roles in aws.
I think the IAM centric and enforced route of AWS for s3 is a lot less ambigous than the possibility of a storage key, so I need to do some thinking on how that extra dimension would work.
On a separate note, I actually work for Microsoft (not in engineering), will ask around if there is interest in contributing. I think we should at least write up a deployment guide that can utilize managed identities etc to make good zero trust deploys using libs like these.
I also work for Microsoft, and am working on an Elixir app that deals quite a lot with storage. I’ll chip in as well. We might want to also ask @strzibny and @chgeuer if they’re interested.
Fantastic! my current implementation is inspired by #ex_aws (request context) the rest is by reading API spec and reverse-engineering https://www.npmjs.com/package/azure-storage v2 especially when I need to confirm shared key generation.
This is very nice! I did come across a use case in the system that required us to share a blob with external parties. So definitely, I’m going to bundle this functionality in the upcoming release. Thanks, @jeramyRR for sharing and @strzibny for writing the article.