Tag Archives: infrastructure

What’s cool? The interactive Open Infrastructure Map is cool

I can write what the Open Infrastructure Map is by using the words of its creator:

Open Infrastructure Map is a view of the world’s infrastructure mapped in the OpenStreetMap database. This data isn’t exposed on the default OSM map, so I built Open Infrastructure Map to visualise it.

But the best thing to do is tell you to head over to it and zoom in on areas you know. Being from Cape Breton, I did just that, and I was wonderfully surprised by how much detail was there. I think you will feel the same.

Highly recommended.


I asked ChatGPT to do my job and write some code to built out some cloud infrastructure. How did it go?

For fun I decide to see if I am ready to be replaced with AI via ChatGPT. Part of my work is building cloud based infrastructure using a language called HCL from Hashicorp using a tool called Terraform. You write one or more program files using HCL, run it through Terraform, and voila, you have the infrastructure you need.

For this exercise I entered the following prompt:

Create a terraform file for IBM cloud that will provision a VPC, set up networking for the VPC, and provision a virtual server for VPC. It will have 1 security group and a rule for this security group to allow SSH connection to your virtual server instance, 1 subnet to enable networking in your VPC, 1 VPC virtual server instance and 1 floating IP address that you use to access your VPC virtual server instance over the public network.

A good prompt, I thought. Nothing vague or conflicting. Practically a form of code itself.

I was shocked when in a few seconds I got this response:

To provision a VPC, networking, and a virtual server with a security group and a floating IP address on IBM Cloud, you can use the following Terraform configuration file:

# Configure the IBM provider
provider “ibm” {
generation = 2
region = “us-south”
}# Create a VPC
resource “ibm_is_vpc” “vpc” {
name = “my-vpc”
address_prefix_management = “auto”
# Create a subnet in the VPC
resource “ibm_is_subnet” “subnet” {
name = “my-subnet”
vpc = ibm_is_vpc.vpc.id
ipv4_cidr_block = “”
# Create a security group
resource “ibm_is_security_group” “security_group” {
name = “my-security-group”
vpc = ibm_is_vpc.vpc.id
description = “Allow SSH inbound traffic”
# Add an SSH rule to the security group
resource “ibm_is_security_group_rule” “ssh_rule” {
security_group = ibm_is_security_group.security_group.id
direction = “inbound”
protocol = “tcp”
port_min = 22
port_max = 22
remote = “”
# Create a virtual server instance in the subnet
resource “ibm_is_instance” “instance” {
name = “my-instance”
image = “ibm-centos-7-10-minimal-amd64-2”
profile = “bx2-2×8”
primary_network_interface {
subnet = ibm_is_subnet.subnet.id
vpc = ibm_is_vpc.vpc.id
security_groups = [ibm_is_security_group.security_group.id]
# Create a floating IP address
resource “ibm_is_floating_ip” “floating_ip” {
name = “my-floating-ip”
# Associate the floating IP address with the virtual server instance
resource “ibm_is_floating_ip_attachment” “attachment” {
floating_ip = ibm_is_floating_ip.floating_ip.address
instance = ibm_is_instance.instance.id

Before running the above code, replace with your IBM Cloud API key and and with the appropriate values for your IBM Cloud region and availability zone.
Once you have saved this configuration file, you can initialize Terraform by running terraform init, and then create the resources by running terraform apply. After a few minutes, Terraform will create the VPC, subnet, security group, virtual server, and floating IP address. You can then use the floating IP address to SSH into your virtual server instance over the public network.

Wow! What an amazing response, I thought!  It was quick, detailed, seemingly knowledgeable. Also…wrong.

There was so much fundamentally wrong with the code that the only way to get it to work was to rewrite much of it and also add a bunch of new code to make it work. I can’t even tell you how it came up with some of the statements: they are not defined that way for Terraform specs for IBM Cloud.

I even had the AI regenerate the code to see if it could get it right the second time. Instead the new code had 9 errors in it.

Fine. My manager provided me with a prompt of his own: see if it will work on AWS. (Good prompt, Ted!)

I did try it on AWS and Azure. With Azure the response was an incomplete script. (At least the IBM script was complete, though wrong.) With AWS the script was better. I could enter terraform plan and terraform thought it looked good. But once I entered terraform apply to build the resources, it failed.

I suspect the larger problem is lack of sufficient overlapping data for the AI tools to train on. So it sort of gets the code right, but sort of isn’t really good enough.

I see people on the Internet raving about how well AI is doing writing code. Some of the examples are interesting, but I think it has a way to go. I’ll stick to doing my day job. Without AI to help. 🙂


What are NFRs (non-functional requirements) and why should you care?

If you have any role in the design of an IT system, you should care about NFRs.  As this piece (Nonfunctional requirements: A checklist – IBM Cloud Architecture Center), states:

Defining and addressing the nonfunctional requirements (NFRs) for a system are among the most important of a software architect’s responsibilities. NFRs are the system quality attributes for a system, as distinct from the functional requirements, which detail a system’s business features and capabilities.

Examples of NFRs include key concepts such as reliability, performance, scalability, and security. NFRs are cross-cutting in nature and affect multiple aspects of a system’s architecture. It’s important to articulate and address the NFRs early in the project lifecycle and to keep them under review as the system is produced. To help with that task, you can use the following checklist of key NFRs. The checklist designed to be consulted when you define and evolve a system’s architecture.

The bold text is key. NFRs describe the qualities your system should have. You have functional requirements and you have quality requirements (i.e. , NFRs). Any system design needs to address both.

The number of specified NFRs your system can have are endless. Three of the key ones found at the top of that list are:

Those three are typically covered in any system design I work on. The piece goes on with a great rundown on the various NFRs you’d expect to address in most system architectures.

Three NFRs missing from that list that I think are important and that I would ask you to consider are:

  • Accuracy
  • Maintainability (related to complexity)
  • Cost

There is often a tradeoff with accuracy and other NFRs, such as performance. To gain better performance, data will often be cached and served up even when it is out of date (i.e., inaccurate). That may be fine. But accuracy should always be taken into account and not just assumed.

Maintainability is often ignored, but it is key for the long term success of a system. Two examples of this. One, developers will sometimes not externalize values in their code; changes to the code require a fix and an outage. That is less maintainable than code with external values in a simple text file that can be changed on the fly. Two, code that is not well documented and not peer reviewed will be harder to maintain. Externalization, code reviews and documentation are examples of maintainability requirements you may have and should have for your IT system.

Cost is an important NFR because it causes tradeoffs with most other NFRs. For example, without cost considerations, stakeholders might have availability requirements that are for 99.99999….. It’s only when cost (and complexity and maintainability) become factors do we see often see availability (and other NFRs) scale back.

Finally, NFRs are not just for software architects: they are for everyone. In fact, I wish the term “non-functional requirement” was replaced with “quality requirement”. However I suspect software architects — for whom functional requirements are key — came up with that term, so we all have to live with it. When you think of NFRs, think Quality Requirements. Everyone involved in the design of an IT system wants it to have good quality. Understanding the NFRs/QRs are key to this.


Weird parts of Toronto: transformer houses

No, they do not transform into robots. Instead:

These are Toronto’s residential substations, fake houses built by Toronto Hydro to conceal what’s inside: a transformer that converts raw, high voltage electricity to a voltage low enough to distribute throughout the city.

I have seen a number of them over the years, including this one, which is not far from me: Fake Toronto castle hides electrifying secret in plain sight

They are rather cool, I think. And the fact they blend into the neighborhoods is a huge plus.

For more on them, including the one shown above, see this: Toronto Hydro’s not-so-hidden residential substations.