Forem: Arjen Schwarz

Cloud Design as a Story

Arjen Schwarz — Tue, 27 May 2025 12:49:55 +0000

For a fresh perspective, it's often helpful to look at a problem or task from a different lens. Sometimes, this will be better; sometimes, it's just a good way to refresh and renew your interest in something you've been doing for a while. In this post, we'll be looking at how similar designing for the cloud is to writing a story. What are the similarities, what are some key differences, and how does that actually help in any way?

The story of a story

A long, long, time ago, in a galaxy far far away, a little hobbit lived in a hole in the ground.

When you read the above sentence, you get an idea in your head about the story that is being told. Depending on the kind of stories you've experienced before, that idea will consist of spaceships and robots, or maybe dwarves, rings, and dragons¹. Either way, that single sentence shows how much humans tend to think in stories. Stories are a powerful vehicle to transmit information, so let's have a look at how we can apply that knowledge.

First, we should define a story. At an almost instinctual level, all of us can recognise a story, but what are the key ingredients? What kind of things can we find in both the latest Marvel blockbuster and an ancient story like The Iliad? In my mind, the main ones are the setting, protagonist, antagonist, any other characters, and challenges.

The setting is where things take place, the protagonist is who we'll be rooting for, the antagonist actually is the baddie of the story, there will be side-characters of various importance, and the challenges are what need to be overcome to come to a happy conclusion. Of course, these are not the only things that can make up a story, and nor does every story contain each of these ingredients. But they are the things that make many stories interesting and ensure that we keep coming back for more.

So, how does that translate to cloud design?

Enter our hero

Let's start with our hero! The main character of any cloud design should, of course, be the application itself. Without an application, what would be the point of anything we design? That said, what is an application? Back in the olden days of web development², an application was a piece of software that you built and then threw over the fence to the ops team to deploy on their precious production server. These days, however, there is a lot more to it, especially if you want to get the most out of running your application in the cloud. Whether that is for cost-efficiency, security, or any of the other reasons that are nicely encapsulated in the Well-Architected Framework.

When it comes to the protagonist in a story, the story's author at least needs to know a lot about them. This includes the superficial things like their looks or the hero's background, but also the more intrinsic elements that fuel their motivations. And the same goes for the story of your cloud design. What language is the application written in? Is it even a single language? What kind of architecture does it have, is it a micro-service or monolith? Will it run serverless, on containers, on VMs, or a combination of it all? Why were these choices made?

Asking these questions is a big part of how you design your architecture, as every answer can lead you to a different path with different trade-offs and follow-up questions. For example, opting for a serverless micro-services architecture where the different parts of the application can be written in different languages will have a very different deployment method from a single monolithic application that needs to run on an x2iedn.32xlarge instance.

And of course, keep asking the questions:

If you opt to run containers, are you thinking of doing so on ECS, EKS, or in a self-managed way?
Are you aiming to have your containers run serverless or on instances?
And are these instances managed for you, or do you have to do maintenance on them?
What OS should the instances run on?
What OS should your containers have?
What dependencies should be installed?
What...

Asking these questions is what you need to flesh out the hero of your story, but of course, there is more to a hero than just their intrinsic items. Where we live has a big impact on ourselves, and the same goes for our hero.

Setting the scene

So, where does our hero live? In a fantasy story this can be an inspiring fantasy world with lush forests and giant mountain peaks surrounded by dragons, but for an application? I hate to break it, but unless you're an amazing artist it probably won't look as nice as that.
At the lowest level this is likely a VPC. While some serverless solutions can live outside of the VPC, in the end a VPC is still the basis that everything else builds on. But what does this look like in practice? VPCs have been around for so long there are plenty of best practices for it, and depending on your organisation you may have limited control over it. Exactly like in the real world.
As an example, let's take a standard 3-tier subnet structure spread out over 3 Availability Zones.

In this environment your application and database live in a private and data or isolated subnet respectively. For your application this VPC is its home, but of course that doesn't give much of a setting. So let's look at the broader landscape. First, there needs to be a way to interact with the world outside of the home. A load balancer can serve as our front door, where we receive visitors, and we can have a NAT Gateway or Transit Gateway to facilitate our hero going out themselves. But this is still limited.

Again, you end up asking a lot of questions to figure out the details:

