In this webinar we will be discussing how Orange Business Services, a global IT and communications services provider, and its large scale distributed cloud and edge network can achieve sovereignty with the hybrid EKS and Weave GitOps shared services platform. Topics we are covering: How EKSD (EKS on premise) and EKS (AWS managed Kubernetes) is used to establish common workflows that minimize operational overhead How to lower operational costs with the use of ephemeral cloud environments for development and testing How to achieve operational Sovereignty by enabling the operation of the shared services platform in on premise, air gapped and non-tethered configurations

1. Achieving Data &
Operational Sovereignty:
Managing Hybrid & Edge
EKS Deployments with
GitOps

2. Today’s Speakers
Daniel Lizio-Katzen
Head of Strategy & Partnerships
Weaveworks
Leonardo Murillo
Principal Partner Solution Architect
Weaveworks
Paul de Monchy
Principal Solution Architect
AWS

3. • Founding chair of the
CNCF technical
oversight committee
(TOC)
• Coined the term GitOps,
and created the open
source tools that make
it work
• Creator of eksctl, the
most used way to work
with AWS EKS
• Invented open source
solutions to run
Kubernetes at scale for
our own Weave Cloud
SaaS product
Team Thought Leadership
• Alexis Richardson, CEO
• Cornelia Davis, CTO
• Steve George, COO
• Global Presence:
– US East, Central, West
– Europe
– India, Japan
Notable Facts
• Founded in 2014
• Investors include:
Accel, AWS, Deutsche
Telekom, Ericsson,
Google Ventures,
Orange and Redline
• Top 10 contributor to
the CNCF
• Multiple - thousand plus
star open source
projects
Weaveworks
4

4. Weaveworks is a Leader in Open Source & Cloud Native
Kubernetes We led the creation of the flagship Kubernetes installer Kubeadm
We created EKSctl – the official EKS CLI enabling GitOps on AWS
Weave Net - the original container SDN & Firewall
LibCNI Kubernetes network model - work with CoreOS (now RH/IBM)
Weave Ignite - the container VM for secure, fast Kubernetes anywhere
Observability We made Prometheus scalable with Weave Cortex & launched 1st
Prom-aaS, powering EA’s global games. Cortex is now a CNCF project.
Weave Scope is is one of the ”top tools for monitoring Kubernetes”
providing management and monitoring and visualization for <20,000
users
CD and GitOps
tooling
CNCF Flux is a Kubernetes-native CD tool for GitOps - also Flux-Helm.
Weave Flagger for progressive delivery
JKcfg for templating, policy and actions
Kubediff - diff alerting for Kubernetes to enable GitOps
Kured - Cluster Reboot Tool
Grafanalib - GitOps dashboarding for Grafana
Integrations Weaveworks for: Istio, Kubeflow, OpenFaaS, Cloud Foundry
5

5. Selected Weaveworks Customers
Financial Services Technology Other Industries
6
Telecom

6. GitOps for EKS

7. Git
Delivery
Controllers
GitOps – An Operating Model for Cloud Native
Build
GIT
Test
IDE
“Immutability
Firewall”
Operational
Controllers
Continuous
Integration
8
Deployment
(clusters, apps)
Monitoring
Logging
(Observability)
Management
(operations)
Compiled
declarative
state

8. Software agents ensure correctness
and alert on divergence
Approved changes to the desired state are
automatically applied to the system
The canonical desired system state is versioned
(with Git)
9
GitOps Principles
1 The entire system is described declaratively.
2
3
4

9. Software agents ensure correctness
and alert on divergence
Approved changes to the desired state are
automatically applied to the system
The canonical desired system state is versioned
(with Git)
The entire system is described declaratively.
10
GitOps Principles
1
2
3
4
Includes cluster
specifications,
components and
workloads
Clusters, apps
and infra stack
is versioned
Includes cluster,
workload,
infrastructure CRUD
Divergence from cluster/app/infra
spec is detected &
corrected automatically

10. 11
App
is developed &
tested locally
Built
automatically
using CI of your
choice
Container Image
pushed automatically
to a container
registry
Deployed automatically
using Weave
deployment manager...
...to an
Execution
Environment
of your choice
Development on Kubernetes ABCDE’s

