Virtually, the wrong reasons

Overview

Currently there are a great many use-cases for containerization. Since its a pretty big deal and changing the direction of many industry deployment methods, now is a good as time as any to cover how its being utilized incorrectly.

What this isn't:

This isn't a conversation to discuss implementation, the permutation of correct vs incorrect way of utilizing containers; due to the simple fact that methods vary too greatly.

What this is:

This is more of a topographical discussion on a behavior that has been put in place by an industry that is going to be hard to recover from.

So to keep this simple and easy to follow; I'll outline the segments in bullet points and gratuitous usage of emoticons for simplicity.

Simple list of great reasons for containerization.

ಠ‿ಠ Repeatability: Consistent development environments with a limited variance of external resources.

ಠ‿ಠ Portability: Shipping code from one environment to the next while maintaining an expected state.

ಠ‿ಠ Sandbox Testing: [1] Testing with the mind-set that anything you've written that could potentially be environmentally destructive has a decent safe place with in a sandbox.

ಠ‿ಠ Memory limitation: Dev'ing on your local workstation isn't a stranger for many so when you need to police a potential memory violator, knowing you can set limits on the amount being consumed is always helpful.

ಠ‿ಠ Ephemeral tasks: Think UDP, if you need tasks spun up to perform single operations that aren't life threating if it gets completed successfully or not, or without high risk.

Some not-so-good reasons for containerization.

ಠ_ಠ Reliability: I put this one first (and forgive the long explanation). But some (nameless) industry giants have had unstable VPS instances that have left enough of the development spectrum with the misunderstanding that as soon as an environment goes down, we must spin up another to replace it for more reliability. This type of thinking is irresponsible.

While I'd advocate high availablility all day long, using containers for the sole purpose of reliability is about as logical as buying a new car because your current one ran out of gas.

ಠ_ಠ Scalability (only): I may get a lot of crap for this one, but solely relying on additional containers as the means of scaling with out usage of intelligent load balancing, heart-beat, monitoring is like using a broadsword for a surgery.

When you throw just more resources a problem its never a solution.

With other utilities that provide you adequate and reasonable metrics then you can find out problematic points in the application itself for stability.

That being said, ANY REASON for a business using containerization as a solution for scale with out sufficient insight into the application behavior and resource limitations is bleeding resources and will eventually have to double back and address the bigger issue at hand. Which (by this time) may have cost you customers, support, developmental band-aides and worst-of-all, customer experience.


  1. Security, There are always risks when working with 3rd party software, its inevitable. Which is why patching is important however its imperative that the risk should be assessed prior to going to "production" with any software but especially those that are specifically targeting containers. ↩︎

comments powered by Disqus