During the weekend I saw the following tweet passing by …
Apparently, a hosting company (allegedly) got all their data wiped by an ex-admin. Now I can imagine people thinking that this is something that is part of the territory when it boils down to cloud. So I wanted to write a blog post entailing what you do to set up a governance structure in Azure. Here I’m aware that the above tweet is more related to the security aspect of governance, it’s a part of it nevertheless.
Let’s get started on our scope… IT Governance can cover a lot of ground. In essence, the goal is to assure that the investment in IT generates business value and the risks that are associated with IT projects are mitigated. Though I found that CIO.com has a nice definition on it ;
Simply put, it’s putting structure around how organizations align IT strategy with business strategy, ensuring that companies stay on track to achieve their strategies and goals, and implementing good ways to measure IT’s performance. It makes sure that all stakeholders’ interests are taken into account and that processes provide measurable results. An IT governance framework should answer some key questions, such as how the IT department is functioning overall, what key metrics management needs and what return IT is giving back to the business from the investment it’s making.
So let’s take a look at how we can put an enterprise-grade structure around the management of Azure!
TL;DR = Azure Enterprise Scaffold
For those who want to skip the post below… When talking about governance in Azure, the best place that summarizes it the following page in our documentation ; “The Azure Enterprise Scaffold“.
Continue reading “Azure : IT Governance in the cloud”
From template code to deployment… If we really want to control this, then we’ll be pushing these templates through a CI/CD (continuous integration / continuous deployment) pipeline. What does that mean? We are going to put our template in a source code repository (like Github). Everytime we update the code, we’ll going to kick in a “build”. During this build we’ll be packaging it (read : create a zip file of it) and it is also strongly advised to do testing here too. Next up, if all goes well, we’ll be using that package to deploy to all our environments. And in the end, we want to be able to have a nice view on this too…
Why do it like this? Quality! We all make mistakes. We want to detect them early and not repeat them. And every change, we want to put it through the exact same process… time and time again!
Starting off, I’m assuming you already have VSTS (Visual Studio Team Services) in place. If not, register for it! It’s free up till 5 users. And let’s be honest, at about 5€ per user / month & 8€ per build agent per month, … it’s still a steal! 😉
Continue reading “Azure : Pushing Azure Resource Manager Templates through a CI/CD (release) pipeline with Visual Studio Team Services”
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?”