Containerized Coding: From Chaos to Consistency

Introduction

Containers are right up there (top 3 for sure) in terms of things that have blown my mind to learn over the years as a developer. One of the first things that blew my mind was simply getting a website deployed to a production environment using shared hosting. The next major breakthrough in my world was learning how to make and use automated pipelines in Azure DevOps to deploy a website. The moment I saw all green checks and went out to my site and saw my changes pushed, all bets were off. I remember standing in my living room telling my wife excitedly that she wouldn’t know it, but I’m deploying my website right now, and I have all this time back for activities — because I automated the entire process. She did not, in fact, know that I was deploying a website, nor what the hell I was even talking about, but she was supportive all the same. All of these powerful moments in my career as a dev have led me to this point, the point of learning to use and implement containers. Containers, I must say, take the cake in total amount of mind being blown. 🤯

The Why

Containers complement and continue to build off the first two major moments for me. Just deploying an application to begin with, and automating that deployment to help reduce cognitive overhead, and human errors. Anyone who’s deployed a website manually, or been involved in a manual deployment, know just how much it sucks. Used FileZilla to do a folder compare and had your comparison settings wrong? Did a date only, but not a content diff check? Welp, deployment failed! It’s awful, and there’s a reason that pipeline automation formed over the years.

These days, deployment automation isn’t a luxury, it’s a necessity. Containers further reduce complexity and overhead by standardizing applications and their dependencies across environments in a way no other form of deployment method could come close to achieving. They help to further stabilize, increase speed and decrease errors in deploying applications. They are the difference between receiving customer feedback and having a change made, tested and deployed in weeks, possibly even only a few days, and what used to potentially take months.

The How

A collection of new tooling is needed to begin implementing containers into your workflow. You’ll need Docker Desktop (if you want to stay sane), the Docker Engine installed (comes with Docker Desktop) and something like VSCode if you want to keep things simple when making an app into a container. There’s a thousand ways to skin a cat, and containers are no exception. If you’re a terminal user, use the CLI commands. If you prefer GUI controls, VSCode and Visual Studio both provide easy to use and out-of-the-box controls to interface with Dockerfile’s and compose.yaml files.

Visual Studio even goes a step further, and anytime you make a new .NET Core application there’s a handy little button that asks “Do you want to containerize this app?”…Doesn’t get much easier than that!

You’ll also need some sort of production environment that supports containers. DigitalOcean has their suite of products, including their own container registry. They have App Platform, which allows you to completely bypass a registry altogether, and if your app contains a Dockerfile it will manage containerizing and deploying for you. It’s about the easiest way to get up and running. Azure, of course, has their suite of products such as: Azure Container Registry, Azure Container Apps, Functions, Kubernetes, etc. Knock yourself out over in Azure (just be mindful of cost, because it’ll sneak up on you).

The Where

The way things are headed, with PaaS, SaaS, IaC, Cloud and Containers, all roads point to development that is redlined in terms of speed and ease. Serverless architecture and PaaS are lending to an app development environment that not that long ago was barely conceivable. More and more cloud providers are coming out with their own offerings, and for pennies compared to what it cost to set things up you can have a full enterprise grade architecture running in no time.

There’s a trade-off, however, that must be mentioned. PaaS, SaaS, and any other *aaS, all have an inherent and sometimes sneaky little dark side. You’re paying a premium to give up control and trust in that service provider to do all the heavy lifting for you. Things like, updates, maintenance, security, and any other role it takes to manage servers, networks and the like, all cost money. It’s why these services started to begin with. Most companies providing goods and services are not technology companies. The mere fact that their products are created and delivered using servers and complex networking is just the way the world works. But, this doesn’t mean that every company has the luxury of time or money to be able to pay entire staffs of people to take care of.

So, what you’re paying for in return to not have to hire IT staff, database experts, networking professionals, etc. is a nominal fee that in general equates to a lot more than it might take to just pay for all these raw goods yourself. There’s absolutely nothing stopping you from buying a server, setting it up in your mom and dads basement and running your next startup from it. But, how much time do you think you’ll be spending on developing features for your new startup versus the time you’ll need to spend keeping the server up-to-date, keeping up on security patches, ensuring database security and configuration are up to snuff…You’ll be buried in busy work. This is exactly the state of companies across the globe. And it’s why cloud managed services are continuing to spread like Canadian wildfires. But, again, there’s a cost associated with it all. You have to be mindful of your budget, and try to ensure you have controls in place to help prevent rampant spending. It’s worth it though, I assure you.

Summary

At the end of the day, I’m a software developer and my customers are who I’m developing software for. I own a car, and I rely on roads to get me from place to place, but generally (apart from any major potholes of course) I don’t give a rats 🐀 butt about how the roads are made, designed or maintained (infrastructure). Just let me take my car (my app) and give me a road (PaaS, SaaS and all other *aaS) and let me give you some money so I can keep on driving. Customer’s also don’t care how you get them their updates, they just want their updates. Containers simply continue to help grease the wheels of software development and delivery. Providing rapid updates from customer feedback, change requests and new product demand. I don’t think containers or PaaS technology will slow down anytime soon. This chapter in the world of technology seems to be here for the long haul.

Prezi

---

I’ve put together a short Prezi presentation that covers the basics of what life might look like to developers who are just getting familiar with container technology. It’s not comprehensive, but should contain some nuggets you can use to have a deeper conversation with ChatGPT and Gemini. Good luck, have fun and make something great!

Link to Prezi

P.S.

If you liked what you read, or if you didn’t care for something, I do read the feedback and comments. If you do like it, please feel free to leave an emoji of some kind. They always help make me feel like I’m reaching folks who want to keep learning, and it helps keep me motivated to try and keep growing as a writer and tech professional.

Thanks for your time, happy coding!

~ Charles