Where is this home?
What region is it in?
Are there limitations like missing services to this region?
What account?
What else is running in this account that you should be aware of?
Where does this account sit in the Organization structure and what impact does this have?

These questions will help you envision the home of your hero better, and thereby how it fits into it all. Of course, not every design will need to care about all of this, just like not every story involves a trip to the other side of the world to throw a ring in a mountain. But, what is a world without anyone in it? Let's look at what fills this world.

The supporting cast

A solitary journey can be a lonely one, and generally speaking stories and design are about the interactions. Who our hero meets is a major part of the story, and that doesn't change when our hero is an application. There are other applications in your environment that it will interact with, third-party services, and of course those who will be using the application.

So the main question you have to ask here is "Who does our hero interact with?". But in addition to that, you also need to figure out how that interaction will take place. In a story that has a medieval setting, you don't usually have instant communication over long distances³ and similarly you have to take what's available into account. Do they communicate over VPC Peering? A Transit Gateway? Or do you use PrivateLink connections to various internal and external endpoints? What kind of protocols are used, both for interactions with the end-users and other applications/APIs, and what's the impact for that on your security groups and NACLs? Who do you need to send alarms to when something goes wrong?

Speaking of things going wrong...

Trials and tribulations

Many stories have a villain, and the story of cloud design is no stranger to this. Unfortunately, in the case of a villain, cloud design is more likely to fall in the mystery genre as we don't really know who or what our protagonist will have to face. There are a great many cyber security threats out there, all of whom have different motives and strategies. So instead of trying to figure out who we need to protect against, you should instead focus on what you're protecting.

Are you protecting your data? Or is there critical infrastructure that can't go down? There are many different things that can be targeted by an attack, and you need to determine what it is that's most important to protect. And once you know what's most important, you can ensure that your cloud environment prioritises protecting that. Of course, don't ignore everything else, and always keep in mind that a layered defense, or defense in depth, will get the best results. Villains aren't the only challenge you may need to confront however, so let's see what else is out there.

Confronting your dragons

No story would be complete without a challenge to overcome. As it happens, the challenges we need to overcome don't involve throwing an evil ring into a volcano or blowing up a moon-sized space station. Instead when dealing with the cloud we have to face other types of challenges. Which can be challenging themselves⁴!

These challenges can take many forms and can be either internal or external. Internal challenges can include things like having to deal with an old application that doesn't support modern architectures. Or you are faced with a release and approval process that requires many meetings and literal months before a change can be deployed to production. Maybe there are business or security requirements that you need to follow.

And then there are the external challenges. The biggest challenge here is often regulation, especially if you're working in industries that have a lot of oversight, and the only way to face that is by doing the work to comply. Similarly, whether by regulation or otherwise, you may not have a choice which AWS region you can use, and whether that region has that one feature or service you really need.

But if you think of these as part of a story, maybe, just maybe, you will find a way to deal with them all and have your happy ending.

And they lived happily ever after

And then our story is complete! We've released our cloud infrastructure; our hero is happy and talking with all their friends in our beautiful world. The antagonist is kept away, and we've overcome all of our challenges. And so our story ends on a happy note and we can watch the credits roll.

Except... this is the real world and the point where the metaphor breaks down a bit⁵. Because, unlike a story with a defined beginning and end, the world of the cloud is always changing and evolving. Because of that you have to keep up to date to stay relevant; this can include updating your protection against new plots the antagonist may be hatching⁶, but the architecture you use can also become deprecated and replaced by something better.

One other key difference between cloud design and crafting a story is that you're not alone. Where a story is created by a single person, or small group of people, for cloud design you have the whole world as your ally. Obviously this includes the colleagues you work with, but there is your local community⁷ you can discuss things with, there is also a lot of documentation out there, and people who have faced the same questions. And nobody minds if you use the same ideas and solutions for your design.

And with regard to using other people's solutions, there is a quote attributed to William Faulkner that is as true for a story as it is for your cloud design:

In writing, you must kill all your darlings

In practical terms, what this means is that you shouldn't hold too tightly onto anything you've built. Yes, you may have sweat blood, tears, and lots of AI tokens over building a working solution, but if AWS releases a service that does almost exactly what you need, you should take a very good look at it. Maintaining your custom solution is harder than using a service, and will take more of your time - time that can be better utilised elsewhere.

