The Journey ( or
● To the Cloud
● To Microservices
● Modular Monoliths
● Containers ? now what is that … ?
● Serverless ..“ I don’t want any Servers …cough ??”
● Hybrid ...Poly Cloud
Where is my Magic Wand ?
● Make Sense of all the above
○ What do I need ?
○ What fits my needs , solve my problems
and get me my Outcomes ?
● Real Engineering issues to overcome
● People and Culture
● Resume Driven Development
● Fear driven Development :)
● Outcome driven Development
● There will be pitfalls
● The need to pivot quickly being Agile and
● Learn from the experiences of others , self
experiment may be costly
Cloud Native ?
● Applications designed to take advantage of
● Fundamentally about how we create and
What do I get by
running my Apps
in the Cloud ?
● Scale up. Scale down. On demand.
● Limitless compute.( Really ? … Fees )
● Cloud native isn’t just an architectural pattern.
● Instead , it can be defined as a Combination of
practices, techniques, technologies.
○ Agile Development
○ Continuous delivery
○ Microservices / Functions
○ Changes our culture.
○ DevOps concept
Where were we ?
● Homegrown Servers
● Treated with so much care .. like Pets
● Always attended to it , day and night ..
● Never had enough .. Constrained resources
The Expensive servers brought the need for Return on
Investment on the Servers that lead to the need to
pack many apps on the same server
Effect of App
Som times unintended
● Shared resources
● One application’s bug could take down
● Coordinating changes hurts
○ “Your app can’t get this feature until all
other apps are ready
● Code deployment Freezes
● Longer Test Cycles
● Fear potential failures and outages slows
down the delivery of software
Is this all worth the Pain ?
Don’t Change it ,
Don’t Break it ..
“Fear is the path to the dark side. Fear leads to anger.
Anger leads to hate. Hate leads to suffering.” -Yoda
● Move code from one server to another
● Worked in dev…but not test.
○ Are the Environments the same ?
○ What is the order of the patches applied ?
● Intel Chips Take over the market
● Everything is relatively cheaper
● I now have no limit on my server resources
● Hardware costs dip below People Costs
● Servers became a commodity
The Cloud “as a
● Google App Engine
● Cloud Foundry
What do all these have in Common ? “I can run my
apps on their servers !!”
Servers Vs the
Shared Servers became a huge liability ,
we need to “Treat them as Cattle not Pets “
Now you can
● Package the app up with everything it
● Move *that* to a different environment
It Works ● Works in Dev means , it will work in prod,
○ The environments are similar
○ Deployment process is similar
○ Isolated runtimes allows for rapid changes in
apps and dependencies
The big win - it Works
Positive Effects ● Changes the development process
● Constant changes to Apps
● Focussed experiments. A/B Testing
● Rapid response to business changes
● Deliver in days not Months
Face need for Speed and face disruption
● No Industry is immune to disruption
○ Amazon ? Google ? What industry do
they cover ?
● Every business is driven by Technology ,
every company is a Technology company
The 12 Factors Characteristics Shared by
Originated at Heroku, Adopted by
many other industry leaders
The 12 Factors
One codebase tracked in revision control, many deploys
Explicitly declare and isolate dependencies
Store config in the environment
IV. Backing services
Treat backing services as attached resources
V. Build, release, run
Strictly separate build and run stages
The 12 Factors
Execute the app as one or more stateless processes
VII. Port binding
Export services via port binding
Scale out via the process model
Maximize robustness with fast startup and graceful shutdown
X. Dev/prod parity
Keep development, staging, and production as similar as possible
The 12 Factors
Treat logs as event streams
XII. Admin processes
Run admin/management tasks as one-off processes
Legacy Apps may not comply to many of the
12 factors , or sometimes none. So is it 12
factor bust ?
Pushing Zero Factor Apps to Cloud Foundry
The key factors to
Some factors can be Challenging !
● Explicitly define your dependencies
● Configuration must be separate from the
● Stateless - share nothing
● Start up fast, shutdown gracefully
○ Impact on health checks
● Dev/Prod parity
12 Factor is a good Goal, Not a must. You will
need to make the right choices
Example : Long startup time hurts elastic
scaling & self healing
Beyond the 12
Beyond the Twelve-Factor App
● Legacy applications will fall short
● Opportunistically refactor
● Building Greenfield ? Go Cloud Native
● Monoliths limit your evolution
○ Developer productivity takes a hit
○ Hard to get your head wrapped around a
huge code base
○ Long ramp up times for new developers
○ Small change results in building and
○ Scaling means scaling the entire application
● Modularity breaks over time and leads to longer
time to functionality and frustration
So what defines a Microservice ?
● No Single Definition
● Anything that can be rewritten two weeks or less
● Suite of small, focussed services
● Do one thing, do it well
● Knit simple pieces together to get complex
● Independently deployable , scalable
● Evolve at different rates
● Right Tech for the Right Jobs
● Focus on Business Capabilities
● High Cohesion and low coupling
It is just another approach. An
architectural style. A pattern
They are all tools
Use the right Tool for the Job
Please Microservice Responsibly.
Do the right
things “If you can't build a monolith, what makes you think
microservices are the answer?”
Functions “as a Service” !
What do I need to do ? Rewrite my
Think “Abstractions” !
Use the highest
Your strategic goal: Push as many workloads as technically
feasible to the top of the platform hierarchy
Functions ● Focus on business problems, not plumbing
● Terminate the container
● A fractional cost per request
● Operational efficiencies
● Serverless ops? Is that a thing ? think Value line
● Use it for the right workload
The Journey to
Where do I start ?
● Access your inventory
● Focus on the outcomes
● Tools to Access apps
○ Extract Tech characteristics
■ Speed ( and expected )
■ Data Access
■ CI/CD ?
■ Test coverage
■ Refactoring Effort
The Journey to
● Look for certain Red Flags
○ Vendor dependencies
○ Writing to and reading from the file
○ Long Startup or shutdown times
○ Non HTTP protocols
○ Hard coded configs
○ Container based shared state
○ Distributed transactions
The Journey to
Scorecard based on the assessment of the
state and effort for refactoring
● Remember is a Sliding Scale
The Journey to
What is needed
● Application knowledge
● Clear path to end state
● Set amount of time per application
● Consider automation of analysis and reporting of
the state of the application and scoring
● T-Shirt sizing instead of too much in depth
● Focus on patterns to allow your to have better
guess on the effort
● Business value articulation
End state Need Cloud Native or Being in the cloud
● Handling of legacy app
● Forklift app into the cloud ?
● Pilot Apps
● Ask the experts
● Center of excellence to help teams get
enabled and migrate their Apps
● Clearly planned Roadmap
● App migration Grouping and dependency
● Lean migrations
Your North Star
Keep the Stakeholders Happy which intern
means , you are happy !