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 an earlier blog post I discussed the decision criteria in selecting a VM. In that post I also showed a tool called “VMchooser“. Today’s post will be on the architecture I used to build this one. As you might have guessed, it’s built on Azure components. Let’s get to it and check the anatomy of this application.
High Level Architecture
VMchooser has the following high level architecture ;
- Web App : The front-end of the application is hosted on an Azure Web App.
- Azure Functions : The back-end API & batch parser are built with Azure Functions. Which unlocks insane scaling possibilities.
- Storage Account : The storage account serves as decoupled/central storage component for the batch parsing. And it could also be used for hosting the “database” (flat file).
- Application Insights : Application insights is used to have the needed insights into the usage & other metrics.
- Github : All code for this project is open-source and publically hosted. You can run your own VMchooser if you want… 😉 Every change is immediately pushed towards the front-end, back-end & database.
- API Management : As the back-end API is decoupled from the application, I’ve also linked this api with api management. This would provide me with the option to allow 3th party application integrations via an API subscription plan.
Continue reading “The anatomy of “vmchooser”… Adding some serverless into the architecture!”
When I was working on the “CSV import” of VMchooser, I noticed that long jobs sometimes had issues. After some investigation, it quickly became apparent that I was hitting the time-out. So I had a need to increase it…
Logic Apps Time-out = 2 minutes
As a bit of back story, I first started off with my async parsing flow by using the combination of logic apps & functions. Where I at first thought it was due to the time-out on the functions side, it actually appeared to be on the logic apps side. And that one cannot be changed…
Azure Functions Time-out
So I browsed the web, and encountered two variables, which I both set on my platform ;
To reach set these, click on your functions bar (“kvaesvmapi” here), then “Platform Features”, and then “Application Settings” ;
But let’s get back to the variables… From various posts I saw these two popping up. Where I set them both to be safe, I started investigating a bit. The first one ;
WEBJOBS_IDLE_TIMEOUT – Time in seconds after which we’ll abort a running triggered job’s process if it’s in idle, has no cpu time or output (Only for triggered jobs).
This is actually the one you need for your function. As it’s clearly described in the kudu docs. Where the second one apparently is only related to the deployment phase; hence the “SCM_”-prefix.
Set the “WEBJOBS_IDLE_TIMEOUT” in your “Application Settings” ;
And don’t be distracted by the “SCM_COMMAND_IDLE_TIMEOUT”. 😉
For today I’ll show you how to roll your own rss2twitter bot in about 15 minutes. What will this bot do?
- Check an RSS feed for new entries
- Parse the new entry and replace key words with hashtags
- Post it to twitter
For this we’ll be using ;
- Azure Function : as the customer code to find/replace certain words
- Logic App : as the tool to create our process via a visual tool
And in the end, we’ll see something like this ;
Continue reading “How to roll your own rss2twitter bot in 15 minutes in Azure?”
With one of my flows, I was using an Azure function to generate a filename for my Azure logic app. This name was generated based on the date…
What did I see happening…
As I the script ran just after midnight, I saw that I was getting the day before instead of the actual date.
Continue reading “Changing the timezone on your Azure Webapp / App Service / Function”