And of course, there is the other thing we've all experienced when it comes to cloud design⁸. Once you're done building something, you get to do it all over again for the next project. But maybe, for your next project consider using a framework like this to envision your design as part of a story. Think of your hero, their place in the world, the friends they make along the way, who might be opposing them, and what other challenges will be faced along the way.

The after credits

I'd love to hear in the comments, or elsewhere, if you have thought of design like this and if this take is useful. Or just fun and you would like me to expand on it. And, if you're interested, I've given a couple of talks about this topic. The first one embedded below was at the Melbourne AWS User Group in March last year⁹, and the second was a shorter version at ADAConf in Melbourne.

Or you could be an overzealous copyright lawyer and start to wonder if there's money to be made here. Spoiler: there isn't. ↩
Let's not go back all the way to when we bought our applications on floppies or CDs in a store. That just makes me feel way too old. ↩
Unless magic is involved. Pro tip: don't rely on magic for your cloud architecture. ↩
Just, you know, without having to risk your life. ↩
Or does it? ↩
Or a new antagonist is introduced. ↩
As a meetup organiser, I can objectively say that they're a great way to learn and meet people. ↩
Especially if you're a consultant like me. ↩
Guess who took forever to write this up? ↩

Party on, dude!

Arjen Schwarz — Fri, 17 Nov 2023 00:06:29 +0000

Earlier this morning, AWS released PartyRock, an Amazon Bedrock Playground. In short, this is a fun little playground that lets you create miniature apps using both text and image generation. Through the Community Builders program, I got access a couple of days ago and have been playing around with it. As a spoiler, it's the most fun I've had playing with AWS tools for a very long time. So, grab your air guitar and have a look at what this most resplendent app actually does.

Building an App

First, let's be very clear here that this is a playground. It's clearly meant to highlight fun things you can do with generative AI, and not necessarily meant to be something you use for what you might call "proper work". However, it is a lot of fun to make these little apps, and you can get stuck on doing your best to improve them very quickly. Or just seeing what it comes up with. That said, I have seen some more practical examples of what it can do including code generation, trip planning, and similar things. Is a PartyRock app the best way to do these things? I don't know and I don't care as I'm sure that the people who built it had fun.

Anyway, to explain how it works, let's go through a quick example. To stay in the theme of PartyRock, we'll want Bill and Ted (from the movie series¹) to explain things to us. Having logged into PartyRock we simply click on the "Generate App" button. This brings up the App Builder, where you can provide a description of your app. Based on that description, PartyRock will then literally generate an app for you.

Generating the app takes about a minute or so and a fun little detail is that the generated app won't be the same every time. If you provide the same prompt multiple times, you will get different apps. And of course, as with all generative AI interactions, slightly changing the wording you use can give a very different result. As an example, for the above prompt of "Explain or describe the concept asked about by the user as a conversation between Bill and Ted from the Bill and Ted movie series", I've received a chat interface, separate output widgets for Bill and Ted, and a single output widget where a conversation takes place. Obviously though, afterwards you can change the generated app however you like. (At least, within the constraints of PartyRock).

I'm not going to take you through the editing UI; it's easy to understand how everything works, and just trying it out for a minute or two will explain it better than I probably can. Also, Jeff Bar literally went through every step in the announcement post. Suffice it to say, I went with the single output widget for the conversation and decided to add an image generation widget that uses the prompt "A portrait of Bill and Ted from the Bill and Ted movies looking confused about @What would you like to know about". The @-sign there refers to that being a field it will get the input from.

As you can see, the image isn't great, but the provided answer is both fun² and informative. And making this only took a couple of minutes (not counting the 30 minutes experimenting with prompts to see what kind of answers came out of it). Yes, you can choose which model is used for the text generation, but other than that you can only change the prompts and the sizing and placement of the widgets.

Which brings us to the most obvious thing about PartyRock: the look and feel. Even if you haven't looked at the announcement post, it should be pretty obvious that this doesn't run in the AWS Console. The look and feel are certainly different from what we're used to with AWS, and may not be to everyone's taste. But then, what is? It does make you feel like you're working in a sandbox environment, and the grid for the widgets works pretty well, so there are no complaints from me about that.

Now, the service isn't perfect obviously. You can get the occasional error, especially with image generation, but there is very active development going on³, and I don't want to dive into the issues I've encountered because they could all be gone already by the time this is posted. Also, let's keep it fun.

