
Sign up to save your podcasts
Or


ABSTRACT OF THE TALK
BIO
Benchmarking storage is not a new concept, this has been happening on storage for a long time. But have we overlooked the benchmarking capabilities or at least the ease in which to achieve this in a cloud-native, container-based, Kubernetes landscape? There has been a rise in stateful workloads and support around persistent storage in Kubernetes is improving. Now we can take our traditional workloads such as SQL Server, Oracle and SAP alongside our data stores for microservices with the same storage system for MongoDB, Cassandra, Redis, MySQL and PostgreSQL. With each of these stateful applications having different performance requirements, it becomes necessary to benchmark the storage backing these Persistent volumes. The CSI (Container Storage Interface) is the standard for creating custom components to work with data storage. This has enabled many more storage vendors to adopt their platforms to the cloud-native approach and offerings. All of this is great, but how do we ensure that the right datastore is used to achieve the performance required for our microservices running these stateful workloads?
A community first technologist for Kasten by Veeam Software. Based in the UK with over 16 years of industry experience with a key focus on technologies such as cloud-native, automation & data management. His role at Kasten is to act as a technical thought leader, community champion and project owner to engage with the community to enable influencers and customers to overcome the challenges of Cloud-Native Data Management and be successful, speaking at events sharing the technical vision and corporate strategy whilst providing ongoing feedback from the field into product management to shape the future success.
Kubestr can assist here in three ways: · Identify the various storage options present in a cluster. · Validate if the storage options are configured correctly. · Evaluate the storage using common benchmarking tools like FIO.
In this talk, we will go over what Julia is, why you would want to learn it, and how to contribute to the ecosystem.
Logan is the Community Manager for the Julia Programming Language, a member of the Board of Directors at NumFOCUS, and a Machine Learning Engineer. Outside of work, Logan is a graduate student at Harvard University and Northwestern Universities Pritzker School of Law.
Viewers will leave with a high-level understanding of the Julia ecosystem, the benefits the language provides, how to contribute to it, and more.
AHOY is a release manager for Kubernetes, fully open source.
I thought, this is easier explained, in, interpretive rap... Look, if you had one shot, one opportunity To fix everything that was ever broke In one deployment Would you rebuild it, or just let it fail? Yo His palms are sweaty, config weak, server load is heavy There's vomit on this keyboard already, Kubernetes He's nervous, but the control plane says Nodes are ready Fork Bomb, but he keeps on forgetting Commands he wrote down, to restart all the pods He opens up Wikis, but the page won't load out Server's chokin now, everybody's phoning now. Release window runs out, times up, over bloaw! Roll back to the previous, oh this is grievous Oh there goes docker, it's borked! He's mad cause K8 don't, downgrade that easily? No He won't have it, he knows, manual deploys back’s on the ropes It don’t’ matter He's dope, he knows that, but he broke He's whole Openstack So when he goes back to his mobile app,that's when it's Back to the Trello Board yo, this whole Agile thing sux He better go capture the screen logs next time using tmux You better lose yourself in this DevOps, the SecOps You own it, you better never let it go Ho! You only get one shot, do not miss your change to Window This opportunity comes once in a weeks time Yo! So that is what I do on a typical day.
It automatically incorporates GitOps, auto-generation of Helm charts, all stored on Git.
Kubernetes has emerged as the de-facto way to deploy modern containerized apps on cloud or on-premises. Despite all that growth on the application layer, it remains challenging to run a database in a distributed environment like Kubernetes. However, many developers want to treat data infrastructure the same as application stacks. Operators want to use the same tools for databases and applications and get the same benefits as the application layer in the data layer: rapid spin-up and repeatability across environments. This is where KubeDB by AppsCode comes as a solution. KubeDB by AppsCode is a production-grade cloud-native database management solution for Kubernetes. KubeDB simplifies and automates routine database tasks such as provisioning, patching, backup, recovery, failure detection, and repair for various popular databases on private and public clouds.
Tamal Saha is the Founder/CEO of AppsCode. Tamal was born and raised in Bangladesh. He completed his BSc in CSE from the top engineering school in Bangladesh. He came to the USA as a Ph.D. student at the University of Virginia in 2009. After finishing MSc, he dropped out of the PhD program and spent the next 5 years building core infrastructure software that powers Amazon retail and Google Ads business. While at Google in 2015, he became an early adopter and contributor to Kubernetes. Since he has developed well known projects in the Kubernetes space like KubeDB, Stash, Kubeform, KubeVault, Voyager, etc.
- Kubernetes is a viable platform for running production-grade databases. - Helm charts are not enough for Day 2 life cycle management of databases. - Users really need an operator based solution for running databases in Kubernetes.
Chaos Engineering in the past few years has evolved with the development of the Cloud-Native paradigm and with the introduction of the LitmusChaos tool which helps curate Cloud-Native Chaos Engineering. Belonging to the CNCF ecosystem, Litmus stresses upon applying Chaos Engineering to modern architectures and building resilient applications simultaneously. The features and ideas majorly surround Community Collaboration, Observability, GitOps, Open APIs & much more. Chaos testing is seen as a must for all Cloud-Native practitioners emphasizing reliability as a container challenge. This talk stresses the evolution of Chaos Engineering with the introduction of the LitmusChaos 2.0
Prithvi Raj has been an active community manager in not only building LitmusChaos, the CNCF project based on Cloud-Native Chaos Engineering but also the overall Chaos Engineering community by working extensively as a co-organizer of the global conference Chaos Carnival as well as hosting monthly meetups at the CNCF Kubernetes Chaos Engineering Meetup group. His love for Chaos Engineering started in 2020 and has been growing ever since leading to the active adoption of chaos testing as a means of testing. He has also worked as a co-organizer for KCD Bengaluru 2021 and has delivered talks at various forums including KCD Africa, Cloud-Native Students, etc. Other than this Prithvi loves listening to Indie pop music and is an ardent fan of Liverpool FC. Watching cricket and wrestling are also his leisure activities. He loves collecting currencies as a hobby!
Kubeflow is a cloud-native ML platform that simplifies the training and deployment of machine learning pipelines on Kubernetes. lakeFS is wrapper layer around an object store that enables git-like operations such as branching and committing over datasets. Learn how to build ML workflows that are portable, scalable, and reproducible by integrating lakeFS operations into your Kubeflow pipeline components
Barak is a software developer of the open source lakeFS project at Treeverse. He has more than 15 years of experience in a wide range of systems, from scheduling to security. He’s passionate about three things: programming languages, distributed systems, and long-distance running.
Prometheus was initially made for short metric retention to answer questions on “what is happening ‘now’”. It is a strong project that solves certain problems really well, but still as a monolith when doing so. Thanos has been made to enable scaling, highly available setups and long term (cheap) storage for Prometheus. Everyone could leverage Thanos for these features. It does not stop there; Thanos has multiple components that could be used for multi-cluster telemetry, remote writes, and multi-tenancy. We want to introduce everyone to Thanos. Explaining the use-cases and how it could benefit your stack now observability becomes such an important factor in tech.
Wiard van Rij’s main focus is in the field of observability at Fullstaq. As a consultant he is helping people, teams, and organizations with various cloud-native challenges with a strong focus on Kubernetes and Observability. Wiard is a Thanos team member, open source enthusiast and has extra fun with security and hacking.
- Introduction to Prometheus and Thanos - How to extend your stack(s) for highly available and long term metrics - By leveraging the right tools and services, one can have a rich set of features which are also cost effective
So you want want to run stateful containers? A brief intro to persistence in Kubernetes. Kubernetes and persistent storage go together like oil and water. Kubernetes is inherently an ephemeral system and persistent storage by definition must survive. After his talk, you should have a clear understanding of the how to get started on the path to successfully manage a persistent data storage solution on your Kubernetes cluster
Kunal - Junior pursuing Computer Science & Engineering. Co-founder at Code for Cause. CNCF Intern 2020. MLH Coach. Google Summer of Code Mentor. YouTuber. Gold Microsoft Learn Student Ambassador.
Kubernetes has hit a home run for stateless workloads, but can it do the same for stateful services such as distributed databases? Before we can answer that question, we need to understand the challenges of running stateful workloads on, well anything. In this talk, we will first look at which stateful workloads, specifically databases, are ideal for running inside Kubernetes. Secondly, we will explore the various concerns around running databases in Kubernetes for production environments, such as: - The production-readiness of Kubernetes for stateful workloads in general - The pros and cons of the various deployment architectures - The failure characteristics of a distributed database inside containers In this session, we will demonstrate what Kubernetes brings to the table for stateful workloads and what database servers must provide to fit the Kubernetes model. This talk will also highlight some of the modern databases that take full advantage of Kubernetes and offer a peek into what’s possible if stateful services can meet Kubernetes halfway. We will go into the details of deployment choices, how the different cloud-vendor managed container offerings differ in what they offer, as well as compare performance and failure characteristics of a Kubernetes-based deployment with an equivalent VM-based deployment.
Amey is a VP of Data Engineering at Yugabyte with a deep passion for Data Analytics and Cloud-Native technologies. In his current role, he collaborates with Fortune 500 enterprises to architect their business applications with scalable microservices and geo-distributed, fault-tolerant data backend using YugabyteDB. Prior to joining Yugabyte, he spent 5 years at Pivotal as Platform Data Architect and has helped enterprise customers across multiple industry verticals to extend their analytical capabilities using Pivotal & OSS Big Data platforms. He is originally from Mumbai, India, and has a Master's degree in Computer Science from the University of Pennsylvania(UPenn), Philadelphia. Twitter: @ameybanarse LinkedIn: linkedin.com/in/ameybanarse/
From the publisher's feed

10,141 Listeners