Integrating Spin with Azure services
As it currently stands, Spin applications written in Go, Python, and JavaScript are not able to use their respective Azure SDKs, which can make it challenging to know how to integrate Spin with some other services within an Azure production cloud environment.
As a workaround, we have built a new Spin component that makes HTTP calls directly to Azure’s API endpoints for Azure Blob Storage and Azure Queue storage services, which can be integrated into your Spin app and accessed via internal HTTP calls.
A quick note about Spin components: These are packaged pieces of code written in one language (in this case Golang) that allow you to integrate them into a single binary file written in any other language that Spin supports. You can think about it like a library that any language can use. See our blog post on the component model for more information.
What is Spin?
Spin is an open-source framework for building WebAssembly applications, which has a ton of amazing features, including portability (a single binary can run on many architectures), and millisecond cold-start times, which means an application is ready as soon as you deploy it. See our introduction for more details.
Benefits of migrating from serverless to Spin
While function-as-a-service products (FaaS) like Azure Functions offer remarkable scalability and simplicity, they are not without their issues. Three significant pain points for FaaS customers are cost, cold-start times (how long it takes to have the code ready for execution), and vendor lock-in (you are forced to use a specific cloud provider because switching will cost too much money and/or time). Spin solves these problems by offering sub-millisecond cold-start times, a significant reduction in cost if deployed using Fermyon Platform for Kubernetes, and cloud-agnostic portability, meaning your applications can be run on any Kubernetes cluster running SpinKube regardless of chip architecture.
When is Spin not a good alternative to serverless?
Although Spin offers some amazing features, there are some situations for which it may not be a good fit. For example, if FaaS is not severely impacting the cost to run your applications, or if cold-start times are not meaningfully affecting the performance of your applications. In these cases, the work required to migrate existing infrastructure to Spin may not be justified by the relatively small improvements in cost and performance. Another situation where Spin may not be a good fit is if your applications rely heavily on libraries which Spin doesn’t yet support. It’s not impossible to find workarounds (as we have with the Azure SDK); however, there are some libraries for which we have not been able to create a workaround (see our language guides for more information).
How to get started
We have put together thorough documentation that will explain how to integrate and use the Azure component: https://github.com/fermyon/experimental-azure-client
How to get help
We understand that integrating a new technology can be challenging. If you have questions or feedback, reach out to us on our Discord channel.