Snapshots

So, instead, let me highlight some of the fun things I've built with this by showing examples. Which reminds me, did I mention there is a snapshot feature that generates a URL you can share that contains your inputs and the generated outputs? I really love this feature as it's a great way to show the results you can get.

So, let's have a look:

From my Bill and Ted explainer app, Bill and Ted explaining the heat death of the universe, and then suddenly deciding they should do something about that. I feel like this shows so well how things can take some very interesting twists.

From my Fantastical Services app that generates a fantasy background for AWS Services:

From my Monkey Mayhem Generator, which I created to create short fun stories for my daughter:

A monkey depicted with 5 hands that has an adventure climbing on a bed

And last, but certainly not least, my Meetup Intro generator tells you exactly why you should come to our meetup next week.

So, while I'm sure there are more useful playgrounds out there than mine, I had a lot of fun creating them and highly recommend everyone to do the same. Luckily for all of us, it's a free service right now that doesn't even require an AWS account.

So, give it a shot by building something at PartyRock. And of course, be excellent to each other!

If you haven't watched any of the Bill and Ted movies, feel free to watch them and be fully consumed by the insane idea of a couple of time-travelling, failed musicians whose music will supposedly save the world in the future. ↩
Assuming you think the way the characters talk is fun. ↩
One bug I reported was a misspelled error message, a couple minutes later I got the same error but this time it had both the correct and original misspelled message. After that I only got the fixed message. So, very quick turnaround. ↩

EC2 Instance Naming Explained

Arjen Schwarz — Thu, 01 Jun 2023 23:33:33 +0000

In January last year there was an announcement for the X2iezn instance type going GA. When I saw that, two thoughts went through my head: "How do I pronounce this on a podcast?" and "What does that even mean"?

In this case, the announcement post actually explained what everything meant. Clearly, someone at AWS understood that this block of letters might be a bit confusing. But I figured, let's get this cleared up in the future by doing a bit of research and getting it all in a single place that I can then look up to see what it means in the future. And while I could keep this somewhere only for me¹, it's just as easy to keep it public. Hopefully, this will help some of you as well. I'll try to keep this updated as new types and attributes come in.

I have used two main sources of documentation for this, the "marketing" page about EC2 instance details and the documentation page about the same. These have slightly conflicting data in places, and are clearly not kept in sync, but as the marketing page seems to contain more detailed information about the instances I have used that as the leading source, with the documentation being used to fill in any gaps.

If you're not interested in the whole document, but are looking for something that gives you all the useful information, you can download the below cheatsheet (pdf) I made that explains the various instance families, attributes, and sizes.

Anatomy of an instance type

Let's break down how an instance is put together and then go into the details for each of these sections. I'll use the X2iezn as the source for this explanation.

An instance type consists of four parts:

Instance family (the X)
Generation (the 2)
Attributes (iezn)
Size (the size you want the instance at, e.g. 2xlarge)

Some of these are a lot easier to understand than others, but let's go through them one by one.

Instance family

On the EC2 types website, AWS has grouped these families into 6 groups. To make things easier, I'll use these groups as well even though two of them only contain a single family. Instance families started out being represented by a single letter, which at times became a bit awkward and unwieldy, and lately AWS has started using longer family names.

One note before we look at the families concerning capitalization of the families. AWS is not consistent about this and often shows a family and generation as starting with an uppercase letter (e.g. T3 or Mac1), but will show a specific size using lowercase (e.g. t3.medium or mac1.metal). There are exceptions to this as well, and instead of trying to make sense of it all, I'm following the pattern I name above where I capitalize the families unless it's for a specific size.

General Purpose

These are the usual workhorses and the standard instance types you're most likely to use unless you've done some investigating and work on figuring out what's best for your environment. It consists of the following types:

Family	AWS Description	Additional notes
Mac	Powered by Apple Mac mini computers	The first one on the list, but already doesn't follow the standard pattern of a single letter. Mac instances (in AWS) have only existed since late 2020, and it's unlikely Apple would allow a different name.
T	Burstable general-purpose instance types	Basically the same as `m` instances, but with only a portion of the CPU always usable and the rest through burst credits. Interestingly, in the documentation it is said the T stands for Turbo, but this term isn't used anywhere else
M	General-purpose instance type	The standard general-purpose instance family
A	The first EC2 instances powered by AWS Graviton Processors	Basically Graviton 1, which started as its own family until it was turned into a type detail. Obviously an outdated family

