CJ Eller

Classical Guitar by Training, Cloud Engineer by Accident

Taking time off of a problem I'm encountering with Github Actions? Easier said than done.

I find my usual troubleshooting method is to continually run my head into the wall until I solve a problem. This leaves me worse for wear — physically, mentally, emotionally.

Perhaps it's better to step back and observe the wall. Find where the cracks are in the first place, then pursue them. That always seems to do the trick. Yet here I go, running at walls anyway. Why is that? Why keep insisting on running into the wall? A sense of personal pride?

This post is a response to a user on the 100 Days of Cloud Discord server asking about details of my journey to where I am now in my career as a cloud engineer. It's a long story but I hope a helpful one.

First off, there's a reason why I have “Classical guitar by training, cloud engineer by accident” as my blog's byline. I got here with a lot of luck.

I've spent 7 years of my life studying to be a music teacher & performer. Being a classical guitarist was my identity for a good part of my adult life. On the cusp of starting a doctoral program, however, something felt off. Music sustained me spiritually, emotionally, and mentally. To make music sustain me financially felt forced. Being an adjunct professor at a college and performing on the side? I couldn't see myself doing that. Why continue? With that I dropped out of the doctoral program, working as a barista all the while.

At this point the accident happened. There was a family friend who needed an extra hand with their IT Consulting business — no experience required. I had been let go at a role I took after the barista gig. No experience? As a music person, that was me in a nutshell. With nothing to lose I decided to jump in.

This was my entry into the world of technology. I learned how to support Windows work stations, printers, servers on prem, Wordpress sites, VoIP phones. The role taught me troubleshooting, of going into a problem with little context and learning enough to solve it. Having the ability to sit with ambiguity long enough to work through a problem? An invaluable skill I carry with me to this day.

Later into my IT role I picked up Python as a programming language to learn on the side. I'm lucky to have had a mentor along the way of learning Python — my friend/landlord who was a backend/operations engineer at the time. He'd sit down with me to go over web frameworks like Django and Flask along with other Pythonic things.

Around the time I got into Python I started using Write.as, my blogging home. One of its many virtues is a clean, straightforward API. This got me thinking — why not create an API client library for Write.as in Python? That's what I did. I shared it to the Write.as forum and tried to be helpful there. The client library allowed me to help some fellow users in different ways — from creating a custom search app to showing a blog's currently used tags. I was able to meet the founder/CEO of Write.as, Matt Baer, a couple times over coffee as well. Soon enough I saw that Write.as was looking for a community manager. I was doing a lot of the things that they needed already and had experience with the product with passion to boot. Why not? I asked Matt about the role. After a couple of conversations I got the job as community manager.

The community manager role involved a lot of advocacy for the product. One part I focused on was getting developers involved in using our API. To do this at scale I created apps using Glitch that took advantage of the API wrapper I made before. We had fun ideas, from turning a Notion page into a blog post to creating a messaging platform that used anonymous Write.as posts as the backend. Glitch eventually reached out to us and we collaborated on a piece for their blog. Using Glitch is a magical experience. I wondered how they could allow people to create web apps so quickly. The answer? AWS. Little did I know this was my first experience with the cloud.

Along with promoting the API we were also trying to find ways for people to install the open-source version of Write.as called WriteFreely. It was here that I explored containerization with Docker along with Infrastructure as Code with Terraform & CloudFormation templates. This got me further into thinking about cloud technologies.

Though all the while I wasn't sure I wanted to transition into cloud. What I wanted to get into was cybersecurity, so I studied up on Linux fundamentals, networking, exploit tooling, and even went as far as getting the Security + certification.

This is when another accident happened. My cybersecurity mentor at the time suggested that I shouldn't focus on getting into cybersecurity through the front door but by finding another way in. Why not through cloud? Be a cloud engineer first and then you can transition into cybersecurity. So I took his advice and focused on a particular cloud, AWS, brushing up on the AWS CLI along with CloudFormation & other fundamentals. I passed the AWS Solutions Architect Associate exam, threw out a lot of applications, and hoped for the best. After many months I got an interview for my current role as an Associate Cloud Operations Engineer.

