A while ago I talked about “Faas/Serverless” in relation to vendor lock-in. Today we’ll be continuing in that road, where we’ll be doing a small proof-of-concept (PoC). In this PoC, we’ll be replatforming existing Azure Functions code into an Azure Functions container!
Things to know
Since Azure Functions 2.0 (in preview at the time of writing this post), you are able to leverage containers. Though be aware that there are several known issues. Do check them out first before embarking on your journey!
So first, we’ll start off with testing the Azure Functions Core Tools! If you’re looking to follow this guide, be sure to have the Azure Functions Core Tools installed, which also depends on .NET Core 2.0 and Nodejs. Once you have those installed, do a “func –help”, and you’ll see what capabilities are at hand…
Continue reading “Replatforming Azure Functions into an Azure Functions Container”
A lot of workloads are driven by peak consumption. From my experience, there aren’t the amount of workloads that have a constant performance need are in the minority. Now here comes the interesting opportunity when leveraging serverless architectures… Here you only pay for your actual consumption. So if you tweak your architecture to leverage this, then you can get huge gains!
For today’s post, I’ll be using VMchooser once again as an example. A lot has changed since the last post on the anatomy of this application. Here is an updated drawing of the high level architecture ;
Underneath you can see the flow that’ll be used when doing a “Bulk Mapping” (aka “CSV Upload”). The webapp (“frontend”) will store the CSV as a blob on the storage account. Once a new blob arrives, a function will be triggered that will examine the CSV file and put every entry onto a queue. Once a message is published onto the queue, another function will start processing this message. By using this pattern, I’m transforming this job into parallel processing job where each entry is handled (about) simultaneously. The downside of this, is that there will be contention/competition for the back-end resources (being the data store). Luckily, CosmosDB can scale on the fly too… We can adapt the request units as needed; up or down! So let’s do a small PoC and see who this could work…
Continue reading “Serverless On-Demand Scaling : Pushing the pedal when you need it…”
In my current role at Microsoft, I often talk about the possibilities in regards to application modernization. A typical ask in this space is to what kind of service they should use as a underlying platform for their own services. Where this commonly results in a (brief) discussion about VMs vs Containers vs Serverless/FaaS. Today’s post is about my personal take on the matter.
Setting the scene
First let’s start with setting the scene a bit… For today I’ll try to focus on the application modernization landscape, where the same goes for the data platform stack. Here you can pretty much interchange “Functions” with “Data Lake Analytics” and “Containers” with “HD Insights”. Though we’ll not go into that detail, in order to reduce the complexity of the post. 😉
When looking towards the spectum, the first thing to acknowledge is the difference in service models. Here we mainly have two service models in play ;
Continue reading “FaaS & Serverless – Vendor lock-in or not? Consider the cost of the full application lifecycle”
In my discussions with customers about “serverless”, we often talk about the typical security patterns when embarking on the deployment of functions for Enterprise organizations. A typical combination we see here is where Azure API Management is used in front of Azure Functions. Today we’ll talk about the options at hand here. In essence this will related to a choice where an organization will need to choose between “Fully Isolated” and “Full Flexibility”!
Continue reading “Hardening Azure Functions when exposing them via Azure API Management”
Today’s post will be on how to expose an API hosted via an Azure function via Azure API management. So what are we going to configure today? We’ll expose the function API externally. The “user” (or client app) will authenticate with API management via a “subscription key“. Afterwards API management will call the back-end function, where it will authenticate via the function authentication code.
So let’s go to our function …
Where we’ll grab the “function URL”. This contains the query parameter “code” which uses the function key as authentication.
Continue reading “Putting Azure API Management in front of an Azure Function API”
There are various articles/blogs/etc that compare logicapps vs flow vs functions vs azure automation, etc… Though there was one use case where I often struggled what to use ;
What to use when I want to retrieve a file from X on a Y timed interval?
Azure Functions? Great abstraction, though the output files have random names. Sometimes / Often I want to be able to control that.
Flow? Doesn’t allow the customization I was looking for. More to integrate existing / popular services.
Azure Automation? Very good and gets the job done. The only downside, you need to code a lot of logic yourself.
Azure Logic Apps? Shows potential, but doesn’t let you include custom functions. Or does it…?!?
You can link Azure Functions to Logic Apps and create some the flow I was looking for.
So what do I want to do?
- On a daily basis
- Retrieve content from an authenticated API
- Save the content to a Blob storage
And afterwards I’ll use other services to process that data. 🙂
What do I want to achieve? On a daily basis I want to retrieve data from a service provider that serves sports data. And if you are looking for such a thing, check out MySportsFeed! So back to our proof-of-concept; how will this look in Logic Apps?
Let’s dissect this flow…
Continue reading “Azure : Mixing LogicApps & Functions as a periodic data retriever”
A few weeks back I posted a blog post on how you can leverage “serverless” components for IoT. Today I’ll show you what it would mean if we replace the Azure Functions component in that post by Azure Stream Analytics.
So the flow between device and event hub is untouched. Though we’ll replace the functions part with Azure Stream Analytics. So how will the end result look?
We’ll be using one Stream Analytics job to trigger three flows. One will store the data into an Azure Table Storage, another on will store it as a JSON file on to Azure Blob Storage and another one will stream it directly into a PowerBi dataset.
So let’s take a look at all the components from within this Stream Analytics Flow we’ll be using…
Continue reading “Basic Azure IoT Flow : From Event Hub via Stream Analytics to Power Bi”