The Virtualization Model

One model can be used for virtualization technologies, such as Software Defined Compute (SDC), Software Defined Networking (SDN), and Software Defined Storage (SDS), as shown in the picture below.


The model shows 3 layers: at the bottom, physical devices, then a virtualization layer that creates abstract system resources, and at the top a number of virtual devices that are compiled using the abstract system resources. It is a well-known way of implementing a virtual machine environment, but it also applies to networking and storage.

When the virtualization layer is programmable, using APIs, it can be controlled by (external, third party) software, to support software defined computing, software defined storage, or software defined networking.

The number of physical devices is typically independent of the number of virtual devices. The physical devices can be commodity hardware, or enterprise grade hardware, or a mixture. Because of the virtualization layer the physical hardware can be upgraded, replaced or phased out independent of the operation of the virtual devices.

The virtualization layer provides a resource pool that enables virtual devices to be configured. Ideally, the virtualization layer should decrease the performance, as delivered by the physical devices, by no than 10%.

The virtualization layer can provide advanced features, such as:

  • Storage (SDS): deduplication, RAID, Snapshots;
  • Compute (SDC): Live migration, virus scanning;
  • Networking (SDN): VLANs, filtering, IDS, firewalls, virus scanning;

and provides APIs for scripting (orchestration), as provided by software such as OpenStack.

This entry was posted on Donderdag 23 April 2015

Software Defined Computing (SDC), Networking (SDN) and Storage (SDS)

Software Defined Computing

While virtualization has been around for many decades, it was mainly focused on the virtualization of computing power – the use of multiple virtual machines running on one physical machine. This allowed a better use of the physical computer’s resources, as most of the physical machines ran at a fairly low CPU and memory utilization. A hypervisor is used as a layer between the physical and virtual machines. Apart from providing virtual machines, this hypervisor also allowed for additional functionality, like managing virtual machines from one management console, adding virtual memory of CPU cores to a virtual machine, high availability by restarting failing machines, and dynamically moving running machines between physical machines to allow load balancing and maintenance. This extra functionality (that the virtual machines are not aware of) can be called Software Defined Computing (SDC), as the hypervisor is controlled by software. In addition, SDC provides open APIs to enable third party software to monitor and control the SDC’s hypervisor(s).

Not only compute resources can be virtualized. Lately, virtualization of networking and storage resources is becoming more popular. This allows not so much for a better utilization of the hardware – as this is not necessarily solved by this virtualization, but does allow for software defined storage (SDS) and software defined networking (SDN).

Software Defined Storage

With SDS, the physical storage pool is virtualized into virtual storage pools (LUNs). This is nothing new, this was possible for many years. In addition to this, SDS provides extra functionalities, like the connection of heterogeneous storage devices and using open APIs.

SDS enables to use storage devices from multiple vendors and manage them as one storage pool by using open APIs and by allowing to physically couple physical storage devices together.

Software Defined Networking

With SDN a relatively simple physical network can be used to provide a complex virtual network. Technologies like vLANs have been around for a long time, but they require complex configurations on a number of devices to work properly. SDN provided one point of control to configure the network in a dynamic way.

In a SDN environment, the physical network is typically based on a spine and leaf topology, as shown below.


This topology has a number of benefits:

  • Each server is always exactly four hops away from every other server
  • The topology is simple to scale: just add spine or leaf servers
  • Since there are no interconnects between the spine switches, the design is highly scalable

Because of the relatively flat hierarchy and the fixed number of hops, the topology can easily be virtualized using vLANs. The virtual network can then have an hierarchical, complex and secured virtual structure that can easily be changed without touching the physical switches. The network can be controlled from a single management console and open APIs can be provided to manage the network using third party software.

This entry was posted on Woensdag 15 April 2015

What are concurrent users?

I found that there is no clear definition of the number of concurrent users a system must support.

When a system is used by a large group of users, not all users are active all the time. For instance, if your organization has 10,000 employees, not everyone is in the office working every day. People have holidays, or can be sick. And if they are in the office, they are not behind their desks all the time, as they can be in meetings, standing at the coffee machine, etc. And when they are at their desk, using the system, they are not always active using the system’s back-end systems. For instance, when they are reading an article fetched from the internet, only the fetching of the document puts a load on the system. The time the user is reading the text, does not put a load on the system.

Consider the following example.

Total number of employees 10000
Only 80% is at the office 8000
70% of their time is spent at their desk  5600
At their desk, they use the system 70% of the time  3920
In that time, they only perform actions that put a
load on the infrastructure for 5% of the time

