I only heard of DevOps maybe just over a year ago.

My career has always been about knowing how the whole system hung together as a whole. So I would know a little bit about everything. Hardware, software, networks, operating systems etc.

Getting to know each area was essentially also getting to know the people who operate those areas. You would get to know developers, and how they thought. Some thinking you agreed with. Some you'd already seen in other useless or lazy workers so it's no different for them.

Balance is good. Balance is also a myth.

The Myth​

You need to work.

More than just to pay the bills, you need fulfilling work. There's a healthy amount of blogs out there explaining why the work needs to be fulfilling, but I'd like to just look at work as the thing you do during your day.

Life. That's the thing you do when you're not doing work.

So we're clear. On one side you have work. On the other is "life" (no in speech bubbles so you know I don't mean living and breathing).

Monitoring AWS costs is tricker than you may think. Cloud cost management as a general topic is the bane of a lot of business expenses.

If you look at AWS Pricing page, you're going to have to get your head around a few things.

For example, your storage needs:

cool, sounds pretty straight-foward.

me: "I'll just have 2TB please."

not so fast.

which region do you want to keep your S3 buckets?

me: "oh, um, what's the difference?"

The main thing that comes to mind is 'latency' to where your users are being served. You generally don't want to serve content from the other side of the world. Also different regions can vary in AWS services available for that region if you need to use something specifically. Data sovereignty is also a consideration - are you allowed to store your users data outside your country?

But the main difference this blog post is worried about, is cost.

AWS have this little note on their "Avoiding Unexpected Charges" page that reads...

The part that says ominously "...appropriate steps for every region..." is funny because it sounds like AWS is telling you if you don't know what you're doing, good luck to you.

Now you might be saying "no duh", because you'll see a version of this very notion every which way but loose.

But the idea of getting from A to a B you never think you'll get to, through being patient and sticking at it, is one that resonates very personally for me.

I bought myself an Amazon Echo Dot.

Why? I'm not exactly an Amazon fan-boy (give it time). But I think the last couple of years I've come across the whole concept of 'voice', 'automation' and the convenience of everything.

You work for a company. It's a business. It's trying to make money.

And that's fine.

You are trading your time for money.

That's also fine.

The contract will spell out what the expectations are, the conditions, the rates.

And then you conduct yourself as professionally as humanly possible. Within the parameters you've agreed to...

With all this crazy technology around working as a devops engineer it's easy to get caught up designing and building something really complex that does a lot of stuff.

Sometimes it's the demands of the job that means you created something that did one thing. Added something else to it. And before you knew it, the "thing" has become a complicated behemoth that's now critical to the operation of the company (true story, I've seen "hacks" become 'the infrastructure').

One thing I used to see a lot of when I was a permanent employee, and experience myself, was the pressure to deliver some pretty crazy project requirements in a short amount of time and the stress management that needs to happen alongside it.

By "time", I mean the 40 hours a week you are paid for. This lead to people working some crazy extra (read "free") hours worked to deliver things. I put free in quote marks because while the project and the company might think they got a massive amount of work for half price. But there is always a cost to anything, it's just not always money up front.

"Dumbest" is probably a harsh way of putting it.

But I knew I was the least experienced and had the smaller skill-set in a team of battle hardened and really skilled Engineers.

I.T. attracts some very smart people and I talk about this in my last post. And sure that doesn't always equal good things. But if you have been fortunate, like me, to end up in a team surrounded by knowledgeable and helpful Engineers (notice I didn't say "friendly"), you learn.

A lot.

Here are some of the key things I learned being the dumbest guy on the team.