Applying 12 Factor Principles to Containerized Applications! @ Docker Atlanta Meetup

April 13, 2023

< 1 min read

Applying 12 Factor Principles to Containerized Applications


Enter for a chance to win a Google Nest Speaker!


Melissa McKay

    Melissa McKay

    Melissa is a long-time developer/software engineer turned international speaker and is currently a Developer Advocate on the JFrog Developer relations team, sharing in the mission to improve the developer experience with DevOps methodologies. Her background and experience as a software engineer span a slew of languages, technologies, and tools used in the development and operation of enterprise products and services. She is a mom, Java Champion, Docker Captain, co-author of the upcoming book DevOps Tools for Java Developers, a huge fan of UNconferences, and is always on the lookout for ways to grow and learn. She has spoken at Kubecon, DockerCon, CodeOne, JFokus, Java Dev Day Mexico, the Great International Developer Summit, and is part of the JCrete and JAlba UNconference teams. Given her passion for teaching, sharing, and inspiring fellow practitioners, you are likely to cross paths with her in the conference circuit — both online and off!

    Video Transcript

    give you this is your first Docker Meetup Docker Atlanta Meetup okay awesome we only had one since the

    pandemic in person and that was back in February so we’re going to work on my name is Ari Waller and

    um I happen to be the local doctor organizer for the Meetup um and we’re going to work on getting

    one every other month um and we’re really excited about that we have a lot of other events at jfrog

    so sometimes I think some of you have come to some of the other events that we have here as well we have some devops oriented meetups too so we have

    obviously we have a really great facility for this and uh my job happens to be a portion of it has to be meetups

    so um we definitely want to take advantage of that and obviously share with the community as much as possible so welcome

    um we started a Docker Atlanta Meetup Channel I mean YouTube channel so if you

    have not subscribed yet it’s a small list right now but go ahead feel free to take your QR code and sign up uh we are

    going to typically um unless there’s a reason why not uh post uh the videos

    um I’ve been asked by a few people are we going to make these hybrid and the answer is no um I believe that hybrid is the cannibal

    of the in-person Meetup and um you know I just I I was definitely torn both ways if

    there was a way maybe wanting a technologist and I can go into business you ready for this do you know how local football games you know they um they

    make the game unavailable to the locals unless it’s sold out well uh if we can

    create a program presumed to do that it’s probably something with IP addresses and stuff like that I’d be

    happy to let people from other states uh join but not the state of Georgia so if there’s a way to figure that out let’s

    talk offline we’ll make a lot of money but other than that we’re going to continue to do it this way so

    um but we will eventually and I say eventually I hope to get it up fairly shortly after uh meetups on the channel

    we have two of our last videos up there right now for your enjoyment um typically so far what we’ve tried to

    do I’m going to try and do this at least for the rest of the year is there’s some amazing people out there that have

    earned the um title of Docker captain and I want there to only be one person that um logs

    in for these meetings and that is the docker captain and I want to do that consistently through the year so um this

    month we are lucky to have Melissa McKay who actually happens to be a J frog employee which is awesome and does hold

    the title of Docker captain yeah Docker Captain last time and um next month and next in June I am talking

    to the docker Captain um Ajit arena in um in India who runs

    the Bangalore uh Meetup very active in the community very active in the docker community in

    fact I think he helped some of the standards in place for the captain’s at one point um and uh he’s going to be sharing with

    us a brilliant speaker and uh looking looking forward that as well for June so that’s that’s the plan

    um also uh we want to hear from you this is uh you know where we want to have both a Docker captain and one of our

    local speakers so tonight we have Ray that’s going to be sharing with us um and we would like one of those speakers to be somebody in the community

    as well um go to our call for speakers you can always send me a note on LinkedIn too it doesn’t have to be formal but uh do

    submit a topic um and uh we’ll take another okay and then we’ll get back to you we’ll definitely get back to you

    um but uh we want to hear from you and you don’t have to be an expert to speak have to be the grand Pub of a particular

    subject and doctor to do this there’s value to what you do every day obviously

    Docker has enough uh components to it that you are probably an expert in something you don’t even know you’re an

    expert in just based on what you do so share with your share with your colleagues and it would be really really valuable

    uh follow us on Twitter another small following but we you know kicked it all off at once uh Shameless plug for my

    amazing son who’s a graphic designer he created the doctor Atlanta logo and uh

    yes I did get permission to use it uh by uh by by the community team there because I didn’t want to infringe on any

    uh copyright so very proud of my son if you ever need some graphic design work ick designs

    um uh also uh so I don’t like to do a ton about jfrog

    um so for those of you who don’t know this is where I balance I am the community programs manager for jfrock so

    my job at jfrog is I handle Global meetups for jfront the docker is set aside from that I

    don’t feel I deal with Meetup organized all across the globe and it’s not fair that I work with them

    and for a living but I don’t understand what it’s like to be a meet-up organizer so during the pandemic I was a Meetup

    organizer from multiple meetups including go uh San Francisco and go to New York throughout the pandemic but now

    that we’re back in person I really wanted to see the docker meet up in Atlanta uh be revived again so it’s

    really important so this is um in essence but I do get to where the jfrog hat too because a J frog is a host and I

    get the help with the facility so just a couple of words from our sponsor very quickly tonight we are doing a raffle uh

    for a Google Nest you may have already signed up for this if you have it’s great we will select the winner at the

    end of the evening you must be present to win okay um now we did I have another contest

    with jfrog this month now this one’s a little bit different this is a monthly contest and this is a survey so we have

    one of the most important things jfrog was founded based on uh the community feedback loop frankly we were an open

    source product and we started in 2006 even before we were a company in 2008 and because that connection to the

    community is so important for us we do have a survey and um we would love if you are willing of course totally opt in

    this is optional of course is to fill out the survey and you will be entered into our monthly contest

    um and the first week of May we’re going to be doing the drawing for a Nintendo switch when it will be contacted by

    email that week terms and conditions apply they’re there you’ll see them want to um but uh one of the things that also

    helps us do just frankly this is a very PBS but uh it allows J rob to continue

    funding Community programs like this so it’s helpful when they get that feedback

    so contribute if you’d like to and if not just enjoy yourselves it’s no pressure for that tonight

    yes there’s the Google Nest one if you want to get that one well oh J5 employees can’t win any of

    the reviews so if you’re from James Brockton Kansas um so I have uh I have to work on

    getting the jetbrains Ides for this for this Meetup the problem I’ve had and I think you’re all I need your help this

    evening before we go into our first talk is I’ve been I’ve been getting jetbrains Ides throughout the pandemic and I have

    several from the last three months that I have not given out because I don’t do the go meet up anymore if these I don’t I’m gonna make the

    appropriate connections but I don’t want these to go to waste so if I’m going to probably hand something out shortly that

    you pass around I know some of you already typed it in but basically I need

    um if you want to be entered into a contest for a IDE this evening I have enough to give away how many how many

    people would actually get the IDE and activate it tonight if they got it raise

    your hands okay I would say that we probably have something for most of you then

    um so that’s good and if you don’t have an IDE I definitely have a couple of codes for some doctor swag so way too

    much to give away tonight again I don’t want to spend too much time on the giveaways let’s get to the talks but um I’ll probably just um at the end uh

    figure out ways to distribute those uh appropriately okay um that being said without any further

    reviewing you there Melissa I am here can you hear me okay yeah we can let me

    go ahead and unplug from this all right well everyone our first talk is going to be from Melissa McKay I’m

    not gonna do her justice with her introduction but I will say one of them uh and I mean

    this sincerely I do work with amazing people at jfrog but I have an immense amount of respect and love love love

    working with Melissa um and she’s got some really amazing insights and experience that I know uh

    she’s gonna share with us tonight so everyone uh J frog developer Advocate and Docker Captain Melissa McKay let’s

    welcome her from Denver [Applause]

    thank you hey everyone um I can’t hear anyone anymore so I hope

    hopefully you can still hear me can you give me a thumbs up all right awesome I’m gonna go ahead and share my screen and get started here

    all right um you should be able to see my slides now um we are here for applying at 12 Factor

    principles to containerized Applications this is actually draft one of a talk that I’m continuing to build out I’ve

    got some ideas for it so I’d love to get your feedback after what more you would like to see

    um and especially if you have any questions that you want me to dive into deeper I usually like to do more thought

    leadership talks um this one in particular is not so much into implementation details yet it’s more of

    the thought around it the reasons why we do the things we do

    um but as I get more uh time to speak and use this talk I’d love to expand it into workshops and get into the deep

    implementation details because I’m sure that as we go through some of these factors some of these principles you’re

    going to be wondering well okay that sounds great but how do I actually do that

    so just a little bit of intro and I was there in Atlanta not too long ago I really miss being there with you so I’m

    glad to be able to be with you virtually at least this time hopefully we’ll run across run paths you know again in the

    future next time I’m in Atlanta but um just a little bit about my background I have been a developer

    Advocate now for three years with jfrog um prior to that I was a developer by

    all means all the way from intern to principal developer at my previous employer

    um during that time I became a speaker I got involved in helping to organize some

    unconference events uh these are conferences that are less formal they’re more like

    um groups of folks that are in a circle uh very much a smaller audience it’s not

    so much one speaker up front talking and you know teaching everyone it’s more of a group effort

    um the topics are chosen uh each day depending on who arrives and who has the

    expertise very very cool stuff so during that time while I was doing that I

    quickly realized that being a speaker and being a full-time developer was pretty difficult we all have obligations

    outside of our normal jobs so I decided it was time for me to find a position

    where I could do this more full-time so here I am with jfrog um during the

    last three years I did become a Java Champion uh Java is my um primary uh career language

    um but I’ve never met a Java developer that isn’t into something else these days we all have learned you know a lot

    of other uh tips and tricks along the way and a lot of other languages something I’m interested right now in is

    rust that’ll be forthcoming um I did become a Docker Champion as a

    Docker Captain as well um containers have always intrigued me

    mainly because of the reasons why they came about how they came about how we use them now

    um so it’s something that I continue to delve into not even not just Docker but all containers in general

    um here’s my uh LinkedIn and my Twitter handle if you want to reach out to me you can do that at any time especially

    if you want to ask questions or just provide me some feedback

    all right so um I’ve been working with containers for a while

    um and in my previous uh position as well it was something that was brought

    to our team where we you know needed to containerize an existing application

    um this was my first time in dealing with containers actually so when I first

    took a look at it at the docker file that was exciting for me to you know walk through that and figure out exactly

    what’s happening and how this is working um but something I always like to do is

    always go back to the original principles for now you can do so much

    with just a Docker file and all the commands that are available to you you can do all kinds of things that are not

    good for you you can do things that are good for you so uh it’s always a good idea to go back to the beginning figure

    out what best practices are without learning too much from trial and error

    like I have in the past sometimes that can be fairly painful

    I do have some stories I can share about that as we go here

    um so I I went out and I went looking for the 12 Factor app this is something that’s been out a long time if you’re

    not familiar with the 12 factors um definitely go check it out it is all

    available at so take this link down and

    go there much of this talk is heavily based on that there is a lot of you know

    blogs and stuff out online about this as well but I like to go to the source read

    it figure out how it’s applicable to me and then go forward from there but basically the 12 Factor app was

    written by Adam Wiggins around 2011. uh he put it out online as an ebook

    um he was one of the founders of Heroku and he was interested in how to release

    software reliably how to scale it quickly and how to maintain it in a

    consistent and predictable manner all of this sounds like heaven to a developer like me so obviously the 12 factors are

    something I’m interested in uh this is just a snapshot of his

    website this is what he has clearly a passionate person I’m interested in making all of

    our Lives easier um someone um will do to follow and check out if

    you’re not familiar with Adam Wiggins

    this slide just comes directly from the 12 Factor app website

    um it talks a lot about the methodology um it’s primarily focused on software as

    a service app um it talks about using declarative formats for setup automation

    um I know for one as a developer I I cannot count how many times as a new

    developer on a new project I was always assigned fix the documentation for

    setting it up um just and it never worked never worked the first time it was always a struggle

    so you’d always Reserve you know maybe two or three days to ramp up on a project make sure you have all of the

    dependencies that you need and and make sure you know the documentation is up to date so this whole idea of focusing on

    automation around that is huge um definitely works to minimize time and

    cost for new Developers it also talks about having a clean contract with underlying operating

    systems and it talks about you know portability between systems I remember

    one time I was set up on a new project I started to get everything building and

    all and I started running through the tests just to make sure that I was a good point in the application

    development cycle that I could start working on something new right this is a common thing we do this all day every

    day so I started running the tests I get to one group of tests and it fails

    immediately and the reason it fails is because of the last person that ran those tests was running on a Windows

    machine and they had written a test that was specific to a Windows machine things like file

    system stuff and uh I just thought that was really silly so this is something

    that pleases me to see that we work more toward and focus on making sure that our

    stuff is compatible doesn’t matter what OS you’re running on obviously this is

    my love coming from a Java background so look forward to

    um we talk about suitability for deployment on Modern Cloud platforms

    I love spending more of my time on the development side of things rather than on CIS admin work so something that I

    like immediately minimizing the diversions between the different environments

    like development and production and enabling continuous deployment

    technical oversight committee for um the CDF The Continuous delivery

    Foundation um this is something that’s been really interesting to me so we talk a lot about

    continuous delivery we have a lot of special interest groups that that come from this Foundation one of them is

    interoperability I’m a chair of that group as well these are all you know

    groups of people that are interested in making this easier for everyone for Developers for those on the operation

    side of things any devops teams this is all a goal of ours to make continuous

    delivery the default way of doing things

    um scaling up without significant changes to tooling architecture or development practices

    you know it’s it’s lovely when you get your service all up and and it works great it passes all the tests and you

    deploy it and then the load just killed it uh this is something that obviously if you’re you know for-profit

    organization is something that you want to address immediately so being able to scale up being able to offer your

    services without interruption to all of your customers something that you know

    we always want to improve so all of this sounds good and I’m just

    talking about 12 factors I wasn’t talking about containers but this sounds very much like the goals of container

    containerization right A lot of these goals are the same it also goes hand in hand with uh you

    know microservice methodology a lot of these items here apply to microservices

    as well well

    um you know Docker introduced The World To The World um as open source that happened in 2013.

    so you know a couple years after this 12 Factor app made its first appearance its

    first draft out there we did start talking about containers a whole lot more

    um now both Docker and containers in general are you know household words but

    it has taken us some time to get here and a lot of that really was about

    getting more of the tools um ironed out there was a lot of done a

    lot of work done in the industry around tooling to make that whole containerization process of SAS apps

    more efficient and easier for developers to pick up and do right off the bat

    and a huge part of that is due to the development of Frameworks like kubernetes openshift Docker swarm and

    and some others out there um but now we’re at a point where most

    people I know you know if they haven’t worked with containers they certainly have heard of them and um certainly in

    this group here you probably are all working with containers right now so the real question here is why do I

    have a picture of bananas on the screen and uh this is just a silly thing for me

    I have yet to find a more fun theme for containers than bananas I absolutely

    refuse to use the shipping container metaphor um so hopefully you’ll enjoy this make

    this a little bit more entertaining for you all right so we’re going to walk through

    these 12 um factors with these 12 principles and

    just see you know how we feel about them why they’re there what the idea is behind it and maybe how it applies to

    containers um I’m by no means a banana expert but

    just a little bit of research um came up with this bit of trivia might be useful to you someday who knows but

    the commercial version of the banana that we see today is the Cavendish variety and these plants

    um they actually are genetically identical clones they do not grow from

    seeds and because of the years of cross breeding and stuff any seeds that you might see when you bite into one of

    these bananas they’re just vestigial if you actually go out and try to plant them they’re not going to grow into a

    banana plant unfortunately and this picture here is of a rhizome or

    a bulb that can be taken from one plant and then transplanted and it will also

    eventually produce more bulbs and then that process is repeated and now whether that’s a good way to maintain our

    commercial supply of bananas uh that’s Up For Debate but um why do what does

    this have to do with this first principle and uh I ask that you stretch your brain a little bit to really get

    the metaphor here but the idea is that no matter how many deploys that you have your app should come from a single

    source the code base should be the same across all of the deploys all through

    the different versions that maybe deploy and um you may have different maybe some

    commits that aren’t yet into um staging or into production but they

    all come from the same code base so you can you know identify them as different deploys of your same app

    and that is directly from the 12 Factor information

    foreign T being the case I always feel bad for

    picking on this particular project because I use it a lot for especially in workshops or um just to show as an

    example it’s actually a really good example but there are some things in here that are intended specifically for

    demo purposes not for production purposes so although I pick on this I’m

    counting on the fact that we all know this is not an application that’s meant

    for production um it’s here for us to play with and work with and learn how to do things

    this is from a GitHub repo It’s called Spring Clinic Cloud it came originally

    from a microservices version of this pet clinic application it’s it’s basically

    like just an application that you could use if you were a veterinarian for example uh checks in you know people’s

    pets and Records who the owner is and things like that anyway

    um there’s lots of different differences in here but they’re all

    uh actually different services that probably should be in their own repos

    these are all in their own uh in directory but all within uh the same

    repo and in the 12 factors uh uh it explains that if if

    this is actually would be a distributed system and each of these components

    should is an app and each can individually follow the 12 Factor

    methodologies um so this right here is actually a

    violation of 12 Factor uh which if there’s any code that’s shared that should also be uh put into a library

    which can be included using a dependency manager of some sort um so yeah having it all here in the

    same repo isn’t exactly how things should be done in this particular app if you wanted to go check it out each one

    of these Services when you build it results in its own individual container here

    all right number two and uh I’m gonna focus on this one pretty heavily because dependencies are

    my thing um but uh and I certainly won’t spend as much time on the rest of the factor so

    don’t be afraid I know we spent a lot of time on just the first and second one here um but we don’t talk about dependencies

    enough so I’m going to spend a little bit more time here um directly from the 12 Factor app a 12

    Factor app never relies on implicit existence of system-wide packages

    this means you can’t ever take for granted that if you run curl that it’s

    going to be there unless you explicitly put it there so this is something that applies to a

    12 Factor app but certainly applies to Containers right you can actually make their life a little bit easier because

    it gives us an environment that forces us to make sure that everything we need is in there

    it has gotten um difficult um because now we not only have the

    application that we’re worried about as a developer but now we have the packaging of the application and

    everything that’s around the application um so we’re we’re talking about the OS

    tools where you know OS packages things that are that come in that are separate

    from the actual uh Java application or or JavaScript application or you know

    whichever um so

    the 12 Factor app really encourages um developers to use package manager for

    their apps and then we also need to just pay attention to where everything is coming from and if we walk through the

    development process by itself we start out with our developer this developer

    chooses a language and framework let’s say he’s very wise and old and he

    chooses Java and he’s going to need a package manager so this developer might

    choose Maven and lists all of these dependencies in a pom file then when

    they build the project locally this package manager assists by reaching out

    to a global Central repository in this case it’s going to be Maven Central and

    pulls in everything that you need the problem here is transitive

    dependencies these are dependencies of dependencies so even though I may have

    done the work of explicitly declaring the dependencies that I want in my

    application that I’m using directly those dependencies may have dependencies of their own so we

    need to pay attention to that make sure that we have a good accounting of everything

    that our project relies on obviously developers do not want to

    reinvent the wheel um this is an overused graphic really but this concept is real

    um software is potentially made up of a ton of components that a developer doesn’t may not have firsthand knowledge

    of these applications and services that we have today are more complex than ever

    and developers generally you know we don’t want to repeat we don’t want to rewrite stuff that’s already out there

    so we continuously bring stuff in unfortunately this becomes even more

    difficult when we bring in build servers and they’re meant to be tools to

    automate this process make everything easier for us but they behave the same way unless you configure it differently

    you’re going to have a build process that reaches out to Maven Central

    and then pulls all of your dependencies in um this is the time when you need to

    consider some kind of artifact management system Shameless plug for

    artifactory really excellent at this um but whatever you use it’s got to be a

    better use um then constantly reaching out to Central

    repos now you may have multiple setups in your

    build process and one of these steps could be actually the job of packaging your application into a container and

    once again by default you’re going to be reaching out to Docker Hub the central

    repo for a lot of containers bringing stuff in to your build processes and

    using it so you at this point you would really need to consider making sure that you have you know some

    kind of caching mechanism or some kind of artifact and image

    management system where you can pull these in and store them without constantly reaching out to these

    external services for this even more complicated all of these steps

    and and jobs will be running any containers themselves and these could be

    managed by you know some kind of build a platform out there where they’ve decided for you what container you’re going to

    be building and all of these things you need to pay attention to when you’re um

    you know considering how your project is built uh really making sure that you’re taking a you know having a good

    accounting of everything that’s involved in your process and making sure that you mitigate a lot of maybe

    third-party pain especially when maybe one of these third-party services become

    unavailable for a limited amount of time or maybe forever if something is deleted

    or moved that you need for your build

    I like looking at real examples um this is a very very derived Docker

    file here but the interesting parts that I want to focus on are highlighted uh we talked you know about application

    dependencies and stuff now that we’re packaging them in containers we’ve got some other dependencies that we need to

    be concerned with uh you can see that you know there’s some packages here that are being installed

    um on this image that need to be available for our application for whatever reason

    and the one on the left does not explicitly Define the versions of these

    applications um that isn’t horrible in and of itself it’s just that now you have a build

    that’s pretty uh unreproducible um it’s going to take some homework you

    know to get in there and figure out what versions is actually being used you can cause yourself some troubleshooting

    problem especially the next time you need to rebuild this image and all of a sudden it doesn’t work and

    it brought in a later version of a package than you had before it’s not even your app it’s something else in the

    system so do yourself a favor and explicitly Define the versions that you want to

    bring in of everything that you need

    um the one on the right you know obviously put in some versions um but there’s a couple of other questions you

    should be asking right away that Top Line we are starting with a base image sure we’re declaring the version but

    where is the space image coming from do we have it stored do you know how it that one is built when it comes time to

    update it are you going to be able to these are things you need to know about your own project and how it’s built

    and then this line obviously like I said this is derived um this isn’t a real application it doesn’t even have like a

    language you can’t even tell but [Music] you would want to know if you’re just

    copying an app what version of the app is this where is it coming from you know is it is it just the latest

    version that was built is it the latest that has passed tests is it the latest that’s past integration tests so that

    it’s you know able to go into production without a worry these are things you

    need to consider when you’re writing your Docker file

    all right moving on like I said we’ll go through the rest of these much faster so number three involves config

    um lots of times um config could be stored you know as

    constants um basically don’t do use environment

    variables that’s what the 12 Factor um

    what that says is to use environment variables there’s lots of different ways to do this but one one thing that the

    principle says and this is directly from the text a litmus test for whether an

    app has all config correctly factored out of the code is whether the code base could be made open source at any moment

    without compromising any credentials so now we have it now we have the why we

    need to worry about this we don’t want our credentials being stored in places they shouldn’t this is something I

    struggled a lot with a lot of java applications because we did have you know this idea that we want to be able

    to run our application in different environments without having to uh

    rebuild the whole thing and no it first started out with believe in profiles we were able to build you

    know like a profile that was intended for development or a profile that was intended for production but the problem

    with doing it that way is that in order to release you had to rebuild to release

    well whenever you’re involved in rebuilding your application you kind of

    defeat the purpose of going through all the testing of the original artifact so that was never really a good way to

    do things so I really appreciated when um spring came onto the scene and they had

    spring profiles these were profiles where you could actually just through an environment

    variable affect how the app would run like which configuration it would use uh

    things like so the things you want to include in your config are you know any

    backing services like database credentials things like that

    um also you need to be careful about how you inject variables like that into the

    docker container because passing those values directly via the command line is

    is not very secure um you could you could accidentally

    um put stuff like that into Source control um and also when those containers run when

    you pass it in that way if you do an inspect on the container if you have access to be able to do that you can

    actually see the values so potentially you could have you know maybe you want

    to limit your developers from knowing you know production passwords that’s not really a trust thing so much as a don’t

    do something stupid by accident thing I’ve had some painful uh experiences in

    that world I do not want to have access to things that um I’m really I really

    shouldn’t have that includes production resources like that um so in those cases you really should

    be using something like a Secrets manager this is you know something like hashicorp vaults AWS has a Secrets

    manager there’s a Google Cloud Key Management Service there’s all kinds of stuff that you can do so you don’t know

    what you don’t know um meaning that sometimes you feel the pain before you realize this is an issue

    prevention and go ahead and um make sure that you’re dealing with your

    config appropriately

    okay look at this this is a good

    um this a backing service is really uh any

    service that the app needs as part of its normal operation that includes databases that includes any messaging

    systems like Robin and queue um that includes you know maybe services

    for mail SMTP Services maybe caching systems uh things like that

    these um really and uh and from the 12 Factor app

    the code should make no distinction between local and third-party services

    so any of these resources should be considered just attached resources they can be accessed via a URL or credentials

    that are located in the configuration you should be able the goal is here is

    to be able to swap any of those things out without having to rebuild the app and in this case that makes sense for a

    container we don’t want to have to rebuild um an image and launch a container just to

    be able to swap out something like this

    all right number five build release run strictly separate build and run stages

    now just for fun I put a YouTube link here that’s to a video of how bananas

    are actually sent through a processing plant I learned more about how bonanas are processed than I ever needed to know

    but I thought it would be fun to include um this picture is also of banana processing plant I mean if you can

    imagine they need to be grown they need to be harvested they need to be washed and then they need to be shipped

    everywhere so yeah it’s all very interesting um our software needs to have different

    stages like this too from you know development in the beginning all the way to actual deployment and the most

    important stages are the three that are defined in the 12 Factor app that’s the build stage the release stage and the

    Run stage every release should have a unique ID

    in Java this was for our jars it was you know we always had like a time stamp attached to the end

    um or you can have you know some increasing version number these are you know the tags for images are often set

    up this way releases cannot be changed after they’ve

    been created so once you’ve developed and you’ve

    built that build should be immutable um other than you know environment

    specific things that are run by you know config that we talked about you should never be rebuilding your artifact when

    you move between different environments or when you go to release and then of

    course when you go to run your application so that’s the rule here for your images

    same thing you should never be rebuilding your images it should be built in the beginning this

    you know may be triggered by a commit to a repo developer makes some changes makes a Commit This goes through the

    build process the build uh goes through and assigns a version

    number to that particular artifact now that artifact is ready to be promoted through the rest of the life cycle until

    it potentially actually gets released to production

    number six processes 12 Factor processes are stateless and

    share nothing any data that needs to persist must be stored in a stateful backing service typically a database

    that’s a quote from the 12 Factor app uh one thing that they do here is they

    call out sticky sessions specifically and I have to laugh because I do remember an application I worked on a

    long time ago where we it wasn’t a computerized application initially but we were working toward that end and we

    didn’t deal with this problem until much later um but we already had it up in

    containers and we absolutely did use sticky sessions for a while so uh this

    is definitely something that needs to be fixed your apps should not have state

    within them um for the simple reason is because they’re ephemeral containers are

    ephemeral they can leave at any time they can be shut down at any time

    um so if you really need to rely or use session State data or anything like that

    you need to bring in something like memcache or redis something that is more

    appropriate to handle that type of data I certainly don’t be handling it with your container

    number seven Port binding it’s pretty simple to me I mean it was one of the first things I learned when um building

    my first containers and being able to assign a port and then just being able to access it directly on my local

    machine was pretty awesome um I know an app that I containerized

    you know previously involves um injecting a web server into the

    execution environment and in this case now that we have containers

    um we actually you know use a dependency to add the web server

    library to the app itself so we we have it available to us it’s not something

    that happens later really

    nice for me because I do remember being in a situation where I was working on an application that was

    uh delivered to a client who then set it up and used it so just to clarify I was

    working on a Java app and I delivered to them the Java app the Java web app and

    then they would do all of this stuff you know to get it up and running and and get the web server set up and stuff like

    that we at that time did not have very good communication about what web server they were using what version they were

    using all kinds of stuff so in our own internal testing we discovered some pretty severe issues with that uh

    consider concerning certain versions of Tomcat and uh some things just did not work quite right so that was something

    that we had to go through painfully so this is a much nicer to have a

    dependency like that to be included with the application

    number eight concurrency in the 12 Factor app processes are a

    first class citizen this is nice for containers especially I

    mean this allows us to scale out horizontally much easier and a good

    example of doing this too and being able to handle work like this is using The

    Good Old Pub sub architecture so you have you know you consume uh requests

    you might put those requests on a queue maybe that’s handled you know by a

    broker of some kind you can then collect maybe you have workers that get spun up

    and they collect work from that queue and you’re able to scale better that way

    so this fits right into how we deal with containers and how we you know logically

    divide this is to make sure that we can scale really

    number nine disposability the 12 Factor apps processes are

    disposable meaning they can be started or stopped at a moment’s notice this goes right along with you know a good

    reason why you don’t handle state in your containers um you need to be able to do this you

    need to be able to scale but not only just scale up but scale down this means you know you’re able to take advantage

    of some cost savings and resource savings when your load isn’t as high so now we have you know automatic scaling

    capabilities that Frameworks like kubernetes offer us and we need to be

    able to shut down these Services gracefully meaning they really need to

    respond to a Sig term signal so this is something that you need to make sure works with your container before

    releasing um and then you know in order to be able to scale up

    you need to be able to minimize your startup time as well um also

    make sure that you implement you know liveliness and Readiness probes so that

    you can you know your internal systems can be more aware whether or not a container is actually ready to start

    receiving requests uh things like that and most of us are not going to be

    perfect with this right out of the gate I know my team several years ago wasn’t

    um we had containers uh that were continuously restarting and

    unfortunately we did not have the best communication with our operations team at the time so their solution was just

    oh well if it crashes just get just restart it well the result of that since I already confessed to you that we were

    handling some State the result of that was that we would often lose you know parts of jobs

    um things like that would go on so if make sure that you have that

    communication monitor when your services are going down and make sure that you understand why is it a scaling action or

    is there actually a bug in your system that you need to consider getting fixed quickly

    so make sure uh you know any Behavior like that is noted and communicated to

    your devs in the right way

    all right number 10 Dev prod parody keep development staging and production as

    similar as possible um I had already told you my story about

    how you know we were developing an app and delivering it and they were using completely different tools to deploy

    than what we were internally um in fact it’s just you know sets you up

    for some problems that you could avoid it would be wonderful to be able to uh tell you know your client you know if

    you use this particular version Be watchful for such and such and be prepared for such and such

    um you know being able to keep all of these environments as similar as possible is a very good idea and

    containers fit right in here too they allow us to be able to run you know

    pretty much the same application in development as in staging as in production the tempting thing here is to

    use different backing services so that’s something to be aware of as

    well um not a good idea to use a different database

    or a different broker you know there’s all kinds of things that you don’t anticipate when you start switching

    those kinds of things around and always good to catch problems earlier rather

    than in production when everything is different so good idea to keep all these the same

    obviously this fits right into containers it keeps all of our you know everything around the container

    and the app the same pretty nice

    logs it has been years since I’ve had to configure logs so when I took a look at

    this one there I have a lot of unanswered questions here um so there’s a lot of experimentation I

    want to do I remember being in a situation where

    we had some containers running we had logs but we were doing stupid things like

    um you know our application inside the container was logging to the file well that file lives inside the container it

    wasn’t you know mounted anywhere it wasn’t like an external file or anything so you know you can predict what happens

    there anytime that container dies those logs are gone

    so a 12 Factor app um not even just a container but any 12

    Factor app you need to make sure that you’re handling logs appropriately

    um it should the app itself should not be concerned with writing or managing log

    files it’s one of the stipulations of the principle each should write to the event stream to

    standard out and uh if you want to handle those logs

    in some way if you want to ship those logs somewhere that’s up to you to do that you might want to use something

    external to do that you can use you know log routers like

    fluent D huge good idea for that you can also you know take all of these

    logs send them out to something like Splunk so that you can start doing some analysis things like that but just you

    know be aware by default Docker you know it will log to standard out and standard

    error but if you’ve got applications inside the container doing their own thing make sure that you are aware of

    that oh another thing that happened to us and obviously we figured this out before it went to production but you

    know um a lot of those logs were there was a lot of logs and when you have a

    little container and you might deploy several containers on a single VM you’re going to quickly run out of space so we

    learned uh quickly that we need to make sure that our logs don’t live within the container

    and the last one here admin processes run admin management tasks as one-off

    processes the examples of these are running database migrations or running a

    console um to kind of you know maybe inspect the

    app with real data for example um and or any other one-time scripts

    that you might need to run occasionally all of these things need to be included

    with the app so those one-time scripts need to be committed into the repo just like everything else when you run any of

    these processes they should be with the same environment the same dependencies everything else around it should be the

    same as the app itself so with containers this is nice because

    you can actually just maybe spin up another container and then be able to do these one-off processes uh that way you

    know you have the same release you’ve got scripts that are compatible

    um this is you know a good idea with containers um

    kubernetes has operators um this is another way that you might be

    able to do stuff like repair tasks or maybe a database schema setup uh things

    like that um you might be able to use you know other Frameworks too to help with this

    so that’s it um you know this overview of 12 factors you know are is this good should are

    they applicable container two containers I think absolutely uh it seems like it fits very well with containerization a

    lot of the same goals and outcomes um so yeah

    thanks very much um if you have any Docker files lying around I guess your task now is to go

    and walk through them and see if your images and your containers are actually following these guidelines and what I

    would love to hear from you is if you find any reasons or exceptions to the

    rule why you would not follow a principle the way it stated in your

    application how you have it built and packaged

    thank you very much

    well due to time I’m going to allow for one pressing question for Melissa Melissa can you hear us okay

    yes okay great one question anybody have one question that you can’t go to sleep tonight unless you get the answer

    okay well I know Melissa’s exceptionally he’s up you got one question okay okay all right let’s not go to

    exchange go ahead one question um yeah so uh uh regarding the um the

    factor about a singular code base uh there is a concept of model repos um now that you’re confused with

    monoliths right and they’re pros and cons the trade-offs to having a mono repo versus having my multiple repos

    um I think of cicd and having like pipelines that are um reusable across multiple applications

    or Services um I’m curious what your thoughts are there in terms of like violating that rule for like a month repo

    I get into this argument frequently about Mono repos

    um I I don’t like them but I mean it’s mainly for personal reasons but there’s there’s some reasons I don’t like them

    is um for one when you have a code base set up like that it kind of implies one of the

    big advantages is if it’s all written in the same language um yeah that’s great uh that way you can

    bring it all in you can bring it all into your IDE if you make a change somewhere you can address you know any

    complications or considerations you know anywhere else in that huge code base but

    I feel like if you’re already there doing that maybe they’re not logically separated enough anyway I mean if you

    have enough code that’s being shared between those Services maybe there’s some other issues in the structure that

    need to be dealt with if they can’t be cleanly separated out into another repo

    there might be some other things to worry about um ideally I would like to be able to

    see like different teams be able to handle different components and have

    their own release cycle their own pipelines that they’re concerned with maybe they can reuse templates of

    pipelines but maybe their release cycle is different than other components in the system

    um also you know every time you check that code base out I don’t know you know you just gotta

    hack away at it to figure out how to only pull in what you need and not build the entire thing every time right and

    then also tracking your releases making sure that you know if every commit actually triggers a build does that mean

    that everything needs to be re-released or just the code that was changed in the

    component that was changed so yeah lots of issues to think about

    thank you so much Melissa really appreciate it