Practical and Professional Devops with AWS and Docker

Getting into Devops, let alone creating an entire infrastructure and development pipeline... is painful.

There's many reasons for this:

a) The feedback loop is insanely long.

If you want to make a change or conduct an experiment, there is no localhost. You have to do it on whichever cloud provider you're using. Testing a configuration or deploy would require setting up some makeshift infrastructure (or even worse, using an existing one) and then launching the changes. This can take minutes to hours to see if your changes are valid and working.

Now "minutes to hours" may not sound like a lot. But once you've done 50 to 100 experiments with this type of feedback time... Those experiments can stack up to days, weeks, or months.

b) Learning costs are high.

In order to really get an understanding of an entire infrastructure, you need to ... build it. For Cloud infrastructure that means doing so with whatever cloud provider you plan on using. And this can cost money.

So in addition to paying for learning materials and paying with your time, you also pay just to host/compute what you're attempting to learn.

c) Learning materials are in silos, out-dated, or teach the wrong thing.

Because there's SO much to a full development pipeline and infrastructure, it's far easier for content providers to just write about one piece of it... and pretend like the rest of it doesn't exist. This has it's place in allowing for focus on just one area of knowledge, but it's not very helpful when you actually need to build something.

Let's not forget about how fast tech changes. Cloud, Devops and the like are no exception to the changing times. This causes existing information to depreciate in usefulness and accuracy very quickly - unless it's actively maintained.

Finally, there's also a ton of WRONG information out there. Because these topics are so complex, a lot of "Hey, this worked for me!" articles, forum posts, and tutorials pop up. And it amazes me how often these are just the result of the writer being so ecstatic that it's finally working that they don't care HOW or WHY it works. This leads to information that only works for their given situation or worse - insecure, unreliable configurations.

d) Certifications help get interviews, but teach little about day-to-day, real-world work.

Therefore educational materials related to acquiring certifications only loosely help with understanding real-world work. Instead they primarily focus on... passing tests. Tests filled with edge-cases, uncommon scenarios, and trick questions. Tests that care little about implementation.

These types of materials will leave you feeling like you know a lot - but I doubt your goal is to become the AWS Trivial Pursuit champion. It's likely to build a production grade infrastructure.

And in fact, employers, co-workers, etc are going to be far more impressed by you creating a production grade, secure infrastructure vs. a poorly designed PDF with your name stamped on it.

I'm bringing up these barriers because I went through ALL of them

When I went to build my first production infrastructure...

• I was AWS certified
• I'd gone through over 10+ full video courses (ugh)
• I'd been reading AWS Docs 1 hour a day for months (to the point where it was part of my daily routine)

AND!

I was paranoid and still had no clue where to start.

I was really great at AWS Trivial Pursuit. I could (and still can) answer tons of questions about the most obscure topics in AWS and Docker.

But put together a production grade stack. Ha.

So I set out on a long journey of building and experimenting. For professional reasons. For science! For my own pride (after all I had 100s of hours poured into this)!

My goal was something that would last. Something that would scale. And something that I could confidently and proudly use on any project or product.

"Darkness took me, and I strayed out of thought and time, and I wandered far on roads that I will not tell..."

...mainly AWS docs and experiments that took hours per iteration.

And out of this long adventure I crafted this blueprint.

It's something I use on all of my professional projects. Something that I will continue to use. Something that's general enough to fit any application.

And it's something that you can USE, UNDERSTAND, and EXTEND for your own needs.

This course distills what I've learned over the years into a full blueprint. My hopes are that you can learn in hours what took me ... well, a very long time. That you'll take this, extend it, and put it to great use.

-J Cole Morrison