DEV Community: Richard

What Three Fictional Startups Taught Me About Structured, Semi-Structured, and Unstructured Data on Azure

Richard — Thu, 02 Jul 2026 04:25:25 +0000

I'm currently transitioning into cloud engineering and DevOps, and one thing I've learned quickly is that understanding a concept in theory is very different from being able to reason through it in real-life scenarios — the kind you'd actually get on the job.

I don't have real production systems to practice on yet, so I employed the use of AI to come up with creative briefs for fictional startups that I can listen through and get constructive feedback on right away. Instead of memorizing definitions, I run myself through a case-based exercise: for each fictional company, I have to classify their data into structured, semi-structured, and unstructured, and pick the right Azure service for it.

The Three Data Types

Structured data has a fixed schema — you'll typically have the same fields every time, arranged in rows and columns. For example: customer records with name, age, and account number.

Semi-structured data has some organization, but doesn't necessarily fit into a rigid table. A good example is a JSON object, where fields can vary between records.

Unstructured data has no inherent structure at all — think a photo, a video file, or a PDF.

That part felt easy enough, and I figured I could just walk through some real-life scenarios and apply it cleanly. But I quickly learned that the type of data and the right database for that data are actually two separate decisions — and it wasn't quite as intuitive as I initially thought.

Case One: Telemedicine

The first creative brief was a telemedicine platform storing patient records, consultation videos, symptom photos, doctor's notes, app logs, and insurance PDFs.

Most of it sorted out without much issue. Patient records were easy to classify as structured data — the same fields every time (patient ID, name, age, diagnosis) falling into clean rows and columns. On Azure, that's a job for Azure SQL Database.

Consultation videos, symptom photos, and insurance PDFs are all formats that aren't rigid or structured. I also learned something here: even with a PDF file, Azure can't read through whatever rows and columns might exist inside it. A PDF is more of a flattened file, so it lumps together under the unstructured umbrella and gets handled by Azure Blob Storage.

The one that stretched my thinking was the system logs tracking user logins, errors, and API calls. Initially I felt: okay, there's some pattern here, it's not quite as rigid as a database. That instinct was correct — it was the textbook definition of semi-structured data, best handled by Azure Table Storage or Azure Cosmos DB.

Case Two: Food Delivery

The second brief was a food delivery startup — think of the Glovo or Jumia Food type of app. This is where I hit my first real curveball.

On one end, you have restaurants registered on the platform with structured information — location, offerings, and so on. On the other end, you have customers logging in, placing orders, specifying delivery locations, generating user IDs. Once again, structured data.

But then there was the GPS tracking data for delivery drivers, captured every 30 seconds — latitude, longitude, timestamp, speed, driver ID — used to tell you the driver is five or ten minutes away.

Initially, this seemed structured, because it is — the same five fields every time. But I realized the sheer volume of data generated every 30 seconds would overwhelm any Azure SQL database. So this was a situation where the data shape, which is structured, doesn't necessarily dictate the architecture needed to handle it.

Azure Cosmos DB became the choice — not because the data became less structured, but because Cosmos DB is built for that kind of high-velocity ingestion.

This gave me a new rule: data type is about the shape of the data, but database choice is about shape plus volume, velocity, and query pattern. Structured data doesn't automatically mean "put it in SQL." Sometimes it needs a NoSQL-style engine purely for performance reasons.

Case Three: Digital Banking

The third brief sharpened these lessons further, and it produced a couple of catches I initially missed.

Onboarding data — KYC details, account information, name, and so on — was straightforwardly structured. KYC compliance documents, like uploaded driver's licenses and utility bills, were straightforwardly unstructured, headed for Blob Storage.

Transactions and fraud detection logs followed the same pattern as the GPS data: structured, but at a volume best suited for Azure Cosmos DB rather than traditional SQL.

The real twist came with the monthly account statements. Because I could picture my own bank statements — everything arranged in neat rows and columns — I figured this was structured data, destined for Azure SQL. That was wrong, or at least only half right. The underlying data is indeed structured. But once it's rendered into a PDF, it becomes a flattened file. Azure doesn't see rows and columns anymore — it just sees a file. That belongs in Azure Blob Storage.

