Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Evolving to Cloud-Native - Anand Rao

274 views

Published on

Evolving to Cloud-Native - Anand Rao

Published in: Software
  • Be the first to comment

Evolving to Cloud-Native - Anand Rao

  1. 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. 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. 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. 4. Beware ● Resume Driven Development ● Fear driven Development :) Vs ● Outcome driven Development
  5. 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. 6. Cloud Native ? ● Applications designed to take advantage of cloud computing. ● Fundamentally about how we create and deploy applications.
  7. 7. What do I get by running my Apps in the Cloud ? ● Scale up. Scale down. On demand. ● Limitless compute.( Really ? … Fees )
  8. 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. 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. 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. 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. 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. 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. 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. 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. 16. Shared self-managed Servers Vs the Cloud Shared Servers became a huge liability , we need to “Treat them as Cattle not Pets “
  17. 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. 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. 19. The Value Line Moves the Value line
  20. 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. 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. 22. The 12 Factors Characteristics Shared by Successful Apps Originated at Heroku, Adopted by many other industry leaders
  23. 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. 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. 25. The 12 Factors XI. Logs Treat logs as event streams XII. Admin processes Run admin/management tasks as one-off processes
  26. 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. 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. 28. Maximize the Cloud Advantage Example : Long startup time hurts elastic scaling & self healing
  29. 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. 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. 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. 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. 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. 34. Serverless Functions “as a Service” ! What do I need to do ? Rewrite my code ? Think “Abstractions” !
  35. 35. The right abstraction for the workloads
  36. 36. Use the highest abstraction possible Your strategic goal: Push as many workloads as technically feasible to the top of the platform hierarchy
  37. 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. 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. 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. 40. The Journey to the Cloud Scorecard based on the assessment of the state and effort for refactoring ● Remember is a Sliding Scale
  41. 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. 42. End state Need Cloud Native or Being in the cloud ● Handling of legacy app refactoring ● Forklift app into the cloud ?
  43. 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. 44. Your North Star Keep the Stakeholders Happy which intern means , you are happy !

×