The overwhelming growth of technologies in the Cloud Native foundation overtook our toolbox and completely changed (well, really enhanced) the Developer Experience.
In this talk, I will try to provide my personal journey from the "Operator to Developer's chair" and the practices which helped me along my journey as a Cloud-Native Dev ;)
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
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?
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 “--------”
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
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
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