EMC World 2016 12 Factor Apps FTW

1© Copyright 2016 EMC Corporation. All rights reserved. 1© Copyright 2016 EMC Corporation. All rights reserved.

12-FACTOR APP FTW !!! (FOR THE WIN)

2© Copyright 2016 EMC Corporation. All rights reserved.

Our Asks…..• Don’t be quiet or shy !!• Sales Pitch Free Zone! • Tweet it out Questions! #EMCWorld

@vTexan @bverkley


Product Companies Are Creating “Smart Devices”EVERY INDUSTRY IS BEING DIGITALLY TRANSFORMED


APPS ARE GOING FROM MONOLITHIC…

To Cloud Native

http://catina.co


WHAT MAKES CLOUD NATIVE APPS DIFFERENT?

• Operate At Much Greater Scale On Much More Data• Tend To Be Built On Microservices• Use New Development Methods• As Well As New Deployment, Organizational and

Management Models• With Open Source Components At All Levels

Different Promises:


CLOUD NATIVE APPS INFRASTRUCTURE NEEDS

• Programmability (“Infrastructure As Code”)• Elasticity (Which Demands A Scale-Out Architecture)• Economics (Steers Towards Commodity + Software-

based)• Strong Instrumentation And Telemetry Of

Infrastructure Layer


DevOps is an operations model where software

development principles are applied to operations


OKAY, I TOTALLY GET IT ! WHAT'S THE BLUEPRINT?


• It’s a methodology for developing what is known as “Cloud Native Apps”• It helps minimize divergence between development

and production• It enables continuous deployment to maximize agility• It can be applied to any app written in any

programming language

WHAT IS 12-FACTOR


FACTOR I - CODEBASE

• Not just for developers anymore• Central repository for all

infrastructure Information– Chef, Ansible, Puppet, Jenkins etc

• Ops: “Dear Ops – can you deploy this code for me….is it in GitHub? If not, it doesn’t exist !.”

One codebase tracked in revision control, many deploys


FACTOR II - DEPENDENCIESExplicitly declare and isolate dependencies

• Never make environment assumptions– Enable automated builds of fresh environments

• Explicitly declare in code– Track in your code repository

• Ops: “Dear Ops, my app broke, can you update a dependency for me?” - “No. Declare it and rebuild.”


FACTOR III - CONFIG

• Config is everything that is likely to vary between deploys ! (Staging, Production, Dev etc)• Include access credentials, logging config• Not buried into the code (with passwords etc)

• Ops “Hey, can you update the app to reflect this new password….ah nope….store your config somewhere other than the code !”

Store config in the environment


FACTOR IV - BACKING SERVICESTreat backing services as attached resources

• URLs allow freedom. Enjoy your freedom. – Freedom of mobility– Freedom of scalability– Freedom of language– Freedom of provider

• Ops: Hardware changes won’t necessitate application changes. Delightful.


FACTOR V - BUILD, RELEASE, RUN

• Build = Codebase being built• Release = Build + Config• Run = deploy to the wild

• Ops: Can you edit this one thing for me…NO ! We don’t do snowflakes…trust the tools

Strictly separate build and run stages


FACTOR VI - PROCESSExecute the app as one or more stateless processes

• When bad stuff happens to good code– Failure is not an option… it is a certainty– Outages are not a choice… how you handle them is

• Be as stateless as possible, so failures are easy to recover from

• Ops: Do you enjoy waking up at 2am to restart a process ?


FACTOR VII - PORT BINDING

• The app should be completely self contained. Don’t assume your app is the only thing on that server• Resources needed to listen (IP Address, Ports) should

be received from the environment (env)• Multi-level systems (Java in Tomcat, PHP in Apache)

violate this principle.• Ops: Ahhhh, my app isn’t working anymore, is

someone else using 8080? Is Python 3.5 compatible with Apache 2.2?

Export services via port binding


FACTOR VIII - CONCURRENCYScale out via the process model• One task = one process• To scale a task up, add processes to do more at once• To improve concurrency, look to eliminate locking &

increase caching (ie table database locking etc)• Reduce whack-a-mole scale bottlenecks• Ops: Infrastructure should be pools of resources and

the applications should allocated them to the tasks based on demand


FACTOR IX - DISPOSABILITYMaximize robustness with fast startup and graceful shutdown

• Startup times should be low• No loss of state for users if process is lost• If it can’t heal itself, kill it and bring up another one.

• Ops: “Can you reboot this app….no….kill it and respawn it”


FACTOR X - DEV/PROD PARITYKeep development, staging, and production as similar as possible

• “Worked in Dev….no idea why it’s not in Prod” • Do you want to troubleshoot code or environment?• Increase deployment confidence• Performance can be different !

• Ops: Reduce the blame game, and the downtime


FACTOR XI - LOGS

• Log absolutely everything !• Searching is cheap !!• Logs should be treated as first class citizens !

• Ops: Logs are the canary in the coal mine! It helps you figure out where things went wrong ! “If I had a $1 for each time my boss said “did you check the logs” when I ask him for troubleshooting help!”

Treat logs as event streams


FACTOR XII - ADMIN PROCESSESRun admin/management tasks as one-off processes

• No one-off custom scripts• Everything done live is from the codebase and logs

to the official logging system• (eg, never update the database from the db cli)

• Ops: “Dear Ops, can you run this for me?” - “No, I like you too much to be that mean.”


• 12 Factor is a mindset, and set of tools/process• DevOps is a cultural shift combining Operations

teams and Development Teams (embrace it!)• DevOps is also the most overused term since Cloud • Keep in mind, this is session is a blueprint!

SUMMARY


• Brian Verkley - @bverkley• Tommy Trogden - @vTexan

WANT TO REACH OUT TO US?

24© Copyright 2016 EMC Corporation. All rights reserved. 24© Copyright 2016 EMC Corporation. All rights reserved.

EMC World 2016 12 Factor Apps FTW

Education