For today’s post, we’ll be deploying a java web-app to Azure. Here we’ll be leveraging our well-known “App Service” as the underlying PaaS component to host our web-app.
Sample Workload : Geoserver
For today’s example, we’ll be using “geoserver” as the grounds for our little proof-of-concept. In addition, we’ll even trow in the Azure PostgreSQL Database for the back-end store.
Continue reading “Azure App Service : Deploying a java webapp (geoserver) to Azure”
When moving to the cloud, one cannot imagine this without some kind of network integration. Taking a look at “Infrastructure-as-a-Service”, there are several common patterns that are utilized by enterprises. Today we’ll discuss these patterns…
Typical Network Maturity Models
Embarking on a cloud journey? You’ll typically go through the following patterns depending on your “maturity level” in working with the cloud ;
- “Island” : The first approach is typically “the island”. The VMs reside in a VNET that is not connected/integrated with any other networks, except for (maybe) the internet.
- “Forced Tunneling” : The first step towards integration is “forced tunneling”. Here you want to access “On Premises” resources, though the mass of the resources on Azure do not justify the investment into a “Network Virtual Appliance” (AKA Firewall). Here you set up a “UDR” (User Defined Route, AKA Static Route), where you force all traffic to go back to the “On Premises” network.
- “Single VNET with DMZ” : One step beyond “forced tunneling”, is moving towards the typical DMZ-alike pattern, where you setup a HA-pair of “Network Virtual Appliances” and segregate network zones.
- “Hub & Spoke”-model : Growing even further, you’ll have multiple subscriptions. Setting up “NVAs” on all of those can be quite expensive. In terms of governance, this also a nice model, where you can consolidate all network integration into a segregated subscription/vnet.
The advantage of these patterns is that you can evolve into another pattern without breaking anything in terms of design.
Continue reading “Azure Networking : Blueprint patterns for enterprises”
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”
Today’s post is conceptually a rather simple one… Let’s see how we can go from this ;
To here ;
By using a CI/CD pipeline.
Flow of the day
What will we be doing today?
- Kick-off a VSTS build once a change has been made to our Github repo
- Build a container via VSTS
- Publish the container to an ACR (Azure Container Registry)
- Kick-off a VSTS release once the build succeeded
- Use an ARM template to deploy an ACI (Azure Container Instance) with our docker container underneath
Sound cool? Let’s get to it!
Continue reading “From Github to ACI – A tale how to use Visual Studio Team Services & Azure Container Registry for Container CI/CD”
In the past I’ve already done several posts about containers. This by using various orchestrators & workflow management tools. Today’s post will be about deploying a Linux container with Service Fabric… The main goals is to provide you with the look & feel of the initial steps. In a future posts, I’ll delve into the more advanced stuff (like data persistence & inter-container connectivity).
Continue reading “Azure Service Fabric : Deploying your first container…”
The Azure Container Instances (ACI) have just been announced. Today we’ll take a quick glance on how it looks in reality. Though what are ACIs?
Azure Container Instances offers the fastest and simplest way to run a container in Azure, without having to provision any virtual machines and without having to adopt a higher-level service.
Want to try it yourself? Check out the ACI Quickstart!
Let’s see how it looks?
In contrast to the quick start, I’m going to use the portal… This is currently not the preferred way, though let’s see how that one looks at the moment.
Continue reading “A quick glance at the newly announced Azure Container Instances”
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!”