At this point I’ve been working with AWS technology almost exclusively for nine years. So that makes me a bit of an expert at it. Yet I’m still amazed at how fundamental principles surface themselves within this “newfangled” technology.

Let’s discuss.

I am re-reading an old favorite of mine, The Mythical Man-Month, by Fred Brooks. In an early part of this book, he discusses what he calls idiomatic complexity, namely, that you have a tradeoff between simplicity and functionality. Here’s an example; variables and types. In the C programming language primitives are all basically integers (not really, but that will serve for the purposes of this blog post). Integers are dead simple to understand, it’s just a number. But in order to do useful things you have to have some idiomatic understanding of what to do with those numbers. A string, for example, is a series of those numbers (an array), where each number represents a character on the ASCII (or UTF) table. Now, contrast this with a more modern programming language construct, something like the Python Requests library. This does something really complex for you, such as POSTing data to an https server and parsing out the response for you. And it wraps up all the complexity of managing all the different strings for you; Request and Response objects have all sorts of strings for the URL, the POST data, the response code, the body, etc.

So in the case of Brooks’s idiomatic complexity, you have traded off the simplicity of understanding all the details of the Request and Response objects for the functionality of being able to do something complex much more quickly.

But this can come at another cost. Now we introduce the Law of Leaky Abstractions, which as far as I know was coined by Joel Spolsky. Let’s say that the response body in the object uses some UTF code that you are not prepared for. The result of this is your body may be unintelligible or unprintable. But unless you have knowledge of how those underlying primitives and strings work, this entire situation might be a complete mystery to you.

How does this relate to AWS? A lot, actually. Let’s talk about Infrastructure as Code (IaC), specifically, CloudFormation versus CDK. With CloudFormation you have the same concept of primitives, namely, straightforward ways to create AWS resources. But let’s say you want to do something complex, such as creating an S3 bucket with KMS-based encryption. You have to have the idiomatic knowledge of creating the S3 bucket primitive, the CMK primitive, and then associating them together along with all the relevant IAM constructs. Conversely, with CDK you can do things such as create L2 constructs, such as a hypothetical “SecureS3Bucket”, which wraps up the creation of these primitives for you into a single object. But guess what? The Law of Leaky Abstractions still applies! Let’s say your IAM rights only allow you to create S3 objects, but not KMS objects. Synthing and deploying this CDK L2 construct will fail, and unless you understand what is happening under the hood in the CDK object, the failure cause will be a mystery to you.

In fact, with AWS and IaC the Law of Leaky Abstractions is even more prevalent, because even those primitives have their own Leaky Abstractions, since many of the resource types are they themselves super complex, such as an entire operating system or database.

My point is, even working with a cutting-edge modern technology such as AWS and IaC, foundational engineering principles from decades ago can still apply, and you can up your game by studying and learning these principles. Don’t ever think that just because a book was written in the last century that the knowledge cannot be used for your to improve your technical skills.