In the past I’ve noticed a lot of people are afraid of “Azure Resource Manager Templates“. I can imagine that a bulk of JSON code isn’t always that user friendly… So today we’ll take a look at another IaC (Infrastructure-as-Code) approach you might like. We’re going to do a small demo where we’ll be using “Terraform” to deploy a network on Azure. So how to get started?
- We’ll be creating a kind of service user in Azure which Terraform will use to log in.
- We’ll be authoring a small configuration file that will serve as the input for our network
- We’ll be applying that configuration file.
Seem simple enough? Let’s get started!
Continue reading “An alternative way to landscaping in Azure… Terraform!”
In my role as a Cloud Solution Architect, I’m often faced with the statement that cloud is expensive. My reply is always that Cloud is not expensive (more expensive than On Premises) if you take into account all the costs involved. As this is an easy statement to make… I made an effort to create a cost comparison for four different scenario’s (in term of deployment size) and stacked “OnPremises” vs “Cloud”.
In this post we’ll discuss this calculation and ensure that we are comparing apples to apples!
Continue reading “Comparing Costs : Is Cloud more expensive than an On Premises setup?”
Earlier today I retweeted the following tweet…
Which got the following reply…
Today’s post is an opinion piece in regards to my take on “hybrid” cloud. This as I can relate to both statements made here.
“All clouds are equal, but some clouds are more equal than others.”
If you have ever had the (un)pleasantry of seeing my present on cloud in a non-technical manner, then you must have seen this slide…
Continue reading “Opinion : Hybrid Cloud =/= Hybrid Cloud, and how does private cloud link to that?”
A while ago I saw a kinda flow chart / subway map entailing the various paths to migrate your workloads to the cloud. My personal view on the matter differed slightly from this, so I’ve mocked up my own version…
The various tracks ;
- “Retire” ; For the workloads that are not relevant anymore to the business… decommission them.
- “Re-Host” ; A typical “lift & shift” scenario where you move the system “as-is” to the cloud.
- Variant “Manual” ; Tedious effort… doing a manual rebuild of your systems in the cloud.
- Variant “Automated” ; Work via migration tooling or redirect your automated deployments.
- “Re-Purchase” ; Some applications are not compatible with cloud platforms. Therefore it might sometimes be interesting to purchase another software suite. Where you’ll join the manual track once the implementation starts…
- “Re-Platform” ; Cloud provider typically offer “PaaS”-services too, where an On Premises deployment only favors “IaaS”-thinking. Examples here ; IIS on premises vs Webapps in the cloud.
- “Re-Architect” ; If you have control over your application, you might consider to refactor it towards cloud native components. Given, this is not always an easy/cheap task, but it’s a play considering the long term.
But for all, it starts with ;
- Discover ; Identify all the workloads in your IT landscape.
- Assess ; Investigate their readiness towards the cloud and which migration paths are viable.
And “ends” with ;
- Validate ; After a “construct” / “deploy”, always validate (test) if everything is according to your expectations / specifications.
- Transition ; Never forget to ensure that your operational team is ready before the “go live” of your workload.
- Go-Live ; The moment your customers will use the workload. 🙂
Yesterday Rancher commented on my github request for windows support ;
Tested with rancher-server version – v1.3.0-rc1 with catalog “library” set to
vnext branch in
Able to add “Windows Server 2016 Standard Evaluation” hosts successfully to rancher environment with orchestration set to “windows”.
Able to launch containers in “nat” network and “transparent” network.
@kvaes , Windows 2016 support will be available as experimental feature in rancher-server 1.3.0 release.
Great news! Let’s take it out for a spin… 😀
Installing the host(s) is the same as any other time… Though the host will still be a Linux machine off course ;
sudo docker run -d –restart=unless-stopped -p 8080:8080 rancher/server:v1.3.0
Though notice that I specified the v1.3.0
-rc1 tag… And let the system do its magic!
(Update : For the stable, release you can omit the -rc1 part!)
Note ; Be aware that this is an early release candidate. Do not use this for your production! There is for instance a bug with the GUI, where the “Auto”-theme is malfunctioning. So switch to light or dark to get that one fixed. 😉
Continue reading “How to try out the experimental windows 2016 support in the Rancher 1.3.0 release candidate?”
A few days ago my connectors arrived for my latest PoC on Azure. So today I’m writing about my experience in using a RaspberryPi with a temperature & humidity sensor and to save the telemetry data in Azure. For this we’ll be using Azure Event Hub as an ingress mechanism, and Azure Functions to storage the events towards an Azure Storage Account. My next venture will be to use this data to create reports and maybe (on the long run) do some machine learning. For the latter, I’m pondering about linking this system to my ebus system of my heating system. That way I could correlate the data from the various censors (RPi, Thermostat & outside sensor) in combination with the heater information & heating schedules. Basically… creating my own Google Nest. 🙂
Sensor : Physical Connection (I2C)
The guys from ThingTank had a spare sensor lying around, which they lend to me for my PoC… This was a “Grove – Temperature&Humidity Sensor (High-Accuracy & Mini)“. As you can see in the picture, underneath, this one has an I2C connector. We see four connections ; GND, VCC, SDA & SCL.
Continue reading “Azure IoT : From RaspberryPi with Sensor to Azure Storage Table by using a serverless architecture”
Azure functions is the “serverless” offering on Azure. Serverless doesn’t mean there aren’t any servers, but it’s rather a platform service where you can run your own snippets of code. Each code can be triggered, where it then can have an in and/or output. In terms of billing, you pay for the amount of runtime you consume.
Imagine having a stateless web front end which publishes state onto a queue or storage account. Then Azure functions is being triggered and your business logic starts. Sounds familiar? Yes, because that’s a typical flow you normally do in your application stacks. Now you can segment that even more into services you do not need to manage.
Today I’m going to show you a very brief demo on using an Azure Event Hub as trigger/input for an Azure function. So what’s the flow we’ll be doing?
- A client will put a message on the event hub queue
- This will trigger an Azure function
- The function will save the contents of the message onto a storage account
Sound simple right? And it actually is that simple to do too!
Continue reading “Azure Functions : A quick demo when using Event Hub”