There are a number of scenarios that can be used to put the new infrastructure in production as the replacement for an existing system – to “Go Live”:
- Big Bang – In the big bang scenario, at a set time, the existing system is switched off and the new system is immediately put in production, possibly after a short data migration run. This is the riskiest scenario because it may be impossible to roll back to the old system after the system is live for some time, and because downtime can occur when something goes wrong during the switchover.
- Parallel changeover – In this scenario, both the new and the existing system run simultaneously for some time (typically weeks). This allows for testing the new system on both functionality and non-functional attributes, and ensuring it works with live production data before switching off the existing system. As both systems are running and processing data, switching back is possible at any time, minimizing risk. A big disadvantage of this scenario is the cost of maintaining both systems and the possible extra work to keep both systems in sync. Also, many system designs don’t allow running two systems in parallel, for instance, if the system has many interfaces with other systems.
- Phased changeover – In a phased scenario, individual components or functionalities of the existing system are taken over by the new system, one by one. This reduces risk, as the changeover can be done gradually and controlled. This scenario can be quite costly, since typically many interfaces between the existing and the new system must be created and maintained. These new interfaces introduce new risk to the scenario, as they must be tested extensively and could fail in production. Also, the existing system must be kept online until the last component or functionality is moved to the new system, which can take considerable time and can lead to high cost.
While in theory a big bang scenario has the highest risk, in practice, it is most often used, as the scenario is the least complex to execute, and because the risk is limited to the changeover moment, when the project team is at full strength and ready to jump in if anything fails.
The go-live should be very well prepared. After the go-live scenario is determined, a step-by-step plan must be created describing each step in the scenario in detail. This plan must be reviewed, tested and improved multiple times, well in advance of the go-live date to eliminate possible surprises and to minimize risk. The scenario should include intermediate tests and multiple “go/no go” milestones, where the go-live can be aborted if anything unexpected happens. The plan should also have a defined point of no return – a go decision at this point means there is no way back to the old system. Either because there is no time left to move back to the original situation, or because an irreversible step is taken (like an update of a critical data model).
At the go-live date, high alert is needed from the project team and from the systems managers, service desk and senior management to be able to fix any issues that might arise.
After the new system is live, on-site support should be available for a predetermined time to resolve problems that may arise after the system is live; problems for which the service desk cannot yet be responsible.
This entry was posted on Thursday 06 November 2025
Where IaC defines infrastructure components, configuration management tools define the configuration of those infrastructure components. For example, a VM can be deployed using IaC, but the software that runs on that VM, or its operating system parameters, must be configured afterwards. This is a job for configuration management tools. Configuration management also uses declarative languages that define the desired state of the configuration.
The most used configuration management tools are Ansible, Puppet, and Chef.
Ansible uses YAML playbooks to define resources and can be used to automate server provisioning, configuration management, application deployment, and more. Ansible is agentless and can be used to manage a wide range of platforms, including cloud and on-premises servers.
As an example, the following Ansible playbook creates a httpd webserver on a Linux server:
- name: Install httpd
hosts: webserver
become: yes
tasks:
- name: Install httpd package
yum:
name: httpd
state: present
- name: Start httpd service
service:
name: httpd
state: started
enabled: yes
Puppet is a configuration management tool that can be used to manage servers, networks, storage, and more. The following Puppet manifest creates a httpd webserver on a Linux server:
# Install httpd package
package { 'httpd':
ensure => 'installed',
}
# Start httpd service
service { 'httpd':
ensure => 'running',
enable => true,
}
Chef is another configuration management tool. It uses a domain-specific language called Ruby to define infrastructure resources and provides features like idempotency, versioning, and testing. Chef can be used to manage servers, networks, storage, and more.
The following Chef recipe creates a httpd webserver on a Linux server:
# Install Apache HTTP Server (httpd) package
package 'httpd' do
action :install
end
# Start and enable httpd service
service 'httpd' do
action [:start, :enable]
end
Configuration management tools are often run periodically, for instance every few hours, to ensure any manual change to the deployed environment is reverted to the state as defined in the configuration management tool.
This entry was posted on Wednesday 01 October 2025
There are several commonly used IaC languages. Below are some of the most popular ones.
Terraform is a popular open-source tool and Domain-Specific Language (DSL) for building, changing, and versioning infrastructure. Terraform is cloud agnostic, which means that it has a generic syntax can be used to configure a wide range of cloud providers and infrastructure platforms, including AWS, Azure, GCP, Kubernetes, Red Hat OpenShift, databases like MySQL and PostgreSQL, firewalls, and more. But it must be noted that each platform needs its own configuration details – in Terraform, configuring an EC2 VM in AWS is done differently than configuring a VM in Azure.
As an example, the following Terraform code creates a virtual machine in Azure:
Resource "azurerm_network_interface" "mynic" {
name = "myvm1-nic"
location = "northeurope"
resource_group_name = "MyRG"
ip_configuration {
name = "ipconfig1"
subnet_id = azurerm_subnet.frontendsubnet.id
private_ip_address_allocation = "Dynamic"
}
}
Resource "azurerm_windows_virtual_machine" "example" {
name = "myvm1"
location = "northeurope"
resource_group_name = "MyRG"
network_interface_ids = [azurerm_network_interface.mynic.id]
size = "Standard_B1s"
admin_username = "adminuser"
admin_password = "Password123!"
source_image_reference {
publisher = "MicrosoftWindowsServer"
offer = "WindowsServer"
sku = "2019-Datacenter"
version = "latest"
}
os_disk {
caching = "ReadWrite"
storage_account_type = "Standard_LRS"
}
}
As a comparison, the following Terraform code creates an EC2 virtual machine in AWS:
resource "aws_instance" "example" {
ami = "ami-0be2609ba883822ec" # Windows Server 2019 Base
instance_type = "t2.micro"
key_name = "my_keypair"
vpc_security_group_ids = [aws_security_group.allow_rdp.id]
subnet_id = "subnet-12345678"
associate_public_ip_address = true
private_ip = "10.0.1.10" # Private IP address of the instance
user_data = <<-EOF
<powershell>
# Set the administrator password
net user Administrator <password>
</powershell>
EOF
}
}
As you can see, the syntax is the same, but the way the virtual machine is created is different between the cloud providers.
Azure Resource Manager (ARM) templates are JSON files that describe Azure infrastructure resources. ARM templates provide a declarative syntax for defining the infrastructure resources and their dependencies, as well as the configuration settings for each resource.
Azure Bicep is a Domain-Specific Language (DSL) for Microsoft Azure. Bicep builds on top of ARM templates and provides an abstraction layer that allows developers to write code that is easier to read and write than ARM templates. Bicep supports the same resources and functionality as ARM templates, but with a more intuitive syntax, better error handling, and reusable modules.
The following Bicep script creates a virtual machine in Azure:
param location string = 'eastus'
param vmName string = 'myVm'
param adminUsername string = 'admin'
param adminPassword string = 'password'
resource vm 'Microsoft.Compute/virtualMachines@2021-04-01' = {
name: vmName
location: location
tags: {
environment: 'dev'
}
properties: {
hardwareProfile: {
vmSize: 'Standard_D2_v3'
}
storageProfile: {
imageReference: {
publisher: 'MicrosoftWindowsServer'
offer: 'WindowsServer'
sku: '2019-Datacenter'
version: 'latest'
}
osDisk: {
createOption: 'FromImage'
}
}
osProfile: {
computerName: vmName
adminUsername: adminUsername
adminPassword: adminPassword
}
networkProfile: {
networkInterfaces: [
{
id: resourceId('Microsoft.Network/networkInterfaces', '${vmName}-nic')
}
]
}
}
}
resource nic 'Microsoft.Network/networkInterfaces@2021-02-01' = {
name: '${vmName}-nic'
location: location
properties: {
ipConfigurations: [
{
name: 'ipconfig1'
properties: {
subnet: {
id: resourceId('Microsoft.Network/virtualNetworks/subnets', 'myVnet', 'default')
}
privateIPAllocationMethod: 'Dynamic'
}
}
]
}
}
Google Cloud Deployment Manager allows to define and manage GCP cloud infrastructures using YAML or Python templates. It is similar to Azure ARM templates. Google Cloud Deployment Manager defines and manages GCP resources, such as Compute Engine virtual machines, Google Kubernetes Engine clusters, Cloud Storage buckets, and Cloud SQL databases.
The following Cloud Deployment Manager YAML script creates a virtual machine in GCP:
resources:
- name: my-vm
type: compute.v1.instance
properties:
zone: us-central1-a
machineType: zones/us-central1-a/machineTypes/n1-standard-1
disks:
- deviceName: boot
type: PERSISTENT
boot: true
autoDelete: true
initializeParams:
sourceImage: projects/debian-cloud/global/images/family/ debian-10
networkInterfaces:
- network: global/networks/default
accessConfigs:
- name: External NAT
type: ONE_TO_ONE_NAT
AWS CloudFormation allows to define and manage AWS cloud infrastructures using JSON or YAML templates. It is similar to Azure Resource Manager (ARM) templates and Google Cloud Deployment Manager. CloudFormation can define and manage AWS resources, such as EC2 instances, S3 buckets, and RDS databases.
The following CloudFormation script creates an EC2 virtual machine in AWS:
AWSTemplateFormatVersion: '2010-09-09'
Resources:
EC2Instance:
Type: 'AWS::EC2::Instance'
Properties:
ImageId: 'ami-0c55b159cbfafe1f0' # Ubuntu 20.04 LTS
InstanceType: 't2.micro'
KeyName: 'my-key-pair'
NetworkInterfaces:
- GroupSet:
- 'sg-0123456789abcdef' # security group
AssociatePublicIpAddress: 'true'
DeviceIndex: '0'
DeleteOnTermination: 'true'
This entry was posted on Wednesday 30 April 2025
The goal of edge computing is to bring computing power and data storage closer to where it is needed, rather than relying on a cloud or on-premises datacenter. In edge computing, compute and storage take place on devices at the edge of the network, such as routers, gateways, switches, and sensors.
Edge computing can be a viable option where low latency, high bandwidth, and real-time processing are critical. For example, in the case of autonomous vehicles, real-time decision making is critical for safety. In this scenario, edge computing can enable the vehicle to process data and make decisions locally, rather than sending all sensor data to a centralized datacenter.
Edge computing is also gaining popularity in Internet of Things (IoT) applications, where a large number of devices generate data that must be processed in real time. By using edge computing, organizations can reduce the amount of data that needs to be sent to the cloud, which can reduce costs and improve performance.
This entry was posted on Monday 31 March 2025
In recent years, we have seen the widespread adoption of cloud computing. Cloud computing can be seen as one of the most important paradigm shifts in computing in recent years. Many organizations now have a cloud-first strategy and are taking steps to move applications from their own on-premises datacenters to the cloud managed by cloudproviders.
The term cloud is not new. In 1997, Ramnath Chellappa of the University of Texas already stated:
Computing has evolved from a mainframe-based structure to a network-based
architecture. While many terms have appeared to describe these new forms,
the advent of electronic commerce has led to the emergence of 'cloud computing‘.
While there are many public cloud service providers today, the three largest are Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP). Together, these three have 66% of the market share and have a large number of datacenters around the world. The following picture shows when each of these cloud providers started.
The three major cloud providers offer similar services, but sometimes under different names. For instance, a virtual machine in Azure is just called a virtual machine, but in GCP it is called a Compute Engine and in AWS it is called an EC2 instance.
While cloud computing can be seen as the new infrastructure, many organizations will be using on-premises infrastructure for many years to come. Migrating a complex application landscape to a cloud provider is no simple task and can take years. And maybe an organization is not allowed to take all its applications to the cloud. In many cases, there will be a hybrid situation, with part of the infrastructure on-premises and another part in one or more clouds.
Please be aware that the cloud is just a number of datacenters that are still filled with hardware – compute, networking and storage. Therefore, it is good to understand infrastructure building blocks and principles even when moving to the cloud.
Cloud definition
The most accepted definition of cloud computing is that of the National Institute of Standards and Technology (NIST)[i]:
Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources(e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction.
It is important to realize that cloud computing is not about technology; it is an outsourcing business model. It enables organizations to cut cost while at the same time focusing on their primary business – they should focus on running their business instead of running a mail server.
Clouds are composed of five essential characteristics, four deployment models, and three service models.
Cloud characteristics
Essential cloud characteristics are:
- On demand self-service – As a result of optimal automation and orchestration, minimal systems management effort is needed to deploy systems or applications in a cloud environment. In most cases, end uses can configure, deploy, start and stop systems or applications on demand.
- Rapid elasticity – A cloud is able to quickly scale-up and scale-down resources. When temporarily more processing power or storage is needed, for instance as a result of a high-exposure business marketing campaign, a cloud can scale-up very quickly on demand. When demand decreases, cloud resources can rapidly scale down, leading to elasticity of resources.
- Resource pooling – Instead of providing each application with a fixed amount of processing power and storage, cloud computing provides applications with resources from a shared pool. This is typically implemented using virtualization technologies.
- Measured service – In a cloud environment the actual resource usage is measured and billed. There are no capital expenses, only operational expenses. This in contrast with the investments needed to build a traditional infrastructure.
- Broad network access – Capabilities are available over the network and accessed through standard mechanisms.
Be aware that when using public cloud based solutions, the internet connection becomes a Single Point of Failure. Internet availability and internet performance becomes critical and redundant connectivity is therefore key.
Cloud deployment models
A cloud can be implemented in one of four deployment models.
- A public cloud deployment is delivered by a cloud service provider, is accessible through the internet, and available to the general public. Because of their large customer base, public clouds largely benefit from economies of scale.
- A private cloud is operated solely for a single organization, whether managed internally or by a third-party, and hosted either on premises or external. It extensively uses virtualization and standardization to bring down systems management cost and staff.
- A community cloud is much like a private cloud, but shared with a community of organizations that have shared concerns (like compliance considerations). It may be owned, managed, and operated by one or more of the organizations in the community, a third party, or some combination, and it may exist on or off premises.
- In a hybrid cloud deployment, a service or application is provided by a combination of a public cloud, and a community cloud and/or a private cloud. This enables running generic services (like email servers) in the public cloud while hosting specialized services (like a business specific application) in the private or community cloud.
Cloud service models
Clouds can be delivered in one of three service models:
- Software-as-a-Service (SaaS) delivers full applications that can be used by business users, and need little or no configuration. Examples are Microsoft Office365, LinkedIn, Facebook, Twitter, and Salesforce.com.
- Platform-as-a-Service (PaaS) delivers a scalable, high available, open programming platform that can be used by developers to build bespoke applications that run on the PaaS platform. Examples are Microsoft Azure Cloud Service and Google App Engine.
- Infrastructure-as-a-Service (IaaS) delivers (virtual) machines, networking, and storage. The user needs to install and maintain the operating systems and the layers above that. Examples are Amazon Elastic Cloud (EC2 and S3) and Microsoft Azure IaaS.
The following figure shows the responsibility of the cloud provider for each service model.
In the context of infrastructure, IaaS is the most relevant service model.
When we combine both deployment and service models, we get the following picture.
The next section describes Infrastructure as s Service in more detail.
Infrastructure as a Service (IaaS)
Infrastructure as a Service provides virtual machines, virtualized storage, virtualized networking and the systems management tools to manage them. IaaS can be configured using a graphical user interface (GUI), a command line interface (CLI), or application programming interfaces (APIs).
IaaS is typically based on cheap commodity white label hardware. The philosophy is to keep the cost down by allowing the hardware to fail every now and then. Failed components are either replaced or simply removed from the pool of available resources.
IaaS provides simple, highly standardized building blocks to applications. It does not provide high availability, guaranteed performance or extensive security controls. Consequently, applications running on IaaS should be robust to allow for failing hardware and should be horizontally scalable to increase performance.
In order to use IaaS, users must create and start a new server, and then install an operating system and their applications. Since the cloud provider only provides basic services, like billing and monitoring, the user is responsible for patching and maintaining the operating systems and application software.
Not all operating systems and applications can be used in an IaaS cloud; some software licenses prohibit the use of a fully scalable, virtual environment like IaaS, where it is impossible to know in advance on which machines software will run.
This entry was posted on Friday 28 February 2025
Dutch
