When you have an SPA (Single Page App), all your code is being run inside of your browser. This means that, from a network perspective, you’ll be talking to the APIs directly. It’s often (rightfully) said that SPAs are an untrusted client, where a typical server-side app is seen as a trusted client. Why is an SPA seen as untrusted? Because from the publisher side (the one providing the service/app), you do not control the device running the code. So this has a huge effect on the security risks involved and how you should mitigate them.
One of those mitigations is “CORS” ;
Cross-origin resource sharing (CORS) is a mechanism that allows restricted resources (e.g. fonts) on a web page to be requested from another domain outside the domain from which the first resource was served. A web page may freely embed cross-origin images, stylesheets, scripts, iframes, and videos. Certain “cross-domain” requests, notably Ajax requests, are forbidden by default by the same-origin security policy. (Source : Wikipedia)
With CORS, the request will indicate from which domain the calls would originate (and what actions / headers it would like to do). Therefore, the backend can check if the call is warranted or not…
Continue reading “When your Single Page App needs CORS and meets Azure API Management with a Function Backend”
Like many organization, you’re probably also looking for a more “rapid development” track for a subset of your applications. I’ve heard a lot of reasons for this… Going from rapid prototyping to having small apps that make life a lot easier within the organization (like typical approval flows). For this we’re going to see how we can combine PowerApps & Azure Functions! By using PowerApps we want to take a low/no-code approach to creating the front-end, where Functions (or even Logic Apps as an alternative) will allow us to provide specific back-end data.
Recipe for today
Today we’ll be using the following ingredients as a base for the recipe of the day ;
Here we’ll be building a small powerapp that’ll call an API (OpenAPI Spec) that is hosted as an Azure function. So basically connecting a low/no-code app to a serverless API.
Continue reading “PowerApps & Functions – Where low/no-code meets serverless… organizations can create apps faster!”
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 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!”