This means that during the day, on average, of all employees, only 196 people are actively using the infrastructure at any given moment.

As an alternative, we can use the ratio between usage of the system and “thinking time”. In our example, the percentage thinking time is 100% - 10000/196 = 98%.

A further breakdown could show how the system is used:

Action Example
Load file  Open file in an office application (like Excel or Word)
Save file Save document from an office application
Browse files Open file explorer
Send HTTP request Push a button in a browser-based application, leading to sending data, or use AJAX calls
Receive HTTP data Receive data from a webserver when using a browser-based application, or use AJAX calls
Send data to the Internet Push a button on an internet page, use AJAX calls or send data using protocols like FTP
Receive data from the Internet Receive a web page from the internet, use AJAX calls or receive data using protocols like FTP
Send email/calendar Send a typed email to the email server, or update calendar items
Receive email/calendar updates Receive new emails from the email server
Send VDI/SBC data In a SBC or VDI environment, send keyboard and mouse input to the server
Receive VDI/SBC data In a SBC or VDI environment, receive screen output from the server
Send and receive data from DNS Use DNS to resolve IP addresses
Send and receive data from AD Use AD to handle login/logout or to check credentials
Other Other uses of the infrastructure

Using such a categorization, the actual load on the infrastructure can be calculated, if we know how the system is setup, how the actions relate to a certain load and what a typical user’s behavior is. Not all users are alike. By observing groups of people, their typical behavior can be mapped to the defined categories over time. For instance, a group called secretaries will typically:

  • Open 25 existing Word documents
  • Save 40 Word documents (including new documents)
  • Send 25 emails
  • Receive 25 emails

Based on these numbers, and with the insight in the setup of the system, the actual load on the various parts of the infrastructure can be calculated. This calculation can then be used to shape performance tests.

This entry was posted on Vrijdag 23 Januari 2015

Performance and availability monitoring in levels

The availability of an IT component can be obtained by measuring (monitoring) the performance of that component. If the performance is below a certain threshold, the IT components is reported unavailable.

Monitoring IT systems can be done using a variety of tools. Vendors like IBM, HP, BMC and others provide tools to:

  • Measure performance
  • Capture logging
  • Generating alarms based on thresholds
  • Report the collected data in dashboards or other overviews

Typically, the number of measuring points in an IT landscape is quite overwhelming. When installed out of the box, monitoring tools will typically detect many issues per second, leading to many false alarms. Therefore, it is essential to tune the monitoring system to only generate useful alarms and to create reports containing useful information for specific stakeholders.

Performance measurement (and as derivate – availability detection) can be done on multiple levels:

  • Business process level
  • Application component level
  • Infrastructure component level

It is important to have separated performance measurements on all three levels and to have processes to solve issues on all individual levels.

For the end user of the system, only the business process level is important – as soon as the performance of this level is too low, the end users will be in trouble. Therefore, the business process level should be measured. Today’s tools are able to measure individual business process steps either by measuring their normal use or by measuring the effect of generated business actions. For instance, it can be measured how long it takes to print an invoice and it can be measured how long a simulated fake order takes to be processed in a certain business step.


If the performance on the business process level is below the set threshold, first the performance of the underlying application component(s) should be verified. Since every layer is responsible for its own performance, it could be that there is a problem in the application component layer causing the performance issue in the business process layer. And the application component layer could have performance issues due to a performance issue in the infrastructure component layer. Therefore it is important to separate these layers and give systems managers specific responsibilities for a certain layer. Between the layers, service level agreements should be agreed (Service Level Agreements – SLAs).

If the performance of the business process level is too low and there is no problem in the underlying application components, the solution to the performance issue must be found in the business process layer itself. If this is not the case, then there is a mismatch between the layers – a certain business process issue is apparently not detected in the lower application service layer.

Of course, this reasoning is also valid for the relation between the application components layer and the infrastructure component layer.

On the application component level, performance can be measured effectively if the application components contains “hooks” that the monitoring tool can use to verify the performance of a software component. Without these hooks, measuring can only be done on a much lower granularity. Especially when bespoke software is developed it is advised to invest in building these hooks in the software as part of the regular development process. Typical measurements are the number of times a (part of an) application component is used and how long it takes to finish a certain task. In software, typically there are some hot spots – parts of the code that are used much more frequently than others. By measuring using hooks in the software, these hot spots can be found, monitored, and optimized for performance.

On the infrastructure component level, the performance of each individual component can be measured. Examples are:

  • CPU load
  • Memory usage
  • Network response time
  • Network load
  • Storage response time
  • Storage load

