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

11.
12factor App principles

12.
CloudNative Landscape

13.
12factor App principles

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

49.
https://landscape.cncf.io/

50.
Thank you !
Haggai Philip Zagury
DevOps BP, GL & TL