There was one more lesson from this case that's worth going back for: customer support chat transcripts. When a customer reaches out to support, they type free text and can attach screenshots. My first thought was: free text and screenshots, unstructured, Blob Storage. But I soon realized every message also carries metadata — a timestamp, a sender ID, an agent ID — which is structured, and lets you reference a specific query later by its unique identifier.

So even though it initially looks like unstructured data, the fact that it carries structured metadata makes it more accurately semi-structured, best handled with Cosmos DB. And in real systems, it's quite possible that the metadata alone lives in Cosmos DB or Table Storage, while the raw content — the free text and screenshots — lives separately in Blob Storage.

Three Takeaways

Ask whether you're looking at a raw input or a rendered output. A rendered output, like a PDF, can carry fully structured data underneath but still count as a flattened, unstructured file once it's generated.
High volume and velocity can push structured data into NoSQL territory — not because the data changes shape, but because the architecture needs to handle the load differently.
Real-world data can be layered. As with the support chat example, structured metadata and unstructured content can — and often should — live across multiple Azure services rather than being forced into one.

For one who has done cloud engineering for many years, this might not seem like such a big deal. But for somebody a few months into a full career transition, working through real-life scenarios and real-life decisions in a low-stakes, case-based way is actually something I'm starting to enjoy. It's helping me build capacity, confidence, and systems-level thinking.

So more case studies to follow, hopefully more mistakes along the way as well, as I keep building toward being an effective cloud engineer.

A Lesson in Role Based Access Control (RBAC)

Richard — Thu, 28 May 2026 14:14:15 +0000

From my previous post on Azure Architecture and Identity Access Management, you would recall the intern who accidentally deleted the entire production database just before the weekend rush. Well, meet John Brown.
A few weeks after accidentally deleting production resources, intern John Brown found himself back in the office conference room — this time, not for disciplinary action, but for remediation.

The plan was simple,
Give John Brown his own user account as a new intake employee following "the incident "

How was this done?

TASK 1: CREATING A NEW USER
Type "Microsoft Entra ID" in the searchbox
Click on "Microsoft Entra ID"

In the Default Directory | Overview window, Click on "Add" then "User" then "Create New User"

Next, we fill out John's details as follows:
User Principal name: John
Display name: John Brown
Password: JBrown26 (or can autogenerate)

Click on "Review+Create"

Click on "Create"

A prompt will appear that reads "Successfully created User, John Brown"

John Brown is now a recognized User with a unique Azure identity.

TASK 2: SIGNING INTO THE NEWLY CREATED USER ACCOUNT
As before, type "Microsoft Entra ID" in the search box to open the "Default Directory | Overview" window
Click on "Users" then "All Users"

The arrow shows John Brown as a new profile

Excited, John Brown attempts to log into his account

Username: John@richardochuksgmail.onmicrosoft.com
Current Password: JBrown26

Next, follow the prompts

Now, our intern John Brown is logged into his Microsoft Azure account
He immediately attempts to fiddle with the new platform by creating a Resource group

Oops! Error message

At this point, John existed in the organization’s identity directory, but had no administrative authority yet. This demonstrated an important distinction: Authentication isn't Authorization.

Feeling a little redundant, John approached Richard, the company's Cloud Engineer with his concerns. "Don't worry", Richard said, as he proceeded to grant John administrative access. "Such a well mannered guy, he thought...perhaps a Global Administrator role?....that'll make him the envy of his friends"

PS: From a security perspective, this is one of the most privileged roles available in Microsoft Entra ID.

How was it done?

TASK 3: GRANTING THE NEW USER GLOBAL ADMINISTRATOR ACCESS

Richard with Username : richardochuksgmail.onmicrosoft.com logs back into Microsoft Azure
He types "Microsoft Entra ID" in the search box on Azure, clicks on "All Users", selects "John Brown" and clicks on "Assigned roles"

Next, "Add Assignments" then selects "Global Administrator"

And voila! John Brown is now courtesy of Richard, a Global Administrator.

He informs John, who then attempts to test his newly assigned role.

Unfortunately, that’s where things started going wrong.

