• Home
  • Testimonials
  • Blog
  • Contact Us

At a Glance of a Key

Crafting Dreams into Ventures, Code into Excellence: Your Journey to Success

  • Home
  • Testimonials
  • Blog
  • Contact Us

Why you shouldn’t trust the documentation ?

2017-06-08 Debugging 1 Comment 2 minute read

Today Microsoft Azure introduced the new F-series VM sizes (you can read about it here) and our software faced a bizarre issue.

When we want to create a new instance in Azure, we have an implementation that chooses VM size based on some criteria. One of the criteria is the number of data disks we need. As you probably know, each VM size comes with a specific amount of CPU cores and RAM memory, and it has limitation on how many data disks can be connected to it.

What the algorithm does is simply get the list of all available VM sizes in a specific region and filter them by our criteria and then choose the cheapest one from the list.

Up until now, when we had 3 data disks the algorithm chose “Standard_A2_v2” VM size which has 2 CPU cores, 4GiB of RAM and supports up to 4 data disks. Today the chosen VM size was “Standard_F1s” which (according to the spec) has 1 CPU cores, 2GiB of RAM and supports up to 2 data disks.

Our software started to fail with multiple “Cannot access memory” errors because our assumption was that the VM has at least 4GiB of RAM (and we are utilizing it pretty well).

The question that we tried to answer is how we chose a VM size that supports up to 2 data disks when the algorithm looked for VM size that supports at least 3 data disks.

Reviewing the code didn’t provide the answer so we went to check the API:

1
2
3
4
5
6
7
PS C:\Users\alexander> Login-AzureRmAccount
PS C:\Users\alexander> Get-AzureRmVmSize -Location "North Europe" | Sort-Object Name | ft Name, NumberOfCores, MemoryInMB, MaxDataDiskCount -AutoSize

Name                   NumberOfCores MemoryInMB MaxDataDiskCount
----                   ------------- ---------- ----------------
Standard_F1s                       1       2048                4
Standard_F2s                       2       4096                8

From the documentation (that can be found here) we see that:

Fs-Series-Azure-Documentation

So looks like someone here is lying 🙂

The real problem that caused our software to fail is a hidden assumption that we made that assumes minimal size of RAM memory (at least 4 GiB) for instances with more than 2 data disks. The solution is simple, add another criteria to the algorithm.

The lesson I learned (and not for the first time) is don’t trust the documentation and don’t do hidden assumptions… They will eventually break and hit you back.

In the same topic, can you guess what is the complexity of std::list size() function in C++ 11 ?

Hint: According to the documentation, it should be O(1).

– Alexander

Oh hi there 👋
It’s nice to meet you.

Sign up to receive a notification when new posts are published!

We don’t spam!

Check your inbox or spam folder to confirm your subscription.

APIAzureDocumentation

Bash Tips & Tricks: Handling failures in pipe

How do I spend less time on compilation

1 thought on “Why you shouldn’t trust the documentation ?”
  1. shani fedida
    2017-06-12 at 11:19 PM

    Assumptions is the mother of all fuckups 😆

    Reply
Leave a Reply Cancel reply

About Me

Principal Software Engineer and an industry leader with startup and FAANG experience. I specialize in distributed systems, storage, data protection services and payment processors.

Beyond technical expertise, I am passionate about supporting fellow engineers in their careers. Through approachable blogs and hands-on guidance, I help navigate the ever-evolving landscape of technology, empowering individuals to thrive in their professional journeys.

Open LinkedIn

Recent Posts

  • Building a Delayed Message System with Redis and FastAPI
  • Go Concurrency, Practical Example
  • Using GORM – Part 3: Models and Idempotency
  • Using GORM – Part 2: Transactions and Save Points
  • Using GORM – Part 1: Introduction

Archives

  • January 2025
  • December 2024
  • March 2023
  • February 2023
  • September 2022
  • July 2022
  • July 2021
  • June 2021
  • February 2021
  • April 2018
  • March 2018
  • January 2018
  • July 2017
  • June 2017
  • May 2017

Categories

  • AWS
  • Career Growth
  • Cyber Security
  • Debugging
  • Development
  • Storage
  • Tips & Tricks

Tags

API AWS Azure Bash Brainfuck C++ Challenge Cloud Cloud Bursting Concurrency Database DevOps Disassembly DLL Documentation DynamoDB Go Golang Guice Java Jenkins Mossad NoSQL OOP Performance Programming Python Redis Security Serverless Singleton Streams Testing Unit Tests WebService

All Rights Reserved 2025 © Sirotin Enterprises Inc.
Proudly powered by WordPress | Theme: Doo by ThemeVS.