The document discusses the twelve-factor application pattern for developing cloud-native applications and how the Spring Framework supports this methodology. It covers the twelve factors which include having a single codebase, explicit and isolated dependencies, storing configuration in the environment, treating backing services as attached resources, separating build and run stages, making applications stateless, binding to ports, scaling out via the process model, maximizing robustness through fast startup and graceful shutdown, keeping development, staging and production environments the same, treating logs as event streams, and running admin/management tasks as one-off processes. The Spring Framework provides features that help implement many of these twelve factors for building cloud-native applications.

1. Twelve-Factor application pattern
with Spring Framework
By Dinkar Thakur
HPU Shimla
23/05/16RICSIT-2016 1

2.  Change in underlying architecture
 From Core to Distributed structure
 Move from monoliths to microservices
 Need for agility in the code
 Some guidelines to how to creates app for new world
 Twelve Factors - Heroku
 Framework to readily support Cloud app
development – Spring
23/05/16RICSIT-2016 2
Introduction

3. Developed specifically for cloud platforms
Highly Scalable
Mobile?
Agile
Run in containers?
Microservices?
Designed for failure
23/05/16RICSIT-2016 3
Cloud Native Application

4. • One Codebase tracked in VCS – Git, SVN.
• Multiple deployments – Different stages dev, testing,
production.
• Multiple instances of same app.
• Are there any alternatives:
1 Codebase = *Apps
* Codebase = 1 App
• Spring provide separation of configuration and fat
jars 23/05/16RICSIT-2016 4
Factor 1 -- Code Base
One code base, many deployments

5. • Application need libraries, can’t run in isolation
• Some are provided by language runtine
• Should not depend underlying platform
• Repeatable deployment – different platform different
machines. So Explicit dependencies
• Spring uses maven, gradle to manage dependencies
• Fat jar contain all the dependencies bundled in one
app ready to run.
23/05/16RICSIT-2016 5
Factor 2 -- Dependencies
Explicit and Isolated Dependencies

6. • Anything that’s likely to change between deploys
Resource handlers to database, Credentials
• Should not be present in Code, properties files, build
or app server – why?
• Store it in Environment !!
• Spring Cloud Config : Externalization of configuration
• Can be overridden by environment
• Need not to restart application
23/05/16RICSIT-2016 6
Factor 3 – Configuration
Configuration in the environment

7. • Backing Service are consumed over the URL.
• Access service through a URL, never locally
• Application not dependent on these to boot-up and
run
• Should not be tied to one service, but can work with
alternatives
• Spring have wrappers for most of the known services.
From messaging, caching, database, logging, even cloud
platform
23/05/16RICSIT-2016 7
Factor 4 – Backing services
Services as Attached Resource

8. • Build transform code to libraries, along with
dependencies – handled by developers
• Release combine libraries and configuration, releases
should be versioned
• Run make app available on server. Should be fast an
light – handled by platform like Dockers
• Spring fat jar come very handy. Build phase add all the
dependencies.
• Create standalone app just need to run. Spring config
provide the configuration
23/05/16RICSIT-2016 8
Factor 5 – Build, Release and Run
Separation between build and run stages

9. • Design for failure
• Many instance of same applications
• No data shared between request be kept in app
• Any instance can accept the request
• Every service should act as different process
• Spring help in create microservices which natively
support HTTP a stateless protocol
• Intermediate data can be stores in Redis or
Memcache. Ideally communication should be queued
23/05/16RICSIT-2016 9
Factor 6 – Processes*
Application as stateless share nothing

10. • Apps are deployed in containers
• There are multiple containers per host
• Platform handle port assignment and mapping.
• Multiple instance of application can be run on same
URL and different port.
• Spring cloud discovery act as registry server.
• All apps get registered in discovery server and
accessed by app-name
• Load balancing handled at client side.
23/05/16RICSIT-2016 10
Factor 7 – Port binding
Export services via port

11.  Individual instances are treated as individual process
 Application should handle one type of work.
 This model help is scaling out as we need to add more
instances
 Again each micro service
shared by URL can act as a
process.
23/05/16RICSIT-2016 11
Factor 8 – Concurrency
Scale out via Process model

12. • Robustness by recovering from failures
• We cannot scale, deploy, release recover fast if we
cannot start fast – that’s why we need containers and
dockers
• We cannot start fast if there is no graceful shutdown
• “Where my db connection goes, why there is locking, what was
last state of data.”
• So concept of external config, queue system and
self contained application is evident here.
• App will start fast, config is provided from outside
23/05/16RICSIT-2016 12
Factor -9 – Disposability
Maximum robustness, Fast startup, Graceful Shutdown

13. • Application are designed for continuous deployment
• Environment parity enable speed
• Less last time bugs while release on production
• At-least no change in the code.
• With installation of backing services like db, message
queue easing up, environments are nearly same.
• Spring provides wrapper for many services and hence
no code change required.
• Config is externalized making changes in config easy
23/05/16RICSIT-2016 13
Factor - 10 – Dev/Prod Parity
Keep dev, staging and production environment same

14. • Treat logs as event streams as they are generated as long
as application is running
• Log to stdout and stderr
• Routing and storing logs not part of the application
• Parsing of logs an important part to know the state of the
applications.
• Spring cloud provides component for the logging and
tracing of the events.
• Can be easily integrated with fluentd, or logstash to filler
the logs and analyze them.
23/05/16RICSIT-2016 14
Factor -11 – Logs
Logs as event stream

15. • Admin/Management processes run against a release
• Environment should be identical to release
• Use same codebase and config
• Should be shipped with code to avoid sync issues.
• Spring provides actuator which exposes management
endpoints
• Help in doing administration and management tasks
• Shipped with in the application
23/05/16RICSIT-2016 15
Factor – 12 – Admin processes
Running management task process

16. • Need to change the way we develop application
• To make a cloud native app this methodology can be
followed
• These guidelines are not forced, we can create
application for cloud without adhering to these
• They are there to make life easy
23/05/16RICSIT-2016 16
Conclusion

17. Thank you
Questions Any?
Mail me at thakur.dinkar@gmail.com
Tweet at @dinkarthakur
23/05/16RICSIT-2016 17