If you would have told me that I'd be a cloud engineer back when I studied guitar, I'd have thought you bonkers. I took a programming & music elective and hated the course. Why would I do that as a job? But life works out in mysterious ways, in fits & starts, in stumbling along the way. That's why it's hard to give advice. I feel lucky more than anything else. How can I give advice on how to be lucky?

But isn't that every blog post I write? A placeholder for something better in the future?

I've been getting into golf again, though “stumbling” is a more appropriate. Used to play with my dad and friends intermittently. Then intermittent began to mean years instead of months in between sessions. Now my clubs are out of storage and I hope to keep it that way.

The reason I bring this up is because I've discovered this recreational programming practice called Code golf. The Wikipedia definition is as follows:

Code golf is a type of recreational computer programming competition in which participants strive to achieve the shortest possible source code that implements a certain algorithm.

The main site (if that's even true for such a thing as “code golf”) includes numerous challenges with numerous languages and a leaderboard to egg you on. It's not my kind of golf, but I appreciate the spirit of Code golf — driving towards concision.

I had an instance today at work where we were trying to parse data out of an AWS CLI command. This was the initial go around:

aws rds describe-db-dngine-versions --engine postgres --engine-version 9.6.20 | grep -a 500 "ValidationUpgradeTarget" | grep "EngineVersion" | sed -e 's/"//g' | sed -e 's/EngineVersion: /PostgreSQL /g' | sed -e 's/,//g'

Then we played around with using another “club” instead of grep & sed — jq. With jq, the command turned to this:

aws rds describe-db-dngine-versions --engine postgres --engine-version 9.6.20 | jq -r ".DBEngineVersions[].ValidUpgradeTarget[].Description"

Accomplishing the same thing in fewer lines. Though it's more than that. While the second solution with jq is smaller, it's also more readable. You can easily infer the structure of the response.

Code golf judges your code by the number of characters & byte size. The real world judges your code by clarity.

Something I'm trying to get better at is archiving the problems I run into with computers — everything from getting a Docker image to work a certain way to figuring out how to do a particular thing in Python or AWS.

What if I could curate these problems like books in my personal library? Think of it. Every day has the potential to unearth an approach to a problem on my shelf. One day I could read something one day that relates to the Docker image issue I keep having. And yet it can be difficult to even manage one's own issues. What problems could be solved if they were top of mind, not lingering in the back of my subconscious?

How to build that awareness? How to build a problem library?

Claire L. Evans wrote a magical piece called Beyond Smart Rocks that took me by surprise. It digs under the silicon and sand that run modern computers to look for sustainable alternatives. A rich corpus of research into mold and memristors shows a fascinating alternative to the relationship we have with computing today. As Evans muses,

Switching from silicon to slime is a transformative idea. For me, the very question feels radically hopeful: might building computers from slime molds and mushrooms transform computing from a sophisticated solipsism into a far more sophisticated expression of our awe-inspiringly complex, interconnected world? Certainly it would change our whole relational experience of computing. It might also be more sustainable, as biological computer systems would consume far less energy than traditional hardware and, at the end of life, be completely biodegradable. ”We can shut down our PC completely,” [Andrew] Adamatzky explains, “but we will never shut down a living fungi or a slime mould without killing it.” Forget planned obsolescence.

The research that Evans dials in on is about Physarum polycephalum, a type of slime mold that has the propensity for limited learning.

Its sensing, searching protoplasmic tubes can solve mazes, design efficient networks, and easily find the shortest path between points on a map. In a range of experiments, it has modeled the roadways of ancient Rome, traced a perfect copy of Japan’s interconnected rail networks, and smashed the Traveling Salesman Problem, an exponentially complex math problem. It has no central nervous system, but Physarum is capable of limited learning, making it a leading candidate for a new kind of biological computer system — one that isn’t mined, but grown. This proposition has entranced researchers worldwide and attracted investment at the government level. An EU-funded research group, PhyChip, hopes to build a hybrid computer chip from Physarum, by shellacking its protoplasmic tubes in conductive particles. Such a “functional biomorphic computing device” would be sustainable, self-healing and self-correcting. It would also be, by some definition, alive.

“A new kind of biological computer system — one that isn’t mined, but grown.” That hits home for some reason. If alternatives like the PhyChip catch on, server farms could actually become more like farms than data centers, where maintenance relies on horticulture as much as it does on traditional IT skills. Imagine growing your parts for your laptop along with herbs for your dinner.

As Evans notes, such experiments only recapitulate the beautiful interconnectedness of our planet. At most we can produce a poor recapitulation — even as our modern world accelerates forward with “innovation” after “innovation.”

[A]s we dream of embedding artificial intelligence into every material surface of our lives, we are at best poorly emulating processes already at play beneath our feet and in our gardens. We’re making a bad copy of the Earth — and, in mining the Earth to create it, we are destroying the original.

However, there is something about the paradigm shift that this alternative creates that is indeed transformative. To go from “a sophisticated solipsism” towards a “sophisticated expression of our awe-inspiringly complex, interconnected world” is a shift I'd want to be a part of.

Best to keep an eye on this and work on my green (slime) thumb.

There's a great Twitter thread from Tom Critchlow that responds to the narrative of the “status game” being played online. In particular, Tom is responding to the variation on the narrative portrayed in this piece by Ali Montag about how writing online takes becomes this “Inner Ring” a la C.S. Lewis (source).

The thread within Tom's thread I want to pull on is this:

But if all you read and follow are mainstream and “inner circle” folks then you're only going to see the status and celebrity game.

You'll desire audience and reach and think that writing in fast company is success...

When the reality is that you can rewild your attention, and follow blogs and people writing small weird things.

You can find your group, you can forge real connections. And writing, working in public helps! It's a tiny weird signal.

That phrase — rewild your attention — hits home with me. It explains much of the development over the past couple years with my relationship towards blogging. A lot of the readers & writers I've come to know exist within the bandwidth of tiny weird signals, especially within the community surrounding Write.as. There are so many great people I've met in that network who are writing those small weird things Tom mentions — more than I can count. I am grateful that I acknowledged and traveled closer towards this signal when I did. It shaped not only my trajectory as a writer but also within the field of technology I work in today. Now that signal is something I don't think about. It's my day-to-day online existence.

But the signal can fade. Tom's message makes me realize that rewilding attention is an active practice. One must not only pursue those tiny signals but share them as well, whether that means writing about them on your blog or by word of mouth. The only way the tiny signal can keep on resonating throughout the web is if we keep passing it on.

Sometimes all I can muster are a couple sentences for a blog post. At first it bothered me. Why couldn't I write longer entries? Slowing down? Losing inspiration?

Ever since I started posting on an every weekday basis, however, the number of words started to matter less. It became more about what I was reading or thinking or doing in that week. If that can only be expressed in a couple sentences, then that's okay.

A blog should be a place to express yourself. Why limit that expression with artificial limits?

I am in a work from home scenario. This week is the first time that I'm spending time working from a place that isn't home — vacationing on the shores of the Atlantic. I've been acclimated to particular habits while at home. Suddenly I don't have access to those, so adjustment is needed. Different co-working pals, different desk for taking video calls, different working session cadences.

It's been a refreshing reset that shakes the dust off of my normal routine. When I go back home at the end of the week I can return to my home office with a renewed appreciation and perhaps a couple improvements that can be made to make things better.

Makes me wonder why I haven't done something like this sooner — working from not home for a change.

As disorder decreases, the system's structure and organization disappears. Disorder is incompatible with life. For open systems, fortunately, it is not impossible that entropy can decrease; fortunately, it is not impossible that entropy can decrease; that is, order can be increased locally (in the organism) while decreasing within the total system (organism plus environment). This is precisely what is typical of living systems: they have the ability to create order out of chaos simply by being assured access tot a continuous flow of energy through the system (energy with low entropy as input and energy with high entropy — heat, for instance — as output). An amoeba “eats” order — that is, it ingests materials with more order (energetically speaking), which it utilizes to maintain and rebuild its own organization, and it expends heat (spreading disordered energy) to its environment. An entire ecosystem operates on the same principle: the ordered input consists of light from the sun, the disordered output is heat to the environment, ultimately to outer space.

The Garden in the Machine by Claus Emmeche