Download as PDF, PPTX
Uploaded byVMware Tanzu
Evolving to Cloud-Native - Anand Rao
This document discusses the journey to cloud computing and cloud native applications. It covers evolving from on-premise servers and monolithic applications to distributed architectures like microservices, containers, and serverless functions. The key steps are assessing applications to determine readiness, prioritizing workloads based on business value, and establishing centers of excellence to help teams migrate applications incrementally through pilots while learning from others' experiences. The goal is to maximize cloud advantages like elastic scaling and continuous delivery while navigating technical challenges along the path to cloud native.
More Related Content
Similar to Evolving to Cloud-Native - Anand Rao
Evolving to Cloud-Native - Anand Rao
- 1. © Copyright 2018Pivotal 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 myMagic 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 DrivenDevelopment ● Fear driven Development :) Vs ● Outcome driven Development
- 5. Caution ● There willbe 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 Iget by running my Apps in the Cloud ? ● Scale up. Scale down. On demand. ● Limitless compute.( Really ? … Fees )
- 8. Cloud Native ● Cloudnative 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 Expensiveservers 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 Somtimes 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 ● Movecode 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 ● IntelChips 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 “asa 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 SharedServers 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 Movesthe 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 needfor 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 FactorsCharacteristics 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 Appsmay 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 factorsto 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 FactorApps 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 limityour 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 definesa 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 alltools 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 aService” ! What do I need to do ? Rewrite my code ? Think “Abstractions” !
- 35. The right abstraction for theworkloads
- 36. Use the highest abstraction possible Yourstrategic goal: Push as many workloads as technically feasible to the top of the platform hierarchy
- 37. Functions ● Focuson 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 theCloud 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 theCloud ● 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 theCloud Scorecard based on the assessment of the state and effort for refactoring ● Remember is a Sliding Scale
- 41. The Journey to theCloud 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 NeedCloud Native or Being in the cloud ● Handling of legacy app refactoring ● Forklift app into the cloud ?
- 43. The Process ● PilotApps ● 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 Keepthe Stakeholders Happy which intern means , you are happy !