Forums
Containers make deployment easy, or at least that’s what it says on the label. It makes intuitive sense, though- instead of wrangling all your dependencies on a host OS, and then trying to understand why your app can’t see them, you bundle all the dependencies into a container and push that around when you want to deploy. It Just Works™.
Sandra had just left a company which didn’t use containers, but containers wouldn’t have helped: the didn’t have a working deployment process, period. They didn’t even try deploying before the production push 9 months into the project, and the first twelve attempts consistently failed because someone hadn’t tested something, or someone didn’t update the script, or the requirements changed and were signed off but nobody told the development team. It meant a lot of nights, a lot of weekends, and a lot of meetings which devolved into circular firing squads.
Enter Initrovent™, a cutting edge, SaaS provider which serviced the event planning industry. Karl, the Big Boss, assured Sandra that he completely understood the importance of deployments. “Oh, you don’t have to tell me,” he said. “I’ve seen so many failed deployments. We’re actually moving our platform into dockerized microservices with continuous deployment. We’ve built a process which works for us.”
Overall, the gig sounded like a good fit, so Sandra started a few Mondays later. She spent most of the day “on boarding”, so it wasn’t until late in the afternoon that she tried to get her development environment set up. Based on her conversation with Karl, Sandra had assumed she’d pull down a container and be ready to go.
She was half right. The company had one standard container. It had nothing in it. The install guide walked Sandra through spinning up one container and installing Apache, then another container for MySQL, then another for Memcache, then another for something only called “queue”, which reeked of some sort of inner-platform attempt at being “enterprise”, but Karl could only explain as being required “because of Docker”.
That was Sandra’s first day. On her way out, she stopped by Karl’s office. “Hey, since I’ve got those containers set up, should I put them somewhere so other devs don’t have to set them up?”
“What do you mean?” Karl asked.
“Y’know, so they don’t have to set up from scratch every time? They can just use the containers I set up?”
Karl nodded, as if he understood. “Oh, I don’t think that’s necessary. Besides, in my experience, every developer wants to set their environment up themselves. It’s fine.”
“That’s not how containers work.”
“Well, it works for us,” Karl said.
The next day, Sandra pulled down the code. The install guide, in bright red text, loudly announced that it must be placed in the /projects/intirovent/planner folder, because the Docker container was hard-coded to use that mount point, and no other. Once she had the code downloaded, she tried to test it, and discovered nothing but error messages. She went back through the install guide, just to be certain, and then took a glance at the code.
It was not microservices. It was a PHP monolith written using a 2012 release of CakePHP which had been endlessly tweaked in the intervening years. Lining up the errors she was seeing with the code, it quickly became obvious that unless a user was very careful with the application, they would see lots and lots of error messages. With a little practice, Sandra managed to get through the sign up process with only one cryptic 500 error, and even created an event.
In that code there was a folder called microservices. It was a bunch of RESTful endpoints. Karl explained: “They’re small, and they’re web services.”
“That’s… that’s not how microservices work.”
“Well, it works for us.”
That was Sandra’s second day. The week ground on like three fully interlocked gears, but by the end of the week, Sandra had not only cleaned up a few of the nastier bugs, but had finished off a new and rather large feature. She closed the ticket, and then Karl followed up: “Swing by, and I can show you how deployments work.”
“Deployments? On a Friday afternoon?” Sandra asked when she got to Karl’s office.
“Well, I did say we do continuous deployment.”
“That’s… not how continuous deployment works.”
“Well, it-”
“-works for us?” Sandra took a seat to watch the show. She wasn’t surprised by what she saw.
The purpose of containers is to have a single unit, with all its dependencies, which can be deployed, possibly to many different machines or VMs. That’s, at its core, how containers work. They’re easy to test, they’re easy to automate, and they’re easy to deploy.
Karl didn’t test, didn’t automate, and the deployment… well. Karl SSHed into the one server which constituted their production environment, and then went over to /projects/intirovent/planner, where he issued a git pull. Karl pulled up the site in his browser, hit refresh a few times, and smiled when he saw the landing page. “Great work.”
“That’s your deployment process?”
“Yep. Works pretty great, doesn’t it?”
The deployment process may have worked for Karl, but Sandra didn’t plan to work for him much longer.