Compute optimized

Compute optimized instances generally have half the memory of an equivalent general purpose instance. Which delivers a cost-saving for applications that don't need as much memory. This

Family	AWS Description	Additional notes
C	An ideal fit for compute-intensive workloads	The standard compute-optimized family

Memory optimized

Memory optimized instances have a multiple amount of the memory of an equivalent general purpose instance. Which makes it a good fit for anything that needs lots of memory, like Java applications.

Family	AWS Description	Additional notes
R	Optimized for memory-intensive applications	The standard memory-optimized instance family
X	Optimized for enterprise-class databases and in-memory applications	Depending on the generation and type details, these have multiple times the memory of the equivalent R instance
U / High Memory	Purpose built to run large in-memory databases	Ridiculous amounts of memory, and the weirdest naming scheme of any instance type
Z	Offers both high compute capacity and a high memory footprint	Basically an R instance, but with a high-frequency processor. If this came out now it probably would be a variant of R instances

As you can see in the table, there are two interesting families here. The Z instances, which as we'll see later is now just a attribute but like the A family got its own type when it came out. It should be fairly clear these are on their way out and will soon enough become a variant of the R6 or R7 generations.

The other weird one is the High Memory instances. These have a different naming scheme, where the name actually shows how much memory they have; u-6tb to u-24tb. These are still part of the family name, but more a sub-family and not quite shown as such as some others we'll be discussing later.

Accelerated Computing

These are instance types optimized for specific use cases, such as machine learning or video transcoding. Each of them is special in its own way, and to really know what suits you best you're better off looking into the details.

Family	AWS Description	Additional notes
P	GPU-based instances	These use a P instead of G because that was already in use
DL	Powered by Gaudi accelerators from Habana Labs	Our first 2 letter instance type, but not a subfamily of the D instances which are specialized in HDD storage
Trn	Powered by AWS Trainium	An instance type for training your ML models, developed by AWS and one of the view that has a name longer than a single letter
Inf	Built from the ground up to support machine learning inference applications	Uses Inferentia chips in addition to the usual Intel ones. Probably the first one to use a longer family name
G	Designed to accelerate graphics-intensive applications and machine learning inference	Has been longer around than the P instances, and stole the G name
F	Customizable hardware acceleration with field programmable gate arrays	FPGAs are cool, and obviously this is a good name
VT	Designed to deliver low cost real-time video transcoding	Another 2 letter name. At least this one makes sense, but why not use V?

While the group as a whole is called accelerated computing, it's clear that most of the instance families are focused on one part of the AI/ML stack or another. With the increasing focus on AI, I expect that these instance types receive a lot of attention and will have new types get introduced soon enough. I also wouldn't be surprised if at that point AWS breaks the AI/ML focused families out into their own category like they did for the HPC ones which originally fell under Compute Optimized.

Storage Optimized

These instance families are all about the local storage. Either NVMe SSDs or classic HDD.

Family	AWS Description	Additional notes
I	Provides Non-Volatile Memory Express (NVMe) SSD-backed instance storage	If you want lots of fast local storage, these are what you need. The I stands for I/O, although they could have chosen S
D	Feature up to 48 TB of HDD-based local storage	If you really need a lot of (slow) local storage. D presumably stands for disk.
H	Feature up to 16 TB of HDD-based local storage, deliver high disk throughput, and a balance of compute and memory	I'm guessing H stands for High throughput, but I suspect this family is on its way out as it hasn't received any updates and the processor it uses is now 7 years old

The I family of instances is currently the only one that has a modifier in front of the generation number, specifically the Im4gn and Is4gen instances. We've seen a couple of instance types with longer names (Mac, Trn), but this is the only case of an actual sub-family defined in this way. I hope this was done on purpose and not that someone forgot how the naming scheme works.

Sub-family	AWS Description
Im	Provide the best price performance for storage-intensive workloads
Is	Offers the lowest cost per TB of SSD storage and the highest density of SSD storage per vCPU

