Distributed computing is an advanced software strategy that is difficult to understand for many. Now you can explain it simply with ducks

A yellow duck.
Photo by S. Tsuchiya on Unsplash

I’ve always been a fan of a good metaphor. It’s one of the best ways you can get people to understand a complex problem. If you can find something your audience can relate to, you have a significantly higher likelihood of them comprehending what you’re saying.

This is especially true when you’re talking about advanced technical mumbo jumbo like distributed computing. If you’re new to the cloud, you or some of your coworkers might have heard the phrase distributed computing but might not know exactly what it means.

Have no fear, today we will learn what distributed computing is with…

Modern software is about being agile. To be agile, you have to iterate. To iterate successfully, you must understand these three things

Cocoons and butterfly
Photo by Suzanne D. Williams on Unsplash.

Iteration is important.

I’ll say it again. Iteration is important.

It’s something I talk about regularly because, well, it’s worth repeating.

Software is never done. Requirements change over time, your understanding of the business problem will change, and your application will be enhanced as you add new features. As you build more, you’ll revisit existing functionality and make it better. You’ll realize this isn’t actually what the customer wants and tailor a better UX.

You’ll get into a new tech stack and want to refactor your solution. …

With such an ominous name, you’d want to avoid a death march at all costs. But they do have some benefits

Person sitting in a cafe
Photo by Hannah Wei on Unsplash

I recently got out of my first death march.

For the uninitiated, a death march is a term used in the software industry to describe a development project that is one of the following:

  • destined for failure as a result of unrealistic scope
  • a prolonged period of overwork to hit a deadline

My death march was the prolonged-period-of-overwork kind. Not fun.

It went on for about a month, then tapered off and things got back to normal.

But as a leader, I reflected back at the past month and tried to get a look at the pros and cons: What…

Being a solutions architect is fun. You get to design systems, talk to a bunch of different people, and offer guidance to other developers

Man typing on laptop
Photo by rupixen.com on Unsplash.

If you’ve recently made the move from developer to solutions architect, congratulations! Welcome to the technical world of system design.

A misconception I see regularly with new SAs is that they think their job is solely to come up with a way to solve a business problem. While that is fundamentally correct, there’s a whole lot more to it than that.

While a race car driver’s job is to drive a car around a track, their objective is to do it faster than everyone else. …

Discover how these principles translate to guidelines for architecting new projects

Two men looking at design
Photo by Science in HD on Unsplash.

If you’ve worked with AWS in any sort of capacity, you’ve probably learned they have a unique way of doing things. They start off meetings reading documents in silence, they begin new projects by working backward, and no matter what they do, they drive their leadership principles… hard.

There’s a reason Amazon basically runs the world. Their way of doing things works.

Among the many artifacts they produce to help companies build best-in-class software are their general design principles. If you’ve ever been through an AWS Well-Architected review, you know all about them in excruciating detail (in a good way).

Did you know you can automatically build infrastructure diagrams in your CI pipeline?

Working on laptop
Image by Olalekan Oladipupo from Pixabay.

Last week, I was giving an introductory class to my company’s technical support team on a new product we’ve been building.

The new product is completely different than anything else we’ve built before. The tech stack, programming languages, methods of deployment, you name it — it’s different.

As I was walking through the structure of our repositories, the support engineers asked me, “Are there any diagrams of what this looks like when it’s deployed?”

I thought about the question for a minute. I have about 30 different diagrams describing the different architectural pieces of the app but not too many…

The flow, service, persona, infrastructure, and developer diagram

Design on paper
Photo by Kelly Sikkema on Unsplash.

Have you ever been in a meeting where someone is trying to explain how a software system works?

I was having a conversation with a relatively new solutions architect who was trying to describe a system they had come up with. It had about eight different components to it and they all interacted with each other in multiple ways.

They were explaining the solution using hand gestures and a lot of “and this piece communicates with this one by…”

I understood the words coming out of their mouth, but they didn’t make sense strung together.

Words get lost when explaining…

When working with software, you often hear “Faster, faster, faster!” But faster tends to lead to poor quality. What can you do?

Two roads. One reads “Quality” and the other “Speed.”
Photo by Justin Luebke on Unsplash (altered by the author).

I was sitting on a call the other day.

We were going through a list of requirements for a project my team has been working on. I had called the meeting to let stakeholders know development was going to slow down.

The senior architect on my team had left in the middle of the project. So I, of course, had to inform the people who care that the date was going to slip.

The answer I received was “That is a hard deadline. We still need all the work by that date.”

So I still had to get the same…

Let’s start by empowering others

Image of male in suit, rolling a suitcase.
Photo by Romain V on Unsplash

I had an interesting dream last night.

I was working remotely in some random house and conducting a sprint review. The primary stakeholder was also in this random house, but working remotely from a different room. The sprint review was carrying along fine, business as usual.

Out of nowhere, a tornado rips through the house, leaving the primary stakeholder and I hurt and freaking out a little bit.

But the sprint review carried on. Somebody else picked up where I left off in the demo and another person picked up raising concerns for the primary stakeholder.

I woke up shortly…

Sending your outbound Lambda traffic through a static IP address might sound difficult, but it’s easier than you think

Blue static electricity
Photo by Amos from Stockphotos.com on Unsplash.

Serverless is great. There, I said it.

At this point, I’m not sure many people would argue with me on that, but to each their own.

Serverless provides us with the luxury of fast compute in the cloud without having to worry about machines or state. Pretty awesome.

But since we don’t have to worry about machines or state, a handful of problems that we didn’t have before have presented themselves. Things like monitoring your app become more difficult. You also have all the difficulties of distributed computing thrown into the mix.

But what about a static IP? There…

Allen Helton

I work in the cloud with a strong focus on serverless and API lifecycle. Pushing the limits on API design, standardization, and automation.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store