Based on these measurements, low performance, or even unavailability of a certain component or a set of components can be detected.

Systems managers can react on the detection of low performance by addressing the issue at hand. It is important to acknowledge that early detection and resolving of performance issues is essential to avoid performance problems at the higher layers. Early detection and resolving keeps the systems managers busy, but reduces the risk that end users experience performance issues.

It is like the people who work hard to keep the trains running on time. If they do their work well, no one will notice…

This entry was posted on Vrijdag 09 Januari 2015

Een impressie van het LAC 2014

Op 26 en 27 november werd in Nieuwegein weer het Landelijk Architectuur Congres (LAC) gehouden. Het LAC is hét jaarlijkse evenement voor de IT architect in Nederland. Het was al enkele jaren geleden dan ik er voor het laatst ben geweest – meestal het gevolg van drukke inzet bij de klant. Het was daarom goed om zien wat er sinds de laatste keer dat ik er was is veranderd.

Het eerste wat mij opviel was dat bij de sponsors van het evenement de grote organisaties ontbraken. De huidige sponsoren zijn vooral kleinere architectenbureaus in plaats van de grote system integrators. Verder viel me op dat er relatief veel sessies waren die gingen over communicatie en andere soft skills in plaat van over “harde” techniek.

De eerste dag werd energiek gestart met een keynote presentatie van Rick van de Lans, die inging op de manier waarop we met data (al dan niet big data) omgaan. Hij benadrukte dat veel Business Intelligence en Datawarehouse technieken zich vooral richten op interne data en niet op beschikbare externe data. Ook wordt data nog niet gezien als een primair product maar vooral als een bijproduct van de bestaande processen. Verder gaf hij aan dat we in Europa aan het achterlopen zijn op dit gebied – grote spelers richten zich vooral op Amerika en op Azië, en laten Europa links liggen, vooral omdat de acceptatie van nieuwe technieken er zo langzaam gaat.

De tweede keynote was van Bert Hooyman van Philips. Hij vertelde over een groot transformatieprogramma binnen Philips. Ik moet zeggen dat me weinig is bijgebleven van deze presentatie. Het valt dan ook niet mee om na een “kanon” als Rick van der Lans te moeten presenteren.

Hierna was er keuze uit maar liefst 6 parallelle tracks en een interactieve sessie. Elke track bestond uit 4 presentaties. Ik koos voor de track over de waardebepaling van architectuur. Helaas mis je daardoor natuurlijk een groot aantal – waarschijnlijk ook zeer interessante – presentaties, maar gelukkig zijn deze na afloop van het LAC allemaal op de site van het LAC na te kijken.

De track die ik koos werd deels gepresenteerd door studenten die onderzoeken op het gebied van waardebepaling van architectuur hadden uitgevoerd. Iemand die ik eruit wil lichten is Wendy Günther, die een aansprekende en humorvolle presentatie wist te geven. Heel goed!

In de pauzes tussen de presentaties was er ruim de tijd om bij te praten met vakgenoten en om oude contacten aan te halen. Altijd leuk en leerzaam.

De eerste dag werd afgesloten met een keynote van Lineke Sneller, hoogleraar Toegevoegde Waarde van IT van de Nyenrode universiteit. Zij was ook lid van de klankbordgroep van de commissie Elias, over de problemen bij IT projecten bij de overheid. De presentatie ging vooral over hoe architecten zich beter konden presenteren in de boardroom. De belangrijkste tip was om vooral de architectuurplaten thuis te laten, evenals de technische termen, en je te richten op de taal die in de boardroom wordt gesproken – de taal van de euro’s. Als de architect de essentie van een probleem of een oplossing in euro’s weet te vertalen is de kans veel groter dat hij aansluiting vindt en begrepen wordt.

De tweede dag werd gestart met een keynote van Philippe Kruchten (een van de grondleggers van RUP en de bedenker van het 4+1 architectuurmodel). Hij vertelde – na wat overbodige slides over wat een architect nu precies is en doet (zucht) – vooral over de wet van Conway, die stelt dat de organisatie van een softwareontwikkelafdeling weerspiegeld wordt in de uiteindelijke architectuur van de software die wordt ontwikkeld. En omdat de architectuur vaak onafhankelijk van de ontwikkelaars wordt opgesteld, kan er frictie ontstaan. Een frictie die lijkt op technical debt. Ook ging hij in op de mismatch die vaak ontstaat tussen ontwikkelaars en de beheergroep, of de infrastructuur waarop software moet gaan draaien. Dit is een erkend issue en de oplossing hierbij is DevOps – een werkwijze waar de architecten nog aan moeten wennen. Professor Kuchten stelde dan ook dat je altijd rekening moet houden en afstemming moet zoeken met drie “tures”: Architecture, Organisation Structure en Infrastructure.

