What can I implement from the Twelve-Factor App to a modern microservices architecture?

1. ©2023 F5
1
Welcome to Unit 1

2. ©2023 F5
2
üAttend all webinars
üComplete all hands-on labs
Use same email for all activities
Obtain Your Badge!

3. ©2023 F5
3
üJoin #microservices-march
üGet help with Microservices
March questions
üConnect with NGINX experts
nginxcommunity Slack

4. ©2023 F5
4
Agenda
1. Lecture
2. Q&A
3. Hands-On Lab with Office Hours
(only for live session – if you’re watching this on
demand, complete the lab on your own time)

5. ©2023 F5
5
JAVIER EVANS
Solutions Architect
NGINX
JASON SCHMIDT
Solutions Architect
NGINX
Meet the Speakers

6. ©2023 F5
6
The Twelve Factors

7. ©2023 F5
7
The Twelve Factors
• Proposed by Adam Wiggins of
Heroku, c2011
• How to handle "web scale"
applications
• Form the basis for most "best
practices" today
• Agnostic to language and backing
services
A set of principles that
describes a way of making
software that enables
companies to create code
that can be released
reliably, scaled quickly, and
maintained in a consistent
and predictable manner
See https://www.redhat.com/architect/12-factor-app
A Brief History

8. ©2023 F5
8
The Twelve Factors
https://12factor.net/
7. Port binding
8. Concurrency
9. Disposability
10. Dev/prod parity
11. Logs
12. Admin processes
1. Codebase
2. Dependencies
3. Config
4. Backing services
5. Build, release, run
6. Processes

9. ©2023 F5
9
The Twelve Factors: Benefits
Scalability
Resiliency
Continuous Delivery
Maintainability
Security
The 12-Factor App
manifesto is an
approach to building
and maintaining a
modern application
that ensures it is
scalable, self-
sustaining, and fit for
a cloud-based
deployment
See https://www.castsoftware.com/blog/the-12-factor-app-manifesto-assessing-your-applications

10. ©2023 F5
10
Before The Twelve Factors
The Age of Monoliths
• Developers
○ Tightly coupled applications
○ Potential to break other parts of the application easily
○ External dependencies on hardware / OS
• Operations
○ Bare metal servers
○ Scale by migration
○ Reboots easily become outages
• Release Management
○ Releases are "an event" and happen infrequently
○ Often results in unscheduled downtime
○ "Code Freezes"
• Overarching Problems
○ Importance of tribal knowledge
○ Lack of documentation / procedure
○ "Change Management Boards"
Gary Cortez https://www.artstation.com/artwork/z4XbQ

11. ©2023 F5
11
Today’s Focus: Factor 3, Config

12. ©2023 F5
12
Factor Three
Configuration
should be
strictly
separated
from code
● Remember this is guidance
● What about...
● Infrastructure as code
● Orchestration configuration
● Other deployment resources
● Spirit of Factor Three
● Honors service ownership
● Enforces code review
● Reduces external dependencies
● Reduces cognitive load

13. ©2023 F5
13
Key Supporting Factors
• Factor Five: Build, Run, Release
○ Releases are a normal part of the process
○ Not "special"
○ Find problems quickly
• Factor Nine: Disposability
○ Applications should have very little state
○ Quick starts, graceful shutdowns
• Factor Four: Backing Store
○ Maintains state
○ Enables other factors
• Overarching Factors
○ Clean contracts
○ Dependencies included in packages
○ Other teams as customers/consumers

14. ©2023 F5
14
Common Patterns
Use a configuration
schema to define
all possible
configuration
options
1
Group
infrastructure and
deployment code
with your
application
2
Use service
discovery to aid in
runtime
configuration
3

15. ©2023 F5
15
Some Types of Configuration
● Application level
○ Configured in the application
● Deployment level
○ Specified in deployment logic
○ Kubernetes configmap
● Configuration from outside source
○ Kubernetes secrets
○ Other source (consul, vault)

16. ©2023 F5
16
Today’s Configuration Lab

17. ©2023 F5
17
Notes on Today’s Lab
● No frameworks
○ Lessons here are applicable to most orchestration frameworks
○ Provides insight into what orchestration does for you
○ Removes distractions from the lab
● Service optimization
○ Ease of understanding is paramount
○ Engineering rigor is secondary
● Liberties have been taken for ease of understanding
○ This is not production code

18. ©2023 F5
18
Lab Overview

19. ©2023 F5
19
Lab Services
● Messenger
○ A simple chat API with message storage capabilities
● NGINX Open Source
○ An entrypoint to the messenger service/the wider system at large
● Consul
○ A dynamic service registry and Key Value store
● RabbitMQ
○ A popular open-source message broker that provides a way for
services to communicate asynchronously

20. ©2023 F5
20
Lab Time!
1. Click link in Resources box
2. Create Instruqt account (or log in) using the same email address from your registration
3. Complete the lab
• Estimated Time: 30-40 minutes
• Max Time: 50 minutes
• Attempts: 3
4. Problems? Use webinar chat
How to Deploy and Configure Microservices

21. ©2023 F5
21
• Progress bar:
• Progress in lab
• Time remaining
• Instruction pane is adjustable
• “Check” runs against a script
• Click “Finish” at end to
qualify for badge
Instruqt Basics

22. ©2023 F5
22
Wrap Up