QCON NEW YORK 2017

Conference: Jun 26-28, 2017
Workshops: Jun 29-30, 2017

Presentation: An Approach to a Container-Happy Tech Department

Track: 
Containers: From Dev to Prod

Location:

  • Salon A/B

Duration

Duration: 
5:25pm - 6:15pm

Day of week:

  • Tuesday

Level:

  • Intermediate

Persona:

  • Architect
  • DevOps Engineer

More talks on:

Key Takeaways

  • Understand the things you need to consider before moving into containers.
  • Hear an approach to creating a plan for bringing containers to your larger organization
  • Learn common pitfalls when bringing containers to your org.

Abstract

Is your organization ready for containers but does not know where to start? Or do you have many groups dabbling with containers and want to combine efforts? Containers have been the game changer sought by many developers, but some rules are still needed; in particular are the human aspects.

We will discuss an approach that can deliver a container-friendly environment while also fostering cooperation throughout the organization. From CI/CD of container images to sharing images, a roadmap will be presented that can be tweaked to your organization’s needs.

Interview

Question: 
You have been a principal architect at Viacom. What’s been your focus over the last few years?
Answer: 
At Viacom, there are many different platforms and over time we have been converging some of those platforms to one. We’ve been working on a centralized platform that allows smaller groups to be able to create feature libraries that are being owned by different business divisions.
My job is to make that possible. Right now we have different groups reinventing the same wheel. We want a way for everybody to be able to do that work and share it within the enterprise. They call it internal open source. You can call it whatever you want. But the idea is to come up with this shared library for these things. Along with that, as the architect over there, my job is to make sure that the platform has great features, like feature toggles.
Question: 
What is the technology stack at Viacom that you are working with?
Answer: 
The main bread and butter, the middleware, is PHP. We have a PHP stack that is thousands of classes thick. We have several different CMS’s. One CMS is powered by MongoDB and is fronted by a Java runtime. At times, we may also have a WordPress that serves as a CMS on some of our press sites. The press people don’t want to be bothered with that heavy handed CMS. WordPress actually works well for that. We use the same middleware to create the front end but we can point it at different CMS’s. On the front end, we have a JavaScript renderer. We still generate the actual HTML at times. It’s something similar to React but it’s in-house. We are using Mustache templates and those types of things.
Question: 
Where is Viacom in the adoption of containers?
Answer: 
A long time ago we used to have problems like publishing from QA to live. So we needed to have feature toggles and other features. That led me to investigate containers. I don’t really care that much about containers, but it gives me a platform to do many things that I need to be able to do. It forces us to do CI/CD. It forces us to be immutable. It steers you to a good architecture.
I have done the Daily Show over a year ago in Kubernetes and before that, I had done South Park in Mesos. It wasn’t hard to create a CI/CD pipeline that builds on containers. We would have our own internal nginx’s and Hip Hop, Facebook’s PHP engine, and because they did not have an official Hip Hop container image at that time, we would create our own library of components that we needed and glue them together. So, if you did a code change on MTV.com, it would trigger a rebuild of the static web assets along with the application code and then redeploy to the container orchestrator.
For the last six months, I spent a lot of time trying to operationalize it with our operations team. We got very far. It was actually being very performant. We transitioned the operations team to be more of basic cluster operations to make sure that the cluster was operating. We trained them how to make sure that the cluster was up, able to add capacity, remove capacity, and able to debug it. We transitioned them from Nagios alerts and logging into VMs to looking at StatsD alerts.
Question: 
Your talk is entitled “An Approach to a Container-Happy Tech Department.” What does that title mean?
Answer: 
A year ago, we inventoried everybody within the organization that was using containers, and we found that different people were doing containers completely differently, and they weren’t sharing any of their code. They had completely different ideas on how containers should be done. We had some people who tried to make a container look like VM. They would stick 7 services in it and say “It’s a container. It’s easy to deploy.” And you say “That’s a VM.” It was not a container, but that’s okay.
And it was not sufficient to just tell people, here is our enterprise registry for container images. That wasn’t enough. That was an image. So what? There is an image but how do I use it? How do I extend it? How do I contribute back to it? If my group is deciding that we are going to use CSSlint, and some guy goes, you know what? You have a great CSSlint thing but I want to use this new version of CSSlint.
If someone decides to use a new version CSSlint, how do we make sure that it’s built and how do you share that knowledge? How do you share the deployments? CSSlint is a different type of container. It is not a service. It is something that you put in and you get out. But what happens if we created a RNTB service? How do I use that? How do I do backups with it? How do I do all these things?
Brendan Burns talked at DockerCon last year, I think, about containers: you should think of containers as objects and you should think of them as parameterized things that you can extend and that have proper isolation from each other. Just like with object-oriented code, how much is too much abstraction? What is not too much abstraction?
What we were trying to do, and we all agreed on, was a protocol for how to share containers within the org. Even though we are in a mess right now, there was a common protocol that we had adopted. Every container has to have a build job. Every container has to have tests, every container has to have a wiki and every container has to have a maintainer.
There is a Git repository for you to check out not only the Docker builds, but also the sample deployments so that people can see that. I think it provides value to enterprises that want to engage in containers because I would assume there are other people besides Viacom that have people doing all kinds of different things, and they don’t know how to migrate into a strategy of sharing that.
I will also share some success stories and failures implementing the container sharing protocol. Some people embraced our protocol and some didn’t.
Question: 
What’s the persona that you are talking to?
Answer: 
I would like to talk to somebody who wants to bring containers home to their organization. People who want to have a unified approach to how they are going to build containers and share them across the organization.
It’s for a messenger that is going to go back and share this with his or her team. It’s not technically hard but you have to have a plan, and I don’t think everybody realizes that they have to have a plan. Your plan can’t be, we are just going to pull everything from Docker Hub, because there are always going to be proprietary things, and how do you organize that?

Speaker: Michael Venezia

Principal Architect @Viacom

Michael Venezia as the Principal Architect of Engineering at Viacom, modernized the Music and Entertainment division to a container-native environment. Since joining Viacom in 2008, he established the platform that Viacom now uses for its Music and Entertainment websites and API servers for its mobile apps, as well as emerging international sites. His interests include containers, distributed computing, machine learning, web development. He holds a BS in Computer Engineering, MS in Computer Science and Engineering, and most recently obtained an MBA from the University at Buffalo.

Find Michael Venezia at

Speaker page

Principal Architect at Viacom

Similar Talks

Learnings from a Culture First Startup
CTO @Buffer
Sunil Sadasivan
Docker Container Lifecycles – Problem or Opportunity?
Developer Advocate @JFrog
Baruch Sadogursky
Multi-Host, Multi-Network Persistent Containers
VP of Product @Aerospike
Alvin Richards
Securing Your Containers
Global Solutions Architect @Venafi
Carl Bourne
CI/CD Pipeline-as-code with Jenkins and Docker
Principal Solution Architect @CloudBees
Kishore Bhatia
Becoming an Outlier
Software Architect @VinSolutions, Author @pluralsight
Cory House
ESPN Next Generation APIs Powering Web, Mobile, TV
Senior Director of Distribution Platforms @ESPN
Manny Pelarinos
The Human Side of Microservices
Tech Lead @Yelp
John Billings
Lessons Learned on Uber's Journey into Microservices
Software Engineer @Uber
Emily Reinhold

Tracks

Monday, 13 June

Tuesday, 14 June

Wednesday, 15 June

See the Full Schedule

Conference for Professional Software Developers

Follow QCon

Contact

Menu

QCons around the World

Qcon