11. CD: GitOps is a technology evolution of DevOps
Imperative Automation
DevOps GitOps
Infrastructure as Code Platform as Code
Mutation
Single State
Deployment
Declarative Automation
Immutability
Deployment and Operations
Reconciliation / Convergence

12. What do we mean by “GitOps at Scale”?
● What do we mean by “at scale”?
Any or all of:
○ Large number of applications, deployed across
large clusters or many clusters
○ Large number of Kubernetes clusters
○ A large cloud or infrastructure estate (managed
via GitOps)
○ Multi-cloud / hybrid-cloud scenarios (driven by
complexity of multiple operating environments)
● What are the best practices based on existing early
adopters who have scaled GitOps out?
13

13. Why GitOps is the Correct Way to Operate EKS at Scale
● Streamlined Fleet Operations: With GitOps, EKS can be operated reliably using established
workflows developed from running multi-hundred cluster fleets extensively in 300,000+ pod
production environments.
● Operate as a Single Team: By providing a single platform for both developers and operators, all
users share a common view of the health and state of the cluster and its workloads.
● EKS everywhere: GitOps reduces the complexity of Kubernetes by enabling a common declarative
approach across multiple infrastructure environments.
● Consistent Environments: Because all configuration resides in Git, and all changes begin in Git –
clusters and environments can be created and destroyed repeatability with reproducibility - many
clusters can be managed as easily as one.
● Enterprise Integration: Agility doesn’t happen in a vacuum, GitOps implementation is flexible and
fits in any enterprise environment - even (especially) in highly regulated ones.
● Observability: Built-in, real-time feedback and control loops utilizing Prometheus for observability
mean that problems can be detected and tracked down, while staying auditable.
14

16. Capabilities Business Benefit
Level 3
Scaled GitOps
Fleet management and fleet reconciliation
Mass customization
Advanced Policy
Advanced Cross-Enterprise Governance
Multi-Cloud and Hybrid
Enables Support for 5G/IoT/Edge deployment
Significant cost reduction for fleet management
Supports massive scale
Enables Enterprise Governance and Compliance
Empowers cross-vendor choice, visibility and control
Level 2
Enterprise GitOps
GitOps for the whole environment
- Infra, Cluster, Config, Workloads
Separation of Cluster from Workloads
Security / RBAC / Audit / Governance / Policy
Progressive Delivery
Package / Template Customization & Management
Improves agility across teams
Further reductions in cost as you scale
Enables Governance & Compliance validation & audit
Improves security
Enables Corporate Policy enforcement
Level 1
Core GitOps
Declarative IaC without reconciliation
GitOps for the Workload / App
- Automated reconciliation / drift detection
Environment & Secrets Management
Pull-based approach
Package Management (helm or kustomize)
Increases frequency of deployment
Reduces cost of operations
Reduces MTTR
Increases visibility and audit of operations
Introduces observability
Introduces basic Governance
Level 0
Prerequisites
for GitOps
Declarative Infrastructure as Code (IaC)
Declarative Workloads
Version control, Immutable images
Suitable infrastructure (e.g. Kubernetes)
“Cloud-native”
Faster provisioning of infrastructures
Repeatability
Immutability
GitOps Maturity Model - Details

17. Data & Operational Sovereignty

18. What do we mean by Sovereignty
Benefits:
● Advantages of the public cloud: By enabling a hybrid operating environment, organizations can take
advantage of the scalability and cost savings of the public cloud while at the same time ensuring that
their production data is kept within the sovereign boundaries that they define.
● Consistent runbook: With the ability to construct a hybrid development pipeline that uses AWS
Elastic Kubernetes Service (EKS) in the cloud and the open source EKS-Distribution (EKS-D) on
premise with Orange, developers and operators gain the efficiency of a consistent SDLC, while
maintaining operational sovereignty.
● Cost efficiency: By utilizing Weave GitOps Enterprise and EKS-D for customers’ on-premise
infrastructure, licensing costs can be reduced dramatically vs. cloud 1.0 operating models.
19
When AWS and Weaveworks discuss data and operational sovereignty, we are speaking to
customers’ ability to keep their data within the boundaries that they carefully define and
operate their infrastructure without having to have it connected/tethered to the cloud.

