Evolving to Cloud-Native - Anand Rao

1. © Copyright 2018 Pivotal Software, Inc. All rights Reserved. Version 1.0
Evolving to the Cloud
Anand Rao
Advisory Platform Architect
Clue2solve.io
@honnuanand

2. The Journey ( or
Journies ?)
● To the Cloud
● To Microservices
● Modular Monoliths
● Containers ? now what is that … ?
● Serverless ..“ I don’t want any Servers …cough ??”
● Hybrid ...Poly Cloud

3. Navigation
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

4. Beware
● Resume Driven Development
● Fear driven Development :)
Vs
● Outcome driven Development

5. Caution
● There will be pitfalls
● The need to pivot quickly being Agile and
nimble
● Learn from the experiences of others , self
experiment may be costly

6. Cloud Native ?
● Applications designed to take advantage of
cloud computing.
● Fundamentally about how we create and
deploy applications.

7. What do I get by
running my Apps
in the Cloud ?
● Scale up. Scale down. On demand.
● Limitless compute.( Really ? … Fees )

8. Cloud Native
● Cloud native isn’t just an architectural pattern.
● Instead , it can be defined as a Combination of
practices, techniques, technologies.
○ Agile Development
○ Continuous delivery
○ Automation
○ Containers
○ Microservices / Functions
○ Changes our culture.
○ DevOps concept

9. Infrastructure
Shift
Where were we ?
● Homegrown Servers
● Handcrafted
● Treated with so much care .. like Pets
● Always attended to it , day and night ..
● Never had enough .. Constrained resources
● Expensive

10. App Servers
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

11. Effect of App
Servers
Som times unintended
● Shared resources
● One application’s bug could take down
multiple apps
● 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 ?

12. 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

13. The Ops
● 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 ?

14. Server Evolution
● 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

15. The Cloud “as a
Service”
● Heroku
● AWS
● Google App Engine
● Cloud Foundry
● Azure
What do all these have in Common ? “I can run my
apps on their servers !!”

16. Shared
self-managed
Servers Vs the
Cloud
Shared Servers became a huge liability ,
we need to “Treat them as Cattle not Pets “

17. The Abstractions
Game Changers
● Containers
● PAAS
Now you can
● Package the app up with everything it
needs
● Move *that* to a different environment

18. 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

19. The Value Line
Moves the Value line

20. 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

21. Speed and
Disruption
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

22. The 12 Factors Characteristics Shared by
Successful Apps
Originated at Heroku, Adopted by
many other industry leaders

23. The 12 Factors
I. Codebase
One codebase tracked in revision control, many deploys
II. Dependencies
Explicitly declare and isolate dependencies
III. Config
Store config in the environment
IV. Backing services
Treat backing services as attached resources
V. Build, release, run
Strictly separate build and run stages

24. The 12 Factors
VI. Processes
Execute the app as one or more stateless processes
VII. Port binding
Export services via port binding
VIII. Concurrency
Scale out via the process model
IX. Disposability
Maximize robustness with fast startup and graceful shutdown
X. Dev/prod parity
Keep development, staging, and production as similar as possible

25. The 12 Factors
XI. Logs
Treat logs as event streams
XII. Admin processes
Run admin/management tasks as one-off processes

26. Legacy Apps
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
http://cloud.rohitkelapure.com/2017/10/pushing
-zero-factor-apps-to-cloud.html

27. The key factors to
focus
Some factors can be Challenging !
● Explicitly define your dependencies
● Configuration must be separate from the
code
● 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

28. Maximize the
Cloud Advantage
Example : Long startup time hurts elastic
scaling & self healing

29. Beyond the 12
Factor Apps
Beyond the Twelve-Factor App
https://content.pivotal.io/blog/beyond-the-twelve
-factor-app
● Legacy applications will fall short
● Opportunistically refactor
● Building Greenfield ? Go Cloud Native

30. Microservices
● 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
deploying everything
○ Scaling means scaling the entire application
● Modularity breaks over time and leads to longer
time to functionality and frustration

31. Microservices
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
results
● 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

32. They are all tools
Use the right Tool for the Job
Please Microservice Responsibly.
https://content.pivotal.io/blog/should-that-be-ami
croservice-keep-these-six-factors-in-mind

33. Do the right
things “If you can't build a monolith, what makes you think
microservices are the answer?”
–Simon Brown
http://www.codingthearchitecture.com/2014/07/06/
distributed_big_balls_of_mud.html

34. Serverless
Functions “as a Service” !
What do I need to do ? Rewrite my
code ?
Think “Abstractions” !

35. The right
abstraction for
the workloads

36. Use the highest
abstraction
possible
Your strategic goal: Push as many workloads as technically
feasible to the top of the platform hierarchy

37. Functions ● Focus on business problems, not plumbing
problems
● 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

38. The Journey to
the Cloud
Where do I start ?
● Access your inventory
● Focus on the outcomes
● Tools to Access apps
○ Extract Tech characteristics
■ Stack
■ Version
■ Users
■ Load
■ Speed ( and expected )
■ Dependencies
■ Integrations
■ Data Access
■ CI/CD ?
■ Test coverage
■ Refactoring Effort

39. The Journey to
the Cloud
● Look for certain Red Flags
○ Vendor dependencies
○ Writing to and reading from the file
system
○ Long Startup or shutdown times
○ Non HTTP protocols
○ Hard coded configs
○ Container based shared state
○ Distributed transactions

40. The Journey to
the Cloud
Scorecard based on the assessment of the
state and effort for refactoring
● Remember is a Sliding Scale

41. The Journey to
the Cloud
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
analysis
● Focus on patterns to allow your to have better
guess on the effort
● Business value articulation

42. End state Need Cloud Native or Being in the cloud
● Handling of legacy app
refactoring
● Forklift app into the cloud ?

43. The Process
● 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

44. Your North Star
Keep the Stakeholders Happy which intern
means , you are happy !