TASK 4: THE NEW USER (JOHN BROWN) CREATES ANOTHER USER

Rather than directing new employee Peter Parker to the cloud engineering team, John decided to “save everyone time.” Using his elevated privileges, he created another user account for his friend directly inside Entra ID.

At first glance, it looked harmless but the cloud engineer immediately recognized the risk: if one intern could create identities freely, nothing stopped him from onboarding every colleague, assigning unauthorized permissions, or accidentally exposing company resources again. The issue was no longer identity creation. It was authorization control.

TASK 5: REVOKING THE GLOBAL ADMINISTRATOR ACCESS FROM THE FIRST USER'S ACCOUNT (John Brown)

Richard logs into his Account again, clicks on "Users" then "All Users"

Selects John Brown's profile then "Assigned roles"

Checks the "Global Administrator" option then clicks "Remove assignments"

Using RBAC Principles, the cloud engineer removed John’s privileged role assignment and replaced it with a lower-privileged role aligned with his actual responsibilities. This followed the Principle of Least Privilege where users only receive the minimum access required to perform their tasks. Instead of permanent administrative access, onboarding responsibilities were returned to authorized IT personnel. In summary, balance was once again restored in the land of Richard Inc.

Let's talk a bit about Azure Architecture and Identity Access Management

Richard — Sun, 24 May 2026 12:32:32 +0000

If you read my previous post, you might remember Richard Inc., our beloved (though make-believe) Nigerian food delivery startup that recently made it to the cloud. Well, status update: business is booming! Orders are now coming in from all over the country, the app is running smoothly, customers are happy, and Richard (the founder in this story) has hired 200 staff. This includes a few developers writing code, a few managers approving budgets, interns doing God-knows-what, and maybe automated robots handling food deliveries outside daylight hours. Now every single one of these people (except maybe the robots) need access to the company's cloud resources on Azure.

To provide access as quickly as possible, he provided a master login — one username, one password. Once logged in, he figured all members could then navigate the platform. Big mistake! Just 3 days after this, an overexcited intern, thinking he was in the test environment, accidentally deletes the entire production database on a Friday at 4:55 p.m., just before the weekend rush! Richard nearly had a stroke! It is to prevent strokes for founders like Richard that Azure has an entire system built around who you are, what you are allowed to touch, and how far that permission reaches — kind of like a well-run company organizational chart.

At the top are Management Groups, kinda like Richard Inc.'s business divisions — one division handling deliveries, another for acquiring groceries, another perhaps handling the logistics of expansion. Policies and permissions set at this level can be inherited by everything underneath.

Below Management Groups are Subscriptions, almost like departments within the business divisions. Subscriptions in Microsoft Azure are essentially containers within which most cloud resources are created and managed. Also, because they tie resource usage to a billing account, when assigned to departments within the divisions of Richard Inc., each department gets its own invoice, providing cost visibility (a neat business trick very useful in planning).

Next are Resource Groups, kinda like project folders within which the actual cloud tools live: logical containers that organize related cloud resources together — Virtual Machines (cloud computers running Richard Inc.'s software), Databases (storing every order, every customer, every delivery record), Storage Accounts (holding receipts, images, invoices), and Load Balancers (which distribute incoming traffic across multiple backend servers or computing resources so that no single server bears a disproportionate share of the workload — like traffic wardens making sure that when ten thousand people order "jollof rice" at the same time, no single server has a breakdown).

Now, how do we solve the intern problem? Simple! Microsoft Entra ID (formerly called Azure Active Directory/Azure AD). Microsoft Entra ID is essentially like a smart staff register and assigns identities in four ways — User Identities, Groups, Service Principals, and Managed Identities. Identities assigned to real people such as Richard the founder, his developers, managers, and yes, the intern, are User Identities. If there are maybe 50 developers requiring permission, creating individual user identities can be exhausting. One way around this is putting everyone involved in a Group and assigning permissions to the group that every identity within the group instantly inherits. Once permissions are assigned to the group, every member of that group inherits those permissions automatically. Service Principals and Managed Identities are slightly more technical (we'll talk about these another time).

All identities and access rules for Richard Inc exist inside a dedicated private identity space in Microsoft cloud called Azure Entra Tenant associated with one or more unique addresses/domains

Now, what happens when a User attempts to log in? First, Authentication — basically the bouncer at the door who checks if you are actually who you say you are. To prove your identity, you provide a username, password, and even multi-factor authentication (where you also have to confirm via your phone or a secondary device).

Next is Authorisation, where Azure decides, "Okay, we know it's you — but what rooms are you allowed to enter?" The single most important safeguard that would have prevented the intern from deleting production files.

Still, this is a lot! How does Azure handle authorizations for, say, 10,000 employees? Yikes! The poor Cloud Engineer, huh? Lol, not quite.

Using something called Role-Based Access Control, or RBAC, authorizations can be done at scale — not by writing a custom set of rules per individual, but by assigning roles to individuals, each role coming with a predefined set of powers.

For this Role-Based Access Control model, there are four roles worth knowing: Owner, Contributor, Reader, and User Access Administrator. The Owner can do everything — create, delete, modify, and hand out permissions to others. This is Richard himself (the founder), or maybe his Chief Technology Officer. Contributors can build and manage resources but cannot grant permissions to anyone else, e.g., senior developers. The Reader can see everything and touch absolutely nothing. Perfect for an investor who wants visibility or a compliance auditor reviewing the system. And then there's the User Access Administrator, who can only manage permissions — can't create a single resource, just handles who has access to what. Great for an operations manager who onboards and offboards staff regularly.

In all of these roles, however, one golden rule applies — Least Privilege, which essentially means: "Give every person and every system the minimum access needed to do the specific job, nothing more."

Another important idea in Azure RBAC is Scope. Beyond the assigned Role, how widely does it apply? The wider the scope, the more powerful the role. A Contributor at Management Group level can touch everything in every department. A Contributor at Resource Group level can only touch one project folder. Same role, very different levels of power.

Oh, by the way, the intern was reassigned to Reader access only. He's doing great!

Today I finally understood what cloud computing actually means

Richard — Mon, 18 May 2026 15:27:54 +0000

The "Swapped" animated movie was such an interesting watch on Netflix. Lovely graphics, great humor, with a reminder of the powerful bonds of friendship and family. It had it all! All this was thanks to a series of powerful computers housed in data centers delivering computing services over thousands of miles. The power of the cloud moved Netflix from a DVD rental service by mail to a leading global platform offering a vast selection of movies, TV shows, documentaries, and even games through its streaming service.

As far back as 2005, a Nigerian company trying to launch a website would spend millions buying expensive servers, renting server rooms, providing constant power, installing cooling systems, hiring a full IT team to babysit processes 24/7, and paying for security — all before writing a single line of code. Now, the same company can rent all these resources over the internet through a subscription, without the burden of infrastructure, space, or personnel, and have full freedom to specify computing needs (service models) and who has access to these platforms (deployment models)!

Imagine the same Nigerian company — say Richard Inc. (lol) — against all odds, gets running and does very well in the market, providing, say, food delivery services online. A good business day also brings with it huge strains on limited internal servers and suddenly, crash! The server goes dark. For a new business, this could be catastrophic, and new customers, after just a few minutes of service timeout, may swivel into the waiting arms of the competition. With cloud computing, a good business day can stay a blessing, with servers scaled up to match rising demand and customers none the wiser.

What if something happens to these computers? We know systems fail and natural disasters happen. Is Richard Inc. or Netflix just one catastrophe (flood, fire outbreak, etc.) away from going dark? While for traditional data centers this might be the end of operations, cloud services transcend these hurdles with the principle of redundancy. Data redundancy means copies of essential company data can be stored in multiple places locally within a data center, in multiple sites in a region called availability zones, and even across regions in different geographical locations! This redundancy also cuts across power supply grids, with primary grid power giving way to instant battery backup, generator power, multiple grid connections, and even renewable energy backups in sequence to ensure no power outage — not even for a millisecond.

The powerful system of the cloud suddenly opens up doors for small businesses to competitively thrive globally where this would otherwise not be possible. To soar in the global space, one must reach for the cloud! (Haha, see what I did there?)