That said, I have no idea what the m and s stand for. It's not medium and small, as the Is instances have more memory than Im. It's a bit of a stretch, but the only thing I can think of is based on the announcement where the use cases are described and the Im4gn is described as being good for databases like MySQL and the Is4gen are good for streaming. Someone, please tell me the actual meaning behind these letters so I can get that thought out of my head.

HPC Optimized

These are instances focused on delivering the best result for High-Performance Compute workloads. Not much else to say, as it's all in the name. Weirdly enough, depending on which part of the official documentation you look at these can be categorised as HPC Optimised or as part of the Compute Optimised section. As stated above, I've chosen to use the more complete appearing marketing page as the main source, which is why they are in this section.

Family	AWS Description	Additional notes
Hpc	Optimized for tightly coupled, compute-intensive, high performance computing workloads	A new instance type from January 2022, that's so powerful it couldn't be reduced to a single letter

Generation

The generation of a family. Higher is newer (M7 is newer than M6), but newer families will obviously have lower generation numbers (e.g. Trn1 is newer than M6), so these generation numbers can't be compared between families. AWS does use this to promote their Graviton processors by always making them part of a new generation of processors. So Graviton2 came out first in the M6g when Intel was still only on M5, and Graviton3 can be found on the M/C/R7g while no equivalent 7th generation Intel or AMD instances exist.

Attributes

Processor type

The processor type letter didn't exist until Graviton2 came out, and it didn't even include options for Intel or AMD until the M6i and M6a respectively became available. Unfortunately, this is also not consistently applied even for new instances except when they run Graviton which always gets a g.

Typically everything without an attribute is Intel, as for a very long time that was the only option available, but that's not always the case. An example of this is the new G5 and G5g families. G5g is clearly Graviton, but unless you are familiar with the G series of instances you might be mistaken in your believe that G5 is an Intel type².

The chosen letters in this case are clear, and already mentioned above but let me repeat them anyway:

i: Intel
a: AMD
g: Graviton

To be clear, this doesn't indicate anything other than the type of chip. So Graviton2 and Graviton3 are both represented by a g, and when in the future i and a have different chipsets they will still keep it to just i and a.

One thing to note here, Mac instances come in both Intel and Apple Silicon (aka ARM) processor types but AWS doesn't make a distinction there. It's simply that the mac1.metal instances use Intel while mac2.metal instances use Apple Silicon. As it's unlikely Apple will ship any more Mac Minis with Intel processors that probably won't be a big concern going forward.

Generic attributes

b: block-storage optimized (increases the EBS bandwidth, but is currently only available in the older R5b instances)
n: network optimized (usually 100Gb networking )
z: high frequency
d: local NVMe storage

Family group specific attributes

There is one attribute that means different things based on the instance family group. This is the attribute e.

e stands for extra³, specifically for memory or storage. The only instance families with this attribute are in the memory optimized and storage optimized groups and they exacerbate the values of the group. So, for memory optimized instances the amount of memory is doubled compared to the same type without an e, and for storage optimized you get more storage (there is no fixed pattern for that one that I could figure out).

Summary table

attribute	meaning
i	This is an Intel instance
a	This is an AMD instance
g	This is a Graviton instance
b	This instance has higher EBS bandwidth
n	This instance has more network bandwidth
t	This instance has a higher CPU clock speed
d	This instance has local NVMe storage
e	This instance has its defining property improved

Sizing

At first glance, sizing is very straightforward. They basically work on the concept of t-shirt sizes⁴ and the size is always based on the number of vCPUs available. Medium size instances have a single vCPU, large has 2 vCPUs, xlarge has 4, and from there you multiply by the number in front of it so 2xlarge has 8, etc. The one exception to this is the T-type instances. These don't go lower than 2 vCPUs even for the nano sizing. However, there the size is mostly based on vCPU credits that determine how long you can use the full capacity of the instance.

An instance family type then usually has a multiplier for the amount of memory; for the M types this is 4, meaning you get 4GiB of memory for each vCPU core, with the C types it is 2, and with R it is 8.

The one complication that comes with sizing is all the special modifiers that can have differences based on the size of the instance. For example, for C6gn, the network optimized part scales up with the instance size. So a c6gn.8xlarge has 50Gbps network bandwidth, but a c6gn.16xlarge has 100Gbps.