19. Industries Utilizing Hybrid Shared Services Platforms
While heavily regulated industries like financial services, healthcare, insurance and gaming were the
first to adopt GitOps managed hybrid shared services platforms (SSPs); increasingly businesses
across any vertical with the requirement to operate sovereign data or air gapped workloads are
adopting this architecture. These include:
● Financial Services
● Gaming (Fantasy Sports, Mobile, Console, Real Money)
● Government
● Healthcare
● Insurance
● Manufacturing
● Military
● Retail
● Telecommunications

20. Common Use Cases for Hybrid Shared Services Platforms
The most common reasons that companies implement a hybrid shared services platform
today are as follows:
1. There is a regulatory requirement that personally identifiable information (PII) be stored
in location with defined boundaries (i.e. within a specific geographic area or even data
center)
2. A customer has a large amount of data (often measured in peta or exabytes) that for
performance reasons needs to be located in proximity to their compute infrastructure
3. An entity has a requirement to operate workloads that are disconnected or intermittently
connected to the internet (i.e. air gapped)
4. An enterprise has a large amount of owned HPC that they prefer to utilize first in a hybrid
compute model

21. Hybridization and Edge Computing
Amazon EKS
+
AWS Fargate
Amazon EKS
+
Amazon
EC2
Amazon EKS +
AWS Outposts
On-premises Clou
d
Customer
Control Plane
Compute
Data Plane Customer
Support
Amazon
EKS
Anywhere
Customer
Customer
Customer
Amazon
EKS Distro
Customer
Customer
Customer
Community

22. Applicability: Disconnectable cloud in Europe
The Disconnectable Cloud offering enables our customers and our partners with a consistent hybrid cloud
experience, where they can leverage the AWS Cloud European Regions (including the Paris Region) with
200+ services, and
host sensitive/regulated parts of their workloads on our partner's infrastructure, with the Amazon
EKS-D open-source Kubernetes distribution, coupled with
i. a cluster management technology such as Cluster API,
ii. Weave GitOps Enterprise for consistent workload deployments between AWS regions and on premises
environments,
iii. and automation tooling optimized for on-premises environments (Amazon EKS-A – coming soon –, with
open-source tooling and AWS support).
With EKS-D/EKS-A and Weave GitOps Enterprise, customers can create reliable and secure clusters
on-prem with generic hardware, or on infrastructures of a trusted partner of their choice, with a management
and automation tooling similar to that deployed in the AWS Cloud (Amazon EKS Clusters).
The Control Plane of these sensitive/regulated clusters is operated by customers and partners in their
facilities, not on the AWS Cloud.

23. Example: Environmental Segregation

24. Example: Sovereign Data Hybrid Dev Pipeline

25. Deployment
Speed
50%
faster
Deployment
Frequency
65%
increase
Time
Spent
Coding
75%
more
● Increased developer productivity through
reduced complexity
● Improved security posture
● Greater uptime and faster
mean-time-to-recovery (MTTR)
● Higher infrastructure utilization through
better platform design and orchestration
● Reduced licensing costs by eliminating
unnecessary tooling
How Weave GitOps Shared Services
Platforms creates value for our joint
customers?
26

26. Bare Metal: DT, Weaveworks, AWS collaboration
27

27. Use Case Deutsche Telekom
● DT are planning a new platform driven by the
needs of 5G and an ongoing demand to become
more efficient
● Most of the applications they deploy are written
by third-parties so standardising the platform
enables them to standardise the approach
● Need for on-premise but they want to take a
‘cloud aware’ approach where they could use
the public clouds
● Focus has been on:
○ Building a reliable platform that can be
deployed into multiple backends
○ Integrating with existing investments such
as storage and virtualization vendors
Key Takeaways
● D-Telekom see GitOps as a way that can
drive reliability and efficiency
● Would like to avoid building out their own
unique platform - but need flexibility for
some customisation
● Need a simplified platform that is easy for a
variety of teams to use
● Predict they will have a large number of
deployments at the edge of their networks.

28. Customer Pain Points w/ Cloud
Native Adoption

29. Infrastructure Teams Aren’t Able to Scale
Simply put, there is a skills shortage in the
marketplace for people with cloud native, and
specifically Kubernetes, skills.
This lack of skills slows the pace at which
infrastructure / operations teams can serve the
developers that want to build cloud native
systems.

30. Technology is Changing Faster than
Developers Can Learn It
Developers are being asked to handle more and
more of the stack, and now even administer
infrastructure.
Combine this with accelerating change in the
technologies used across every function, and
developers can’t stay abreast of best practices
and tooling.

31. Enterprises Want to Adopt New Technology, Now
Enterprises want to transition from older
technologies to cloud native patterns more rapidly
than their teams’ skills can develop.
This causes log jams across many different areas
of a company, from infrastructure teams that now
need to support multiple different types of
infrastructure (VMs, IaaS, PaaS) to Dev teams
asked to support legacy SOA apps as well as
microservice applications.

32. The Net Result Being…
Enterprises are not able to expand
their capabilities as fast or efficiently
as they need to.
Their teams spend time administering
systems that add no value to their
core businesses.

33. How AWS EKS, Weaveworks & GitOps
Accelerate Cloud Native Adoption

34. Increased Developer Productivity through Reduced
Complexity
● Kubernetes Benefits, without its Complexity: By using AWS managed Kubernetes
(EKS) and combining it with Weave GitOps; operators and developers get all of the
benefits of Kubernetes without having to manage the complexity
● Operate as a Single Team: By providing a single platform for both developers and
operators, all users share a common view of the health and state of the cluster and its
workloads
● Streamlined Fleet Operations: With GitOps, EKS can be operated reliably using
established workflows developed from running multi-hundred cluster fleets extensively
in 300,000+ pod production environments.

35. Improved Security Posture
● Increased Auditability: Every change to infrastructure
is approved, logged, and managed through Git,
ensuring identities are verified, access is approved and
policies are enforced.
● Better Observability: Built-in, real-time feedback and
control loops utilizing CloudWatch for observability and
Git for change management mean that problems can be
detected and tracked down, while staying auditable.

36. Greater uptime & faster mean-time-to-recovery (MTTR)
● Consistent Environments: Because all
configuration resides in Git, and all changes begin
in Git – clusters and environments can be created
and destroyed repeatability with reproducibility -
many clusters can be managed as easily as one.
● Ephemeral Infrastructure: EKS clusters can be
started from scratch with identical configuration
and services to ones that were already running in
minutes as opposed to hours or days.

37. Reduced Licensing Costs
Utilizing GitOps and EKS in development pipelines
dramatically reduces their complexity while at the
same time removing licensing costs due to having
different tools for each stage of continuous integration
and continuous delivery/deployment systems.

38. Operating Scaled
EKS Shared Services Platforms
with GitOps

39. Challenges users face operating EKS at Scale
EKS User Persona Challenge
Platform Architect/Operator
Responsible for creating a definition for clusters that
will fill corporate and team requirements.
Defining standardized production ready clusters.
Managing Kubernetes and cluster component
upgrades. Needs to plan for security and compliance
regulations.
Cluster Operator
Responsible for managing clusters, taking the
standardized platform definition and managing an
individual cluster.
Cluster and cluster component upgrades. Scale
up/scale down, managing customized configuration
choices over time. Needs to implement security and
Application Developer
Responsible for creating an application that will run on
the production platform. They will develop the
application, test it in a variety of set-ups and release
new versions.
How to deploy new features and updates. How to set
up identical environments in order to test, observe
and debug issues.
SRE/Application Developer
Responsible for creating an application that will run on
the production platform. They will develop the
application, test it in a variety of set-ups and release
new versions.
Needs to manage application uptime: observability,
logging and all other related services.
Delivering, managing,
developing and
operating on EKS at
scale presents
organizations with
challenges on many
different levels before
its benefits can be
realized.
40

40. Introduction to Scaled SSP examples
● These are a set of best practices based on
Weaveworks’ experience with organizations who are
scaling out
● Each takes the pragmatic approach
○ Utilizing core GitOps principles
○ Balancing security / team organization vs repository
proliferation
○ Based on specific cluster requirements and team
structures
● They can be combined as needed
41

41. Different Configurations of GitOps enabled EKS SSPs
● A - “Multi-tenant clusters”
○ A small number of large clusters, many workloads
● B- “Multiple specialized clusters”
○ Many clusters, each with specialized requirements
● C- “Hybrid / Multi-Cloud”
○ Combination of On-Prem and Cloud clusters using EKSD, mixed workloads
● D - “Fleet scale”
○ Several workloads deployed identically across hundreds of clusters
● E - “Templating and Customization”
○ Different clusters using Helm for cluster / infra and workloads
○ Can be “mix-and-matched” with other examples
42

42. Example A - “Multi-tenant Clusters”
Summary Multiple teams using the same clusters with a cluster per environment
(multi-tenant, app teams restricted to namespaces via RBAC)
Number of clusters < 10
Number of workloads 100’s
Number of Repositories 3
Use of
Repos/Branches/
Folders
● Repos to separate Cluster/Infra, Development environments, Production
● Folders for cluster definitions
● Branches for Dev/Staging/UAT
Repository details 1. Infra and Cluster
2. Dev/Staging/UAT
3. Production
Use of Templates Application definitions
43

43. Example A
Multi-Tenant Clusters
Dev
Team A
App1
Code
Cluster / Infra
Declaration Repo
.
|__clusters
|__dev.yaml
|__UAT.yaml
|__prod.yaml
|__base
|__templates
|_nonprod
| |_capi.yaml
|_prod
|_capi.yaml
Team A
Manifest
Repository
Dev Branch
.
|__apps
|__app1
|__app2
|__jobs
|__etc
UAT Branch
.
|__apps
|__app1
|__app2
|__jobs
|__etc
Team A
App2
Code
Team A Prod
Manifest
Repository
Master/Main
Branch
.
|__apps
|__app1
|__app2
|__jobs
|__etc
CI Pipeline
ends in
immutable
image,
used in
deployment
manifests
Team A NS
Team B NS
Team N NS
UAT
Team A NS
Team B NS
Team N NS
Prod
Team A NS
Team B NS
Team N NS
Mgmt
Cluster
*Promotion
from Dev
Branch to
UAT via PR
Deploy / reconcile
desired & actual
state via FluxCD
or other GitOps
certified software
agent
Application
Repos / CI
44

44. Example B - “Multiple specialized clusters”
Summary Specialized clusters required to meet application needs
● Separate clusters for each environment / specialization
● e.g. GPU accelerated clusters for Machine Learning (ML)
Number of clusters 2-10 (i.e. a cluster per specialization per environment)
Number of workloads 100s
Number of Repositories 2 per specialization + 1 cluster/infra
Use of Repos/Branches/
Folders
● Repos to separate Cluster/Infra, application specializations
● Folders for cluster definitions
● Branches for Dev/Staging/UAT in each specialized non-prod repo
Repository details 1. Infra and Cluster
2. For each specialization:
a. Dev/Staging/UAT
b. Production
Use of Templates Application and cluster definitions
45

45. Example B
Multiple specialized clusters
Cluster / Infra
Declaration Repo
.
|__clusters
|__dev.yaml
|__ML.yaml
|__UAT.yaml
|__prod.yaml
|__base
|__templates
|_type1
| |_nonprod
| | |_capi.yaml
| |_prod
| |_capi.yaml
|_type2
Mgmt
Cluster
Dev
UAT
Clusters
Prod
Clusters
ML
App
Code
Non Prod Workload Manifest
Repository
ML
Code
Prod Workload Manifest
Repository
Master/Main Branch
.
|__apps
|__app1.yaml
|__app2.yaml
|__appN.yaml
|__jobs
|__etc
CI Pipeline
ends in
immutable
image,
used in
deployment
manifests
Dev Branch
.
|__apps
|__app1.yaml
|__app2.yaml
|__appN.yaml
|__jobs
|__etc
ML Branch
.
|__apps
|__ml-model1.yaml
|__ml-model2.yaml
|__ml-model3.yaml
|__jobs
|__etc
Dev-UAT
Branch
.
|__apps
|__app1.yaml
|__app2.yaml
|__appN.yaml
|__jobs
|__etc
ML-UAT
Branch
.
|__apps
|__ml-model1.yaml
|__ml-model2.yaml
|__ml-model3.yaml
|__jobs
|__etc
Application
Repos / CI
46

46. Example C - “Hybrid / Multi-cloud”
Summary Workloads required to run in different hosting environments (i.e. cloud or on-prem)
Number of clusters 10 - 100s
Number of
Repositories
3
This assumes that the repos are accessible in every environment
Number of workloads Any number from small to large
Use of
Repos/Branches/
Folders
● Repos to separate Cluster/Infra, Development environments, Production
● Folders for cluster definitions
● Branches for Dev/Staging/UAT
Repository details 1. Infra and Cluster
2. Dev/Staging/UAT
3. Production
Use of Templates Application and Cluster definitions
● Cluster template per target hosting environment
47

47. Example C
Hybrid / Multi-Cloud Dev
App 1
Code
Cluster / Infra
Declaration Repo
.
|__clusters
|__dev.yaml
|__UAT.yaml
|__prod.yaml
|__base
|__templates
|_cloud
| |_nonprod
| | |_capi.yaml
| |_prod
| |_capi.yaml
|_onprem
Non Prod Workload
Manifest Repository
Dev Branch
.
|__apps
|__app1.yaml
|__app2.yaml
|__appN.yaml
|__jobs
|__etc
UAT Branch
.
|__apps
|__app1.yaml
|__app2.yaml
|__appN.yaml
|__jobs
|__etc
App 2
Code
App N
Code
Prod Workload
Manifest Repository
Master/Main Branch
.
|__apps
|__app1.yaml
|__app2.yaml
|__appN.yaml
|__jobs
|__etc
CI Pipeline
ends in
immutable
image,
used in
deployment
manifests
Mgmt
Application
Repos / CI
Mgmt
UAT
Prod
Dev
UAT
Prod
Cloud
On-Prem
48

48. Example D - “Fleet Management”
Summary Several workloads deployed across 100s of similar clusters
Number of clusters 100s
Number of Repositories 3
Number of Workloads Any number
Use of Repos/Branches/
Folders
● Repos to separate Cluster/Infra, Development environments, Production
● Folders for cluster definitions
● Branches for Dev/Staging/UAT
Repository details 1. Infra and Cluster
2. Dev/Staging/UAT
3. Production
Use of Templates Cluster and Application definitions
49

49. Example D
Fleet Management
Dev
Cluster
(xN)
UAT
Cluster
(xN)
Prod
Cluster
(xN)
App 1
Code
Cluster / Infra
Declaration Repo
.
|__clusters
|__dev.yaml
|__UAT.yaml
|__prod.yaml
|__base
|__templates
|_nonprod
|_capi.yaml
|_prod
|_capi.yaml
Non-Prod Workload
Manifest Repository
Dev Branch
.
|__apps
|__app1.yaml
|__app2.yaml
|__appN.yaml
|__jobs
|__etc
UAT Branch
.
|__apps
|__app1.yaml
|__app2.yaml
|__appN.yaml
|__jobs
|__etc
App 2
Code
App N
Code
Prod Workload
Manifest Repository
Master/Main Branch
.
|__apps
|__app1.yaml
|__app2.yaml
|__appN.yaml
|__jobs
|__etc
CI Pipeline
ends in
immutable
image,
used in
deployment
manifests
Deploy / reconcile
desired & actual
state via FluxCD or
other GitOps
certified software
agent
Create / reconcile
desired & actual
cluster via FluxCD or
other GitOps certified
software agent
Mgmt
Cluster
Application
Repos / CI
50

50. Example E - “Templating and Customization”
Summary Using Helm to template and customize workloads
Number of clusters Any number
Number of Repositories One additional repository for Helm charts (includes public charts)
4 in total for this example
Number of Workloads Many
Use of Repos/Branches/
Folders
● Repos to separate Helm charts / templates, Cluster/Infra, Development environments,
Production
● Folders for cluster definitions
● Branches for Dev/Staging/UAT
Repository details 1. Helm
2. Infra and Cluster
3. Dev/Staging/UAT
4. Production
Use of Templates Cluster and Application definitions
51

51. Example E
Templating and Customization
App 1 Code
Cluster / Infra
Declaration
Repository
.
|__clusters
|__dev.yaml
|__UAT.yaml
|__prod.yaml
App 2 Code
App N Code
CI Pipeline
● Build, Test
● Publish Versioned,
Immutable Image
Application Code
Repos / CI
Helm / Templates Repo
.
|__cluster
|__templates
|__values.yaml
|__chart.yaml
|__infrastructure
|__grafana
|__prometheus
|__istio
|__cert-manager
|__etc
|__microservice
|__templates
|__deployment.yaml
|__hpa.yaml
|__service.yaml
|__etc
|__values.yaml
|__chart.yaml
CI Pipeline
Build, Test
Publish Versioned Chart
Helm Registry
Non-Prod Workload
Repository
Dev Branch
.
|__apps
|__app1.helmrelease/values.yaml
|__app2.helmrelease/values.yaml
|__appN.helmrelease/values.yaml
|__jobs
|__etc
UAT Branch
.
|__apps
|__app1.helmrelease/values.yaml
|__app2.helmrelease/values.yaml
|__appN.helmrelease/values.yaml
|__jobs
|__etc
Prod Workload Repository
Master/Main Branch
.
|__apps
|__app1.helmrelease/values.yaml
|__app2.helmrelease/values.yaml
|__appN.helmrelease/values.yaml
|__jobs
|__etc
Desired State Repositories
Image
Registry
Templating Repos / CI
52

52. What about Monorepos?
● These examples are of “GitOps at Scale”
● Monorepos can, in this context, be useful for a single team that:
○ Manages infra & clusters
○ Manages Dev/Staging/UAT and Production workloads
● Monorepos for anything other than very small implementations quickly bring a
large amount of complexity:
○ Authorization to parts of the repo is likely difficult, problematic, or impossible
○ CI system requires sophistication to prevent building everything upon each
change
● Can work for Levels 1/2 in the GitOps Maturity Model in some cases
● We do not recommend a monorepo for Scaling
53

53. Monorepos - not recommended for scale
Summary A single team managing everything - simple approach
Number of clusters Any number
Number of Repositories 1 repository containing infra/cluster as well as dev/staging/UAT/prod
Number of Workloads 1
Use of Repos/Branches/
Folders
● Folders for cluster definitions
● Branches for Dev/Staging/UAT
Repository details 1. Infra and Cluster
2. Dev/Staging/UAT/Production
Use of Templates Per cluster definitions
54

54. Weaveworks Offerings
TECHNOLOGY & CONSULTING SERVICES
55

55. Professional Services Overview
Weaveworks can engage with you from
Cloud Native readiness review, architecture
& design to long term dedicated expertise
● Provide organizations with detailed readiness
review of your current or planned cloud native
initiatives
● Architect, Designing and Building the platform
alongside your team.
● Provide long term stability with Dedicated SRE
expertise
● Work with your team to integrate and develop new
ways of working that use GitOps to full advantage
56

56. TECHNOLOGY: Weave GitOps Enterprise
Workload Workload Workload Workload
Container
Control
Release
Management
Visualisation
Monitoring &
Metrics
Alerting
Cluster
audits
Deployment
Policy
Dashboards
Kubernetes
Cluster
configuration
Fleet
management
Cluster
components
Logging and
Tracing
Networking Storage
Infrastructure
Automation
Security
• Continuous Delivery, observability
and monitoring
• Consistent developer workflows
across multiple deployments
• Team workspaces for
multi-tenanted usage
• Extend Kubernetes to
managed platform using
GitOps model
• An Open Source Kubernetes
platform for on-premise
deployment
• Additive to manage Kubernetes
(e.g. EKS, AKS or GKE)
• Upgrades to new versions
• Extensible controls to
implement security and policy
controls
Developer
Experience
Operator
Experience
57

57. Education Enablement Platform Modern Ops
Weaveworks Consulting, Training and
SRE Service
• Guided technology choices
• Cloud native reference
architecture designs
• Cloud native technology
options and selection
Modern App Platform w/EKS
• Configuration management
for the whole platform
• Integrated governance, risk &
compliance
• Seamlessly integrated
metrics
• 24/7 worldwide support
Faster Delivery, Lower TCO
• Automation, management
and Continuous Delivery
• CloudWatch monitoring
and alerting
• Increased developer self
service capabilities
• Training for cluster
operators, application
operators and developers
• Delivery of POCs and
experimental environments
The steps to cloud native in production ...
GET STARTED FAST
TEACH AND MANIFEST
EKS SKILLS
DELIVER A PRODUCTION
READY APP PLATFORM ON EKS
GITOPS TO ENABLE AN
AGILE DELIVERY MODEL
1 2 3 4
58

58. Thank you!
Contact us to discuss how to get your customers operating
EKS at scale quickly!
Daniel Lizio-Katzen
Head of Strategy & Partnerships
djlk@weave.works
Leonardo Murillo
Principal Partner Solution Architect
leo@weave.works
Paul de Monchy
Principal Solution Architect
monchyp@amazon.fr