Sooo, I’ve been taking a networking class online, and it has been consistently surprising me with really interesting information. I wanted to share that info with others, but wasn’t really feeling a series of blog posts. Then I remembered some awesome zines (which is short for fanzine for those of you who are on my same level of un-hipness) I had seen recently, and it seemed like a fun medium to try out!
If you’re familiar with the idea of multi-region replication, feel free to skip to the Overview section. If you don’t know what multi-region replication is, why it’s important, or aren’t convinced that it is, I’d like you to imagine you’ve just sat down to breakfast in a small cafe. You’ve had a long night and your body is craving some refined sugar, so you decide to order a stack of toast (obvs).
After what seems like ages, your waiter finally returns with the promised mountain of carbs. You groggily reach for a slice, and in a moment of awe, realize that the toast has a depiction of a pug emblazoned on it. A PUG! You nearly collapse into tears of joy – if only you could bring this bliss to other toast lovers across the world! But wait! You remember that once upon a time you spent 4 years in an ivy league university learning the complex inner workings of all things computer.
I firmly believe that operations main goal is to increase developer velocity. This means focusing on crafting the tools and systems needed to expedite application deployments to production. A lot of this work revolves around removing operations bottlenecks from that deployment pipeline – the less the developer has to ask ops for, the more they can do on their own.
It would only make sense then, that developers should master their own application dockerfiles (images). This would allow them to create and modify their application runtime environment on the fly, not having to submit tickets for operations to upgrade or install dependencies on the host machines. I used to fully support this methodology, and helped enact it at a previous employer. Hell, the dockercon 2017 keynote even pushed the idea.
But, when I started working on the great docker migration of 2016 (GDM) at a new job, I found myself turning to the dark side of managed images.
I recently moved into a much larger home than where I was previously, and took the opportunity to exercise my interior decorating muscles. While that mostly consisted of furniture rearrangement and cleaning my fridge out for the first time in half a year, I decided to try my hand at decorating a small nook for my floof.
First thing I decided I needed was some sweet customized wall art, because I honestly don’t think the heated temper-pedic bed and monogrammed food bowls were letting Kirby know how much I loved (spoiled) her.
I know, I know – While the amount of buzzwords in the title might be overwhelming, the simple goal of this post is to introduce users to AWS’ Elastic Beanstalk Worker Tier offering, and give a detailed tutorial on how to build and deploy an application to it.
If you don’t feel like reading the entirety of this tutorial (spoiler alert, it’s long), or want to jump straight to deploying & playing with the default app – skip ahead to the TL;DR section at the end! I promise not to judge. 😀