And then there is the "metal" size. This isn't really a size as much as a different type of instance as it doesn't offer you a virtualised instance but what AWS terms "bare metal". This means you get access to the full underlying hardware and don't share it with anyone. This also means you don't get a choice about the sizing of a metal instance as it's always the maximum possible size for the instance family. In addition, however, you don't get any overhead caused by virtualisation.

And have, considering I wrote most of this a year ago before I forgot about it... ↩
I hope you realise that means it's AMD seeing there are only 3 types. ↩
Proving that it's not just me who comes up with weird names ↩
Ok, not micro or nano and I admit not seeing many 112xlarge t-shirts either. ↩

Presso-Driven Development

Arjen Schwarz — Tue, 23 May 2023 00:22:19 +0000

Last Thursday I gave a presentation at the Melbourne Golang meetup. In this presentation, I had a slide that contained a warning about "Presso-Driven Development". Presso-Driven Development, or PDD, is a term I use to explain how some of my code comes into being. To make my life easier, and see how it fares in the wider world, I figured it's time to put a proper definition out there.

Disclaimer; this would likely be called Presentation-Driven Development if I lived anywhere other than Australia, which would make it sound incredibly boring.

The definition

A presso¹ represents any form of showing people something you've built. This can be in person or online, live or recorded, formal or casual, interactive or one-directional. There needs to be a time constraint attached to it, however; a set date when you need to deliver this by.

Presso-Driven Development takes place when giving a presso is the driving force behind building a feature. The idea for the feature already exists before you plan to give the presso, but giving the presso depends on the feature being implemented. This feature represents something you want to implement, whether that is a small functionality in an application or a complete application, but it is something that can be used to achieve an actual task and will be functional beyond the presso itself. And of course, once you have completed building what you need for the presso, you don't touch it again until after the presso to prevent bugs².

Not required, but a recommended best-practice for PDD, is to make sure your feature includes at least one visually fun property that doesn't add value other than looking cool.

Main points

You build the feature because you need it for the presso, but you are giving the presso as an excuse to build the feature
You build it as a minimal viable feature
Once it works well enough, you don't touch the feature until after your presso
Include a visually fun, but otherwise useless, property
Documentation, tests, and other good coding practice are completely optional and can wait until after the presso (when you probably don't have time for them anymore)

Some background

Now, you might ask, why would anyone build features after they've decided to give a talk on it? Isn't that a bit backwards?

Yes, yes it is. I understand that a more logical sequence of events is "Think of something cool/useful" -> "Write an implementation of this" -> "Give a talk about it". And that makes perfect sense when you live in an ideal world and have lots of spare time.

In a world filled with other activities³ however, this is more likely to be: "Think of something cool/useful" -> "Don't have time to implement it" -> "See an opportunity to give a talk about that cool thing" -> "Propose that talk" -> "Talk is accepted" -> "Realise you should probably make sure it actually works before the talk" -> "Finally implement it" -> "Give the talk". The timeframe for this can also be very long as sometimes an idea can stay in that second step for months, if not years, and is completely dependent on everything else going on in your life. The below diagram attempts to show the different paths for an ideal world where everyone has all the time, and the one we happen to live in.

In short, presso-driven development means that you can actually implement these features/tools that you want to play around with.

Concerning code quality

Most "Something"-Driven Development methods are focused on getting high-quality code, documentation, tests, etc. That... is not a driving factor for Presso-Driven Development. As should be clear from the above background section, PDD generally happens when you don't have a lot of time to get your desired feature working. In the unlikely event that you're finished building the feature but have spare time before your presso, there is no reason not to add documentation, tests, etc. As long as you don't touch the code itself anymore! After all, to reiterate, once it works, don't touch it until after your presso. Most importantly though, don't forget that you could spend that time working on the cool but useless visual property!

A definition in progress

It is my belief that Presso-Driven Development is a very common development strategy, and I have probably missed some parts of this. I would love to keep this post updated with details on how PDD is used in the world, so if this strikes a chord with you please let me know either here in the comments, on Mastodon as @arjen@ig.nore.me, on LinkedIn, or in person. Similarly, if you think of a way to improve the definition let me know.

Or presentation, if you really must use such a long term. ↩
Unless something changes in the service you're depending on, in which case you also shouldn't forget to add a slide complaining about that. ↩
Whether that is work, social activities, or the never-ending task of being a parent. ↩