CloudSkew alternative: the icons are not the hard part

Icon breadth is the headline. AWS, Azure, Google Cloud, Kubernetes, CNCF, Alibaba Cloud, IBM Cloud, and Oracle Cloud are all covered, which is wider than most cloud diagram editors bother with, and it matters when your stack is not the one the tool vendor uses.

The rest is sensible product design: a browser app with nothing to install, an infinite canvas, autosave, a built-in document editor for notes next to the diagram, and templates to start from. The free plan keeps one diagram and one template, which is enough to judge the editor and not enough to document a platform, so the decision arrives early.

It is a drawing tool that knows it is a drawing tool. That focus is why it is pleasant.

The first is the blank canvas. Every box, every arrow, and every alignment decision is manual work, and for a real production topology that is an afternoon, repeated by whoever needs a variant of it. Templates help with the starting shape and not with the specific system you are documenting.

The second is decay, and it is the expensive one. Nothing in a drawing tool reads infrastructure, so accuracy is highest the moment you save and drops from there. Six months later the diagram shows two services that were merged and misses the queue that was added, and the only person who could correct it has moved teams.

Describe it. Datadef generates a diagram from a plain description, then puts it on an editable canvas with zones, labelled edges, and real icons: 438 AWS marks, 624 Azure, 226 Google Cloud, inside a catalog of more than 2000 that also covers Kubernetes and data tooling. Getting to a first draft is a paragraph rather than an afternoon, and the draft is arranged rather than piled in a corner.

Or derive it. Connect a repository on GitHub, GitLab, or Azure DevOps read-only, pick a branch or tag, and the diagram is generated from the files that define the system, then regenerated by a daily sync. That is the version that does not decay, because nobody has to remember to update it. Details on repo to diagram.

Either way the result is editable, exports as PNG or JPEG, and can be embedded as a live image so the copy in your wiki is never a screenshot of an older truth.

The interesting part of skipping the dragging is that the icon, the label, the attributes, and the placement are all decided from the source rather than picked from a palette.

The same pass decides what does not get a box at all. Role assignments, IAM policies, grants, key vault secrets, diagnostic settings, and every resource from the random, null, tls, and time providers are classified as wiring, counted in a note rather than drawn. That note is usually what a reader wanted anyway: 27 wiring resources not worth boxes, 14 role assignments, 8 grants, 5 secrets.

Take one storage account block. Three decisions land below without anyone choosing them: the type maps to a specific Azure mark rather than a generic cylinder, three attributes are lifted onto the node because that type is worth describing by tier, replication, and hierarchical namespace, and resource_group_name is read as containment rather than as a connection, so the account is drawn inside the resource group instead of pointing an arrow at it, which is the most common way a hand-drawn cloud diagram misleads.

# in the repository
resource "azurerm_storage_account" "lake" {
  name                     = "acmelakeprod"
  account_tier             = "Standard"
  account_replication_type = "ZRS"
  is_hns_enabled           = true
  resource_group_name      = azurerm_resource_group.data.name
}

# on the canvas
# id       node-storage-account-lake
# label    lake
# icon     azure-storage-accounts
# detail   Storage account; account_tier Standard,
#          account_replication_type ZRS, is_hns_enabled true
# placing  inside the resource group zone (containment, not an arrow)

For a system that does not exist yet, there is nothing to generate from and direct manipulation is the fastest path. The same is true for a diagram that has to say something the code does not contain, such as a proposed migration or a slide that deliberately simplifies.

The useful question is not drawing versus generation. It is whether the thing you are drawing already exists somewhere machine-readable. When it does, hand placement is unpaid work you will do again next quarter.

• Datadef compared with draw.io
• Datadef compared with Cloudcraft
• The editable canvas
• Hava alternative