Community-related job plus some technical marketing - Guiding customers and building cloud blueprints for them Former startup CTO - Built a startup from scratch and a product based on Kubernetes but never got to funding rounds as EU is hard for startups and competition is fierce. Former Lead DevOps Engineer - Site Reliability Engineer - Ensuring that deployment and operations are automated, plus 24/7 support in case of incidents of critical systems For more info you can visit https://mb-consulting.dev/experience This is me, earlier this year (last month), speaking at Cloud Native Rejekts in Paris
takes way longer than a couple of hours to learn it; • We will look at things from an industry/enterprise angle more than an academic one; • Goal is to spark your curiosity more than to give you all the answers; • Q&A is encouraged at the end of each chapter - but also in the middle, as long as you politely raise your hand; • Reporting incorrect / incomplete information is appreciated, so my next students (and I) will be happier. • I’m not sponsored, endorsed or tied in any way with the Linux Foundation or the Cloud Native Computing Foundation (CNCF) X X ✓
• Orchestrating containers • Kubernetes in a nutshell • Kubernetes use cases • Kubernetes in AI/ML • Break (10 minutes?) • What does Cloud Native mean? • Cloud Native Computing Foundation (CNCF) - what, how, why? • CNCF Landscape • Summary • Final remarks - yes, slides will be publicly available
were delivered and served on bare metal servers where a developer in a company had to: • Buy, install and manage hardware in house - including power supply, cables, A/C and dealing with component failures. • Manage the OS layer - keeping the OS updated (probably once every 3-4 years for server OS), networking and security… • Operating the application - logging in SSH, copying files via SFTP, manually restarting Linux services This has been the standard de-facto until the early 2000s - just in time for the internet bubble - even if virtualization was born in the 1960s.
run, maintain and manage their own data centers, companies started both adopting virtualization and outsourcing to 3rd parties service providers. This is the time of Wordpress, Yahoo and Flickr.
of VM services as most of their customers were still running monolithic apps. 2007 2008 2010 AWS, GCP and Azure are currently a de-facto oligopoly of hyperscale cloud providers, in terms of % market share (31%, 24%, 11% - totaling 66% of share), other providers are trying to fill market gaps and offer specific services to compete - e.g. regional, privacy-driven… 2013 2009 2015 1999 1998 2016 2013 1999
taken into account in the 2010s, shifting the software complexity from the development process to the operations processes but obtaining in return: • Modularity - problems solved by software are way more complex and on way more verticals than before • Scalability - internet and software usage is becoming fundamental at all levels of society, hence more users • Integration - protocols like SOAP and REST took over and enabled a wide range of integration between products • Distribution - both in terms of deployment and workload - smaller teams, highly specialized with a strong distinction between frontend and backend (finally no more fullstack?) Thanks to microservices we witnessed the rise of different methodologies, practices and tools such as: CI/CD - to enable faster and automated shipping, DevOps - to handle operations complexity, Agile Scrum - to add complexity and give Scrum masters a job…
run multiple apps on the same physical server but, due to the higher density of microservices, it started to be too complex to manage everything on a single VM, so a new standard appeared: containerized apps. Containerization enabled the deployment of multiple applications (preferably microservices) on the same OS, without any hardware abstraction layer but in order to deploy a containerized application, a container image needs to be created first.
based on LXC, a Linux virtualization system that allows running multiple Linux instances on the same kernel. In the same way, Docker aim was to ship multiple containerized software images running on the same OS. A container image is a standard packaged application encapsulating its requirements, dependencies and runtime environment along with information about how to run standalone. Not so different, at least in its purpose, from a .jar, .dll, .exe file. A new container standard was created, including the container image specification and the docker runtime named runc and containerd, along with many utils like: docker-cli, docker-engine, docker-desktop, docker-compose, Dockerfile - or the configuration file enabling the creation of a Docker image…
spec were donated to the OCI (Open Container Initiative) under the Linux Foundation. In 2016, containerd was donated to the CNCF (Cloud Native Computing Foundation) - which is a branch of the LF. The whole IT world started a rapid shift towards containerized workloads and today more than 6 millions developers run containerized workloads on AWS, Azure and GCP combined.
for a simple nodejs app, in the root of our git repository FROM node:18-alpine WORKDIR /app COPY . . RUN yarn install --production CMD ["node", "src/index.js"] EXPOSE 3000 Given that we have docker-cli and the engine installed, running docker build creates the image and a simple docker run will execute our Nodejs application and expose it locally on the address http://localhost:3000 Yes, it can (and will) get way more complex than that.
the Conservation of Mass law “mass is neither created or destroyed”, so is complexity in IT systems. Both microservices and containers contributed to shift complexity on the operational level, so much that, on top of Docker alternatives and new container runtime software (FirecrackerVM, Podman, Buildah, CRI-O), a new way of operating software had to be created: container orchestration.
management of containers, creating an abstraction layer away from the underlying infrastructure, allowing to coordinate manage and monitor containerized applications. • Provisioning - defining and creating containers based on a declarative programming paradigm, typically YAML-based • Deployment - image retrieval from a container registry, deployment of the image and process execution • Resource allocation - distributing vCPU and vRAM based on load and constraints • Node management - moving containers on different underlying hosts in case of unavailability • Scalability - scaling application replicas up and down based on load and constraints • Networking - exposing (micro)services, service discovery, L4-L7 load balancing,service mesh, traffic isolation, encryption… • Advanced capabilities - Self-healing a.k.a. replacing services in a non-healthy or degrading state with new ones and more…
based on the catchy phrases “prepare to be assimilated” and “resistance is futile” from Star Trek and was also the name of an internal tool used until late 2013 at Google. Borg served as a cluster orchestration tool while building the Google Cloud Platform trying to compete with AWS and it was used as the blueprint of what later on will be the One Tool to orchestrate them all. In 2014, co-founded by Brendan Burns, Joe Beda and Craig McLuckie - the Kubernetes project was born. A brand new orchestration tool, taking part of the architecture from Borg and re-designing the rest of it to be Cloud Native. After convincing Google’s executives, k8s (there are 8 letters between ‘k’ and ‘s’ in the word Kubernetes) has been open-sourced in 2014 with the famous wheeled logo and Cloud Native Era begun. https://research.google/pubs/large-scale-cluster-management-at-google-with-borg/ https://kubernetes.io/
Docker was pretty obvious since k8s was born, but it was actually standardized and widely adopted only later on. Now a few more facts about k8s history: • Version 1.0 (stable) was officially launched in July 2015, now we have 1.29 (december 2023) - and 1.30 is due soon; • Google worked with the Linux Foundation to create the Cloud Native Computing Foundation; • Project was donated to the CNCF as first seed technology; • In 2018 Google left the steering wheel (pun intended) to the OSS community; • Kubernetes was born stateless but now happily supports stateful workloads as well;
tools aside vanilla k8s, with many different flavors and capabilities but the most important distinction is between managed and unmanaged tools. EKS (AWS), AKS (Azure), GKE (Google), OpenShift (RedHat), Rancher (SUSE) are managed orchestration tools offered in a PaaS (Platform as a Service). 90% of users run k8s on managed services in production environments. Docker Swarm, Apache Mesos, Nomad (HashiCorp) are open-source unmanaged orchestration tools - a.k.a. DIY - do it yourself
works? Imagine you are a grandma and you have three hungry nephews to feed biscuits to, you want to bake for all of them at the same time and you need to distribute these biscuits. Alessandro doesn’t like chocolate, Filippo doesn’t like fruit jam, Matteo loves chocolate chips… You need a grandma to orchestrate the effort and overseeing this cookies prep sesh.
• Automated operations especially day-to-day ones like deployment, rollback, restart… • Infrastructure abstraction - compute, networking are storage are handled with fairly good defaults; • Declarative state reconciliation - system tends to remain the way it was defined and intended to run - GitOps anyone? • Service health monitoring - k8s ensures your service is healthy before marking it as available with a probe system (ready is different than healthy); • Runs anything, anywhere - all the major and minor cloud providers have a managed Kubernetes offering, plus k8s can run on bare-metal and be used at the datacenter level to orchestrate VMs - see KubeVirt, any workload; • Scalability is nearby infinite - there is technically no hard limit, one could have 5000 nodes, 10000 namespaces and 150000 pods and still achieve a fair level of performance. Beyond that level it just starts to degrade. Reminder that 1 pod = 1 or 2 microservices - See how they do it at OpenAI (running 7500 nodes), Netflix (dealing with orphaned pods) and Spotify (running 30% of the whole music streaming infrastructure worldwide); Source: https://github.com/kubernetes/community/blob/master/sig-scalability/configs-and-limits/thresholds.md - thanks SIG Scalability for the info;
• Wide open-source ecosystem rich of tools one can attach to your clusters to enable advanced capabilities • SDKs (Software Development Kit) and Operators to create CRDs (Custom Resource Definitions) for maximum flexibility; • Short release cycles and huge community support - innovating fast and deprecating even faster; • Cost reduction and higher density of resource usage (only if well managed), that means to be greener as well; • Portability - a bit like what Java proposed thanks to the JVM, Kubernetes is proposing thanks to its large adoption, interoperability and vendor support;
their portfolio website on Kubernetes but it is most probably an overkill and getting diminishing return based on effort needed. Instead, these are some use cases that can benefit from such advanced container orchestration practices: • Edge computing / IoT - k8s works well even with no or little internet bandwidth, constrained resources, and in private air-gapped environment* • Artificial Intelligence, Machine Learning - K8s allows orchestrating GPU workloads, dynamic resource allocation (DRA), sharding, sharing, vGPUs, ML training and even inference; • Government - K8s allows multi-tenancy and segregation of data and it has been adopted by governmental bodies, especially in the US but also in the Netherlands, for example the Dutch Tax Office uses k8s in production. • Big Data - Peaks of big data computing are well handled by k8s autoscaling For more details about adopters and their specific use-cases you can explore this https://www.cncf.io/case-studies/ * this is true for specific lightweight distribution of k8s, like k3s.
way of approaching software by building, deploying, and managing modern applications in cloud environments, may they be private, hybrid or public clouds - leveraging IaaS, PaaS and SaaS tools. Cloud native software is designed, built and maintained to be: scalable, flexible, resilient, fault-tolerant, highly distributed and quickly and frequently updated. In short: born to be cloud.
but Cloud Native is not just Kubernetes or containers, even if they power the backbone of most cloud native apps. There are many other tools and concepts belonging to Cloud Native such as: IaC (Infrastructure as Code) tools - Pulumi, CrossPlane, OpenTofu, Terraform - contributing to providing immutable infrastructure; API tools and specs - OpenAPI (spec), gRPC (spec), Postman (DevTool), Zuplo (API management), Kong (API gateway); DevOps tools - Jenkins (CI/CD), Prometheus (Time series db), Grafana (Dashboards)...; Service meshes - Cilium, Istio, Linkerd, Consul, Traefik…; Microservices development frameworks and languages - Spring boot (Java), Quarkus (Java), Django (Python)… Serverless frameworks - Dapr, OpenFaaS…; Anything that was either created or modified to be cloud-first is cloud native.
is huge, navigating can be exhausting and it is complex in many different ways. For this reason, meanwhile Kubernetes was getting donated back in 2015, a number of companies and the Linux Foundation, decided to join forces and created the Cloud Native Computing Foundation (CNCF). RIP🪦💀🥀🕯🕊 (project discontinued by Fedora) rebranded to D2iQ later sold to Nutanix Acquired by Altair Engineering
of over 450 members (companies), part of the Linux Foundation staff and their internal staff, plus all of their contributors. Main goal is to keep Cloud Native as Open Source as possible in a sustainable way for vendor companies (including cloud providers), end user companies, us engineers working with Cloud Native tech. Another goal is to grow the community, educating and guiding companies that are not Cloud Native, yet. CNCF organizes global events such as KubeCon and the OpenSource Summit and helps local communities organizing events such as KCDs (Kubernetes Community Days) and CNCG (Cloud Native Community Groups) Note: I’m not sponsored, endorsed nor tied in any way to CNCF
governing body of the CNCF Foundation. It counts members from different organizations and backgrounds: vendors, end-users, developers… The goals of this body are: • Defining and maintaining the overall vision and mission for the Cloud Native Computing Foundation; • Collaborating with the Technical Oversight Committee to ensure technical decisions align with such vision/mission; • Meet 3 to 5 times per year to define the CNCF roadmap, marketing strategy and budget; • Unclear how the members are appointed/elected, aside from the ones coming from paid CNCF membership; Sources: https://www.cncf.io/people/governing-board/ https://github.com/cncf/foundation/blob/main/charter.md
is the technical governing body of the CNCF Foundation. The goals of this body are: • Defining and maintaining the technical vision for the Cloud Native Computing Foundation; • Approving new projects within the scope for CNCF set by the Governing Board (GB); • Create a conceptual architecture for the projects, aligning, removing or archiving them, accepting feedback from end user committee and map new projects; • Aligning interfaces to components under management (code reference implementations before standardizing), and defining common practices to be implemented across CNCF projects, if any; • All votes, meetings and artifacts are publicly accessible in the spirit of Open Source. Sources: https://github.com/cncf/toc https://www.cncf.io/people/technical-oversight-committee/
group aiming to scale contributions by the CNCF technical and user community TLDR; These groups should be maintaining and advocating for CNCF projects. These are the currently active TAGs: • TAG App Delivery - see SIG App Delivery / Core and applied architectures • TAG Contributor Strategy - maintainership, mentorship, utils for the rest of the TAGs • TAG Environmental Sustainability - Green software, also related to the Green Software Foundation (GSF) • TAG Network - see SIG traffic • TAG Observability - see SIG Observability • TAG Runtime- see SIG Core and applied architectures • TAG Security - see SIG Governance • TAG Storage - see SIG Storage Sources: https://github.com/cncf/toc?tab=readme-ov-file#technical-advisory-groups https://github.com/cncf/toc/blob/main/tags/cncf-tags.md
there are working groups focusing on single projects (continuous or scoped) WGs and TAGs are both open and anyone can join, each TAG also has a Chair, a Co-Chair and Tech Leads; these roles don’t exist for WGs. For example, the TAG App Delivery has the following WGs: • Platforms • GitOps (moved to OpenGitOps) • Air Gapped (inactive) • Operator (inactive) • Artifacts Each group has its own public meeting schedule, working hours and internal structure, all the docs is on a GitHub repo. Source: https://github.com/cncf/tag-app-delivery
easier than that. https://landscape.cncf.io/ https://landscape.cncf.io/stats The landscape which is basically a map of all the current (relevant) Cloud Native open-source projects counts: 114 Sandbox projects 36 Incubating projects 26 Graduated projects The degree of maturity and adoption of a project determines its state and speeds up/slows down passage from sandbox all the way up to graduated. Source: https://github.com/cncf/toc/tree/main/process
before you jump right into building your Cloud Native app, help your company doing so or migrate from those old on-premise servers to the cloud, is better to remember that: • Cloud is just a tool, not a one-fits-all solution; • A bad performing on-premise software will perform even worse in the cloud; • Costs are shifted from maintaining a datacenter and paying electricity bills to pay someone else to do the same; • 12Factor is still relevant today, implementing that and only then going to the cloud is highly advised; • Managed Serverless is very expensive - see AWS Lambda or Azure Functions costs compared to having your own; • Any managed service is typically expensive and has tradeoffs - see any managed k8s offering; • Egress traffic (going out of the cloud provider) and hot storage are typically the highest costs of your cloud infra;
and CN? Bologna, 20 June 2024 https://community.cncf.io/events/details/cncf-kcd-italy-presents-kcd-ital y-2024/ Discount code not available yet, before purchasing a ticket get in touch with the organizers.
any e-learning course on https://training.linuxfoundation.org CLOUDNATIVECG (expires 31/12/2024) I suggest you to buy these certifications only if someone else can pay for it - they are industry valid and highly requested. My suggested path - pre-requirement being knowing (some) about Linux and Cloud Infrastructure: • LFS158x - introduction to k8s(free)+ LFS250 - K8s and Cloud Native essentials • CKNA - Kubernetes and Cloud Native Associate - [optional] k8s the hard way • CKA - Certified k8s administrator (for DevOps/SRE/Cloud Engineers) • CKAD - Certified k8s app developer (for Software Engineers) • CKS - Certified k8s security specialist (for DevOps/SRE/Cloud Engineers) Note: I’m not sponsored, endorsed or tied in any way with the Linux Foundation - this code is a general courtesy for university students.
started from 1972, year when the first virtualized OS was born. Observe how most breaking changes such has the advent and adoption of cloud happened from 2014 to 2024. Only 10 years. In tech this is a huge amount of time. Extending the example further, AI existed since 1956, Machine Learning since 1958. OpenAI released ChatGPT at the end of 2022 and since then the market has been flooded with AI products in under 3 years. Cloud Native is the very foundation of every modern app currently deployed, it will most probably accelerate AI even more, it is fundamental that you learn more about it. Grasp it and make it yours but, at the end of the day, the important things are how fast you learn new concepts, new languages, new frameworks, new hard skills and how often you use your knowledge in practice. Even more, in my opinion, the most important thing in tech is how smart are the people you work and pair with.
smartest person in a room” “A job should either give you good money or good knowledge, having both is great, having neither means 'go away as fast as you can'”
you contact me with a good question, I will try to give you the tools to answer yourself, which if you ask me is worth way more than just giving you the answer. Email - [email protected] LinkedIn - linkedin.com/in/mbianchidev For more info about me you can visit https://mb-consulting.dev or find me on social media @mbianchidev Note: I do not guarantee replies within a certain time frame
Headers: Assistant Body Copy: Assistant You can find these fonts online too. Happy designing! Don't forget to delete this page before presenting. Use these design resources in your Canva Presentation. RESOURCE PAGE
do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
mbianchidev
samlambert
rocio
shpigford
geeforr
revolveconf
soudai
davidbonilla
wjessup
rasmusluckow
chriscoyier
speakerdeck