Na de keynote werd de traditionele NAF penning en architectuurprijs uitgereikt, waarna er weer tijd was voor parallelle tracks. Ik koos voor de track “Boardroom skills voor architecten” – een track die bijzonder populair bleek. Een presentatie die ik zeker wil vermelden was die van Kees-Jan Koster, die – om aan architecten duidelijk te maken hoe communicatie werkt – de presentatie verduidelijkte met een taal die architecten wel begrijpen: UML diagrammen.

De dag werd afgesloten met een keynote van Stefan Willems van Sandvik uit Zweden, die met een zeer goed verhaal met veel humor liet zien dat het vertellen van een goed verhaal over een toekomstige architectuur veel meer waarde heeft dat welke architectuurplaat dan ook. Ook liet hij zien hoe je met een geanimeerd whiteboard filmpje grote groepen mensen in je organisatie kunt bereiken.

Het was goed om weer eens op het LAC te zijn – wat mij betreft volgend jaar weer.

This entry was posted on Vrijdag 28 November 2014

Earlier articles

The Virtualization Model

Software Defined Computing (SDC), Networking (SDN) and Storage (SDS)

What are concurrent users?

Performance and availability monitoring in levels

Een impressie van het LAC 2014

UX/UI has no business rules

Technical debt: a time related issue

Solution shaping workshops

Architecture life cycle

Project managers and architects

Using ArchiMate for describing infrastructures

Kruchten’s 4+1 views for solution architecture

The SEI stack of solution architecture frameworks

TOGAF and infrastructure architecture

The Zachman framework

An introduction to architecture frameworks

How to handle a Distributed Denial of Service (DDoS) attack

Architecture Principles

Views and viewpoints explained

Stakeholders and their concerns

Skills of a solution architect architect

Solution architects versus enterprise architects

Definition of IT Architecture

My Book

What is Big Data?

How to make your IT "Greener"

What is Cloud computing and IaaS?

Purchasing of IT infrastructure technologies and services

IDS/IPS systems

IP Protocol (IPv4) classes and subnets

Infrastructure Architecture - Course materials

Introduction to Bring Your Own Device (BYOD)

IT Infrastructure Architecture model

Fire prevention in the datacenter

IT Infrastructuurmodel gepubliceerd in XR Magazine

Where to build your datacenter

Availability - Fall-back, hot site, warm site

Reliabilty of infrastructure components

Human factors in availability of systems

Business Continuity Management (BCM) and Disaster Recovery Plan (DRP)

Performance - Design for use

Performance concepts - Load balancing

Performance concepts - Scaling

Performance concept - Caching

Perceived performance

Ethical hacking

Computer crime

Introduction to Cryptography

Introduction to Risk management

The history of UNIX and Linux

The history of Microsoft Windows

Engelse woorden in het Nederlands

The history of Novell NetWare

The history of operating systems - MS-DOS

Infosecurity beurs 2010

Wat is infrastructuur?

The history of Storage

The history of Networking

History of servers

Guru4Pro - Cloud computing

Cloud: waar staat mijn data?

Tips voor het behalen van uw ITAC certificaat

Ervaringen met het bestuderen van TOGAF

De beveiliging van uw data in de cloud

Proof of concept

Een consistente back-up? Nergens voor nodig.

Measuring Enterprise Architecture Maturity

The Long Tail

Master Certified IT Architect

ITAC Certification

Human factors in security

Google outage

SAS 70

De Mythe van de Man-Maand

TOGAF 9 - wat is veranderd?

Landelijk Architectuur Congres LAC 2008

InfoSecurity beurs 2008

Spam is big business

De zeven eigenschappen van effectief leiderschap

Een ontmoeting met John Zachman

Persoonlijk Informatie Eigendom

The Irresistible Forces Meet the Movable Objects

Sjaak Laan

Recommended links

Genootschap voor Informatie Architecten
Ruth Malan
Informatiekundig bekeken
Gaudi site
XR Magazine
Esther Barthel's site on virtualization


XML: RSS Feed 
XML: Atom Feed 


The postings on this site are my opinions and do not necessarily represent CGI’s strategies, views or opinions.


Copyright Sjaak Laan