DevOpsDays Tel Aviv DEC 2022 | Building A Cloud-Native Platform Brick by Brick.pdf
0 likes24 views
Haggai Philip Zagury discusses building a cloud-native platform using open-source technologies and emphasizes the importance of understanding system architectures, operational costs, and the complexities of software development. The document outlines the principles of the 12-factor app model, which provides guidelines for creating scalable and efficient cloud applications while considering aspects like backing services, logging, and environment similarity. It also highlights the integration of CI/CD processes and the significance of treating logs as event streams within the cloud-native landscape.
![Admin processes
● Database migration
[create schema, update schema]
● Backup and Restore procedures
● Cron tasks
● Jobs (maintenance job)](https://image.slidesharecdn.com/devopsdaystelavivdec2022buildingacloud-nativeplatformbrickbybrick-221216113304-ebadfc4b/85/DevOpsDays-Tel-Aviv-DEC-2022-Building-A-Cloud-Native-Platform-Brick-by-Brick-pdf-36-320.jpg)
![Admin processes
● Database migration
[create schema, update schema]
● Backup and Restore procedures
● Cron tasks
● Jobs (maintenance job)](https://image.slidesharecdn.com/devopsdaystelavivdec2022buildingacloud-nativeplatformbrickbybrick-221216113304-ebadfc4b/85/DevOpsDays-Tel-Aviv-DEC-2022-Building-A-Cloud-Native-Platform-Brick-by-Brick-pdf-37-320.jpg)
DevOpsDays Tel Aviv DEC 2022 | Building A Cloud-Native Platform Brick by Brick.pdf
- 1. Haggai Philip Zagury DevOps BP, GL & TL Building A Cloud-Native platform Brick by Brick
- 2. Open thinking and open techniques ideology - driven by Open Source technologies My Solution driven approach is based on hands-on and deep understanding of Operating Systems, applications stacks software languages and frameworks, Networking, Cloud and Cloud Native solutions. Haggai Philip Zagury DevOps BP, GL & TL
- 3. Tikal is a leading Israeli hands-on tech consultancy, scaling R&D teams with cutting-edge technologies. Our experts join development teams across the tech industry and help them make a tech Impact on their product. Tikal - Home of Tech Experts
- 4. Building an application platform brick by brick The evolution of Software Development
- 5. Software is still “eating the world” - Trends like microservices, SaaS sprawl, and cloud-everything create a chaotic ecosystem for engineers. - Every company uses different subsets of these tools and faces different challenges. - Your whole stack is getting more complex; onboarding and collaboration are becoming more difficult.
- 6. Why? Operational Overhead | ROI / TCO ● The TCO & ROI of the entire SDLC - is defined by its operational cost ● More CapEx - Capital (Capability) exp ● Less OpEx - Operational exp
- 7. So, how do we build a cloud native application?
- 8. Beyond the obvious…… Git init.
- 9. Choose an Architecture - Monolith (2-tier to n-tier etc..) - SOA - Event Driven
- 10. You want to be following 2 things: Regardless to your SW architecture style - A few more later ;) Cloud Native Computing Foundation 12factor app
- 14. ● If in 2005 we were looking for the “build script” as part of the code ● Configuration as part of the code ● Json | Yaml | Toml || *ml ● Declarative ! ● They all agree on kubernetes ;) ● In some cases VM’s is still an option … Config
- 15. Backing Services ● Make sure how and where you store your data ● Treat backend services as Dependencies / Third Parties ○ It’s only purpose is to Serve your app ○ Your service should be able to run with / without it
- 16. Backing Services ● Make sure how and where you store your data ● Treat backend services as Dependencies / Third Parties ○ It’s only purpose is to Serve your app ○ Your service should be able to run with / without it. ● There is no option of keeping anything local*
- 17. Backing Services ● An ecosystem of solutions for storage which is cloud native meaning your application can port from one cloud to another
- 18. Backing Services ● An ecosystem of solutions for storage which is cloud native meaning your application can port from one cloud to another ● CERTAINLY doable ❗ There will be sweat INvolved :)
- 19. Build release Run ● CI/CD is part of the application ! ● All cloud provider offers them ○ Github ○ Gitlab ○ Circle CI ○ Our very own “--------”
- 20. Processes ● Keep it simple ● 1 process running in your app
- 21. Processes ● Keep it simple ● 1 process running in your app ● This ones make you START thinking about the architecture style you want / need Monolithic Microservices
- 22. Processes ● Keep it simple ● 1 process running in your app ● Take kubernetes architecture as an example ● CnCf is baked on projects running containerized applications on multiple clouds
- 23. CloudNative Landscape 12 factor principles
- 24. Port Binding ● Single process bound to port
- 25. Port Binding ● Single process bound to port ● Docker - container networking principles ○ We had that in docker-compose ● Liveness and Readiness ● Rolling update
- 26. Concurrency ● This patten encourages you to be stateless don’t save anything locally ● Calculations may and should be done outside the service whatever cache put in to backing service ● Now -> Scaling out is built-in
- 27. Concurrency ● There is a temp dir you can use. ● There are stateful applications - how do we deal with those ? ○ A cluster is a cluster ○ Shared state == highly available data
- 28. Disposability ● We can start & stop services at any given time ● Service decommissioning
- 29. Disposability ● We can start & stop services at any given time ● Service decommissioning ● Replica Set controller
- 30. Disposability ● We can start & stop services at any given time ● Service decommissioning ● Replica Set controller ● Kubernetes Deployment controller
- 31. Dev/prod parity (Environment similarity) ● Developer environment and runtime environment must be similar ○ Very difficult to be identical cost wise
- 32. Dev/prod parity (Environment similarity) ● Developer environment and runtime environment must be similar ● Eco-system of solutions for the entire lifecycle
- 33. Logs ● Treat logs as event streams ● Logging Drivers ● Stdout | Filters and Aggregators
- 34. Logs ● Treat logs as event streams ● Logging Drivers ● Stdout | Filters and Aggregators ● You will find ○ all cncf project follow this principles ○ A well known project - fluentd
- 35. Logs ● Treat logs as event streams ● Logging Drivers ● Stdout | Filters and Aggregators ● You will find ○ all cncf project follow this principles ○ A well known project - fluentd
- 36. Admin processes ● Database migration [create schema, update schema] ● Backup and Restore procedures ● Cron tasks ● Jobs (maintenance job)
- 37. Admin processes ● Database migration [create schema, update schema] ● Backup and Restore procedures ● Cron tasks ● Jobs (maintenance job)
- 38. CloudNative Landscape 12 factor principles
- 39. 13. API First ● OpenAPI ● RAML
- 40. 14. Telemetry ● Monitor Software Performance - a.k.a APM ● We aren’t influences by A single machine ○ It’s a cluster
- 41. 14. Telemetry ● Monitor Software Performance - a.k.a APM ● Understand how your application behaves ● Scaling decisions are the cloud-native part of your app when you follow 12factor app principles
- 42. 15. Authentication & Authorization (Security) ● Workload Identity -> assuming a cloud role
- 43. 15. Authentication & Authorization (Security) • Workload Identity -> assuming a cloud role • IRSA - IAM Role Service Account
- 44. How does this look like in the cloud native world ? https://github.com/vikasg11/fifteen-factor-app https://github.com/cjudd/15-factor-app-workshop
- 45. CloudNative Landscape 12 factor principles
- 46. Creates References Resources mgt Network / exposition Configuration Storage IAM Pod generator Decouples the application from the infrastructure
- 47. ● Custom Resource Definition ● The “Things” you wish to operate the cloud-native way. The cloud native way is - CRD’s
- 48. ● Custom Resource Definition ● The “Things” you wish to operate the cloud-native way. The cloud native way is - CRD’s
- 50. Thank you ! Haggai Philip Zagury DevOps BP, GL & TL