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).
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…
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…
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…
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…
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…
The first time somebody asked me that question in a sprint review, I had no idea what to say. I was a junior developer at the time and the question destroyed me.
I stammered. I fidgeted. I looked over to my boss for help. I was truly at a loss for words.
I had just finished demoing my first project from start to finish. I was proud to say that I did this.
But when a stakeholder asked me, “So what?” I didn’t know what to say.
I knew how my project worked. That was it. I didn’t…
This past weekend, I saw a post on Twitter saying if you want to level up your career in tech, you have to improve on your soft skills.
“True,” I thought. But I felt inclined to add to this statement.
I sent a reply back stating “On top of that, if you master the art of the metaphor you will go far.”
Sounds kind of cryptic and vague, but I said it like that intentionally. I wanted people to engage with my statement. I wanted an opportunity to immediately prove my point.
I didn’t have to wait long before somebody…
Everybody has opinions on how AWS accounts should be used.
Some people think you should have a mono-account and store everything in your AWS ecosystem in one place.
Others believe an individual application (composed of multiple microservices) belong in a single AWS account.
And others take it to the extreme and keep a single microservice in an AWS account.
None of these approaches are inadvertently wrong (except you might run into some resource limitations with a mono-account), but they all run into the same problem:
How do you maintain consistent authorization across accounts?
If you use a custom Lambda authorizer…
APIs are digital currency.
Modern software lives and breathes through the use of APIs. It’s how things work today.
Not all APIs are created equal. Simply having an API is not going to bring you happy customers. Having a high-quality, meaningful API is what sets you up for success. But how do you increase the value of your API? What makes an API high-quality?
Honestly, it depends on the lens you’re looking through. Arguably the most important way you can look at your API is through the eyes of the customer.
Whether they are using a UI that sits on…
I work in the cloud with a strong focus on serverless and API lifecycle. Pushing the limits on API design, standardization, and automation.