[00:00.000 --> 00:06.040]  Sounds like we're live. I wanted to start off today's presentation by thanking everybody in the
[00:06.040 --> 00:12.660]  DEF CON community for welcoming me to present on the Storage Network in Tardigrade today.
[00:12.660 --> 00:16.960]  This is my second time presenting at DEF CON and I'm really excited to be here.
[00:17.000 --> 00:21.620]  Today what I'm going to do is I'm going to first give a quick update around the Storage Network,
[00:21.620 --> 00:27.680]  which launched in March, talk about the recent wins from an adoption standpoint,
[00:28.320 --> 00:31.160]  what tools are being built on the network, who are we working with.
[00:31.160 --> 00:35.420]  Then I'm going to go into a quick workshop that will walk you through the process
[00:35.420 --> 00:42.500]  of backing up Kubernetes configuration and object data to the decentralized cloud using an open
[00:42.500 --> 00:48.760]  source tool called Valera, which is sponsored by VMware. And so with that, let's go ahead and get
[00:48.760 --> 00:53.020]  started. And if anyone has questions, just post them in the chat and we can get to them at the
[00:53.020 --> 01:01.560]  end right before the workshop. So as a company, our goal is to build the world's largest,
[01:01.560 --> 01:08.780]  most secure, resilient, performant, and economical cloud storage service without owning or operating
[01:09.280 --> 01:14.080]  a single data center. And what that really means is that rather than having the cloud
[01:14.080 --> 01:19.280]  controlled by gatekeepers across a small number of data centers, we enable anybody to be the cloud
[01:19.280 --> 01:23.740]  by monetizing their excess hardware capacity, their extra storage space, and their bandwidth.
[01:24.200 --> 01:29.600]  And so we formed a decentralized cloud storage network that is highly competitive with, say,
[01:29.600 --> 01:37.420]  an Amazon S3 or Azure Blob or Google Object Store just by incentivizing mass amounts of individuals,
[01:37.420 --> 01:44.760]  data centers, crypto enthusiasts to offer their excess capacity to help build the network.
[01:44.760 --> 01:49.860]  And so in terms of some stats, right, the original prototype for storage was first
[01:49.860 --> 01:58.620]  built in 2014 by Shawn Wilkinson at a hackathon at Texas Bitcoin Hackathon.
[01:58.820 --> 02:04.420]  It's gone through a lot of iterations since then. The key milestone was probably in 2019,
[02:04.420 --> 02:10.040]  we began work on version three of the network after hiring Ben Golub, who is the former CEO of
[02:10.040 --> 02:16.040]  Docker, you know, having built the largest open source community by Linux. And so we launched in
[02:16.040 --> 02:22.680]  March. And in terms of stats, we're at 26 petabytes of capacity. We've done a number of
[02:22.680 --> 02:27.360]  cool things, you know, outside of our early customers, we've actually backed up GitHub
[02:27.360 --> 02:34.400]  through a tool called Git Backup. And that's a pretty cool open repository of data. And we're
[02:34.400 --> 02:39.760]  helping other people share open data sets as well. We have about 8,000 storage nodes,
[02:39.760 --> 02:44.160]  more than 8,000 target users, which are developers that are storing data on the platform,
[02:44.160 --> 02:48.120]  and actually 72,000 unique wallet addresses of people that are participating in our token
[02:48.120 --> 02:55.720]  ecosystem. We've today stored 50 million files across four satellites. And, you know,
[02:55.720 --> 03:00.040]  are really proud to have been the number two project in terms of development activity
[03:00.040 --> 03:07.620]  in the Ethereum ecosystem in 2019, as measured by sentiment insights and consensus media.
[03:07.620 --> 03:13.320]  We have a really awesome partner ecosystem that's driven by a number of open source projects who
[03:13.320 --> 03:18.760]  have integrated with Tardigrade directly, whether for backup tools, or for, you know,
[03:18.760 --> 03:24.200]  second level kind of graphic user interfaces on the platform. One of those that's pretty notable,
[03:24.200 --> 03:29.680]  we'll get into kind of deeper case studies in a second would be MongoDB. We recently launched a
[03:29.680 --> 03:36.620]  native integration into their enterprise tool DevOps manager. So let's get into the fun part.
[03:36.620 --> 03:41.060]  How does Tardigrade work? What's the security model? Why is this a better approach to storing
[03:41.060 --> 03:46.260]  data than on traditional cloud data centers? So the way that Tardigrade works is that there
[03:46.260 --> 03:51.460]  are three peer classes, or really three pieces of software that anybody can run that powers
[03:51.460 --> 03:57.560]  the network. So first off, there's the uplink. The uplink uploads data to the network, encrypting it,
[03:57.560 --> 04:02.560]  splitting it into pieces, and spreading it across nodes. The satellite talks to storage nodes,
[04:03.000 --> 04:08.480]  which are sharing their capacity and monetizing it. The satellite builds reputation around the
[04:08.480 --> 04:12.980]  storage nodes based off of their uptime, their response time, and their statistical
[04:12.980 --> 04:18.820]  and correlation to each other, and then uses that reputational profile to determine where
[04:18.820 --> 04:23.400]  data gets pushed from the uplink. And so the satellite acts as kind of the the key decision
[04:23.400 --> 04:27.680]  maker. It's an open source peer class that anybody can run. We run a collection of them with
[04:28.900 --> 04:32.340]  industry standard service level agreements through Tardigrade, but anyone
[04:32.340 --> 04:37.020]  can run them and they decide basically where the data gets stored. So when you upload the data,
[04:37.020 --> 04:41.180]  it gets broken up into pieces and uploaded in parallel directly to storage nodes without
[04:41.180 --> 04:46.400]  touching the satellite. The satellite's just telling the uplink where to put the data. So let's talk
[04:46.400 --> 04:51.380]  about the journey of a file, what happens when you upload a file to the decentralized cloud.
[04:51.380 --> 04:57.900]  It's actually pretty exciting. So what first happens is the file gets encrypted. We'll get
[04:57.900 --> 05:04.180]  into the standards in a bit. It's AES-GCM256. It then gets broken up into erasure-coded pieces,
[05:04.180 --> 05:09.020]  and we'll get into what that means in just a second as well, and then pushed across statistically
[05:09.020 --> 05:14.780]  uncorrelated endpoints across the world. And so what's really critical about Tardigrade is not
[05:14.780 --> 05:19.780]  only do you have default encryption and default geo-redundancy, right, features that you might
[05:19.780 --> 05:25.960]  pay extra for with alternative cloud storage providers, but you also have statistical
[05:25.960 --> 05:30.260]  and correlation from an ownership of the hardware standpoint and network infrastructure. And so
[05:30.260 --> 05:34.180]  your data, you know, there's not one single provider that could pull the plug on your data,
[05:34.180 --> 05:39.820]  making for a much more resilient cloud storage system. We'll get into kind of how audit and
[05:39.820 --> 05:44.940]  uptime is ensured as well in a second. So in terms of the security differentiators of Tardigrade,
[05:44.940 --> 05:51.980]  there are a number of really interesting pieces that make Tardigrade more secure,
[05:51.980 --> 05:58.860]  more reliant, more reliable than traditional cloud service providers. So first is client-side
[05:58.860 --> 06:03.740]  encryption. So by default, all data is encrypted client-side. This prevents scenarios like the
[06:03.740 --> 06:09.240]  leaky bucket scenario that Capital One faced, where an exposed S3 bucket was then downloaded
[06:09.240 --> 06:13.840]  by everyone and exposed a bunch of customer data. So data is encrypted client-side rather
[06:13.840 --> 06:19.940]  than server-side. It's encrypted at the edge, at the source. For API keys, we embed logic inside
[06:19.940 --> 06:27.620]  of the API keys using a embedded logic structure called macaroons, which was originally formulated
[06:27.620 --> 06:32.480]  by Google. What this means is that instead of, you know, querying an access control list,
[06:32.480 --> 06:39.260]  the API key is actually the access control credential. And so inside the API key,
[06:39.260 --> 06:44.920]  there's embedded logic that can restrict usage of a file from, say, read-write to only read
[06:46.560 --> 06:51.340]  time-bound files to only be read for a certain period of time and is extensible. And so you can
[06:51.340 --> 06:55.640]  actually embed third-party logic inside of it that enables you to do things like require
[06:55.640 --> 07:01.020]  OAuth verification and pass an OAuth or SAML token. So there's some really cool constructs
[07:01.020 --> 07:05.240]  with macaroons that we're playing around with. And today out of the box, we support kind of
[07:05.240 --> 07:12.220]  standard file restriction capabilities. And all the developer tools on Tardigrade are simple.
[07:12.280 --> 07:15.980]  And so it's a really easy, sweet software called libuplink that enables you to
[07:15.980 --> 07:20.520]  connect your applications, object storage to the decentralized cloud.
[07:21.200 --> 07:24.440]  So let's start with encryption. Encryption is really important.
[07:29.080 --> 07:36.880]  Encryption is privacy by default on Tardigrade, and if it was only ratio-coded, it'd be easier
[07:36.880 --> 07:40.980]  to take someone else's file. So in terms of specifications, all encryption, again,
[07:40.980 --> 07:47.360]  occurs at the edge, at the absolute edge of the client. Using the AES-GCM-256 standard,
[07:47.360 --> 07:51.620]  which is a military-grade standard, the encryption, if you went into libuplink library
[07:51.620 --> 07:56.280]  and forked it, it's open source, you could plug in your own encryption if you wanted to as well.
[07:56.400 --> 08:02.480]  It's hierarchically deterministic and it's path-based as well. And so you might have
[08:02.480 --> 08:07.320]  heard of hierarchical deterministic encryption from BIP32, which is the Bitcoin Improvement
[08:07.320 --> 08:12.580]  Protocol 32, which added hierarchical deterministic key derivation for Bitcoin.
[08:12.580 --> 08:19.280]  So you can have one master wallet and sub-wallets. On storage, encryption for files works much the
[08:19.280 --> 08:26.880]  same way. And similar to how on Ethereum or on Bitcoin, your keys are your money. On Tardigrade,
[08:26.880 --> 08:32.280]  your keys in many ways are your data. And so protecting that key is really crucial
[08:33.400 --> 08:37.900]  to the security of the network, and that can be held offline as well.
[08:38.240 --> 08:41.660]  So erasure coding is kind of the next really important differentiator that we have
[08:41.660 --> 08:46.580]  from a security standpoint. What that means is after you encrypt a file,
[08:46.580 --> 08:52.440]  it's broken up into segments. Each segment is broken up into 80 pieces of which you only need
[08:52.440 --> 08:59.320]  today 29 pieces of the 80 to reconstitute the file. And so from a resilience or security standpoint,
[08:59.320 --> 09:04.600]  what that means is that you need 51 uncorrelated nodes with different owners and different geos
[09:04.600 --> 09:09.540]  with different internet service providers to all go offline to put availability at risk
[09:10.140 --> 09:15.900]  at a given point in time. If nodes are constantly measured for uptime, if any one of them goes down,
[09:15.900 --> 09:20.940]  that data is repaired and new parity pieces are created. Erasure coding is also one of the core
[09:20.940 --> 09:25.860]  reasons why we have a performance advantage. So the way that Tardigrade works is instead
[09:25.860 --> 09:30.540]  of a single thread stream, data is streamed in parallel, somewhat like BitTorrent.
[09:30.540 --> 09:38.180]  But erasure coding adds an extra benefit because when you call 80 pieces and you only need the
[09:38.180 --> 09:42.540]  first 29 responders to reconstitute the file, you're always going to get the fastest 29 pieces.
[09:42.540 --> 09:48.360]  Any what we call distributed systems, any long tail responses are basically smoothed out of the
[09:48.360 --> 09:53.820]  distribution due to this cool erasure coding schema. And so this drives, again, both resilience
[09:53.820 --> 09:59.440]  of the data and performance through parallel packet streaming and kind of native concurrency
[09:59.440 --> 10:04.580]  methods in Go. The third piece, which we chatted about a second ago, is the access management piece
[10:04.580 --> 10:09.300]  that's built around macaroons. So traditional cloud storage providers use an access control
[10:09.300 --> 10:15.920]  list or an ACL that's stored in a cloud database to control who has permissions to each file.
[10:15.920 --> 10:20.840]  We've seen a number of devastating attacks with the ACL model, mainly around super user privilege
[10:20.840 --> 10:26.560]  escalation attacks, where someone climbs up the ACL privileges and then changes everyone else's
[10:26.560 --> 10:31.600]  privilege and can create ransomware out of attacks like that. Tardigrade is natively designed to
[10:31.600 --> 10:38.240]  prevent this. All access control happens at the edge and is associated with the macro and with
[10:38.240 --> 10:43.560]  the API key. And so you can actually, again, embed logic into the API key, which determines identity
[10:43.560 --> 10:47.740]  and access management. And so we think that edge-based identity access management alone
[10:47.740 --> 10:54.640]  is a huge security advantage over traditional ACL cloud-based models because it is much more
[10:54.640 --> 11:01.100]  resilient to privilege escalation attacks and to a number of other attacks as well.
[11:01.800 --> 11:06.480]  And so Tardigrade is built by default from the ground up for a trustless environment, right?
[11:07.520 --> 11:12.980]  The idea is that you can store your data on any endpoint, any uncorrelated to endpoint,
[11:12.980 --> 11:18.520]  and it doesn't matter. It's built for zero trust, zero knowledge environment, making it from the
[11:18.520 --> 11:24.020]  ground up much more secure than solutions that are built for trusted environments because,
[11:24.020 --> 11:30.600]  as we know, trusted third parties often tend to be security holes. And so again, we have
[11:30.600 --> 11:35.900]  client-side encryption, we have path-based encryption, all the content and metadata is encrypted before
[11:35.900 --> 11:40.640]  it goes to the satellite, the data storage is distributed so there's not a single point of
[11:40.640 --> 11:46.180]  failure, and all the endpoints are uncorrelated, and all that ties back to the encryption key
[11:46.180 --> 11:52.740]  ownership. And so we think that this is a really exciting model to try and disrupt a lot of the
[11:52.740 --> 11:59.600]  weaknesses that we see in standard object storage models. And so how do you get started with
[11:59.600 --> 12:04.120]  Tardigrade? How do you upgrade your stack today? Well, here are a few ways that you can integrate
[12:04.120 --> 12:09.540]  Tardigrade or the storage network into your stack. One of them that we've seen, one early
[12:09.540 --> 12:16.300]  use case, is around database backups. And so we have tools today for MySQL, Postgres, InfluxDB,
[12:16.300 --> 12:22.280]  which is a time series database, MongoDB, and other distributed databases like Flurry.
[12:22.280 --> 12:31.320]  We have native backup tools that enable you to either dump or schedule and dedupe regular backups
[12:31.320 --> 12:36.120]  of your database onto the decentralized cloud. And a number of companies are really interested
[12:36.120 --> 12:43.140]  in this due to the uncorrelated nature of Tardigrade. So data is stored across 80
[12:43.140 --> 12:49.280]  independent operators, there's no single point of failure from the storage side, and we think that
[12:49.280 --> 12:56.840]  this creates a better security play for backups and for disaster recovery than storing your data
[12:56.840 --> 13:00.020]  on a centralized provider that's going to be correlated with all the other providers.
[13:01.320 --> 13:07.460]  In terms of, you know, the MongoDB integration, we're natively integrated into MongoDB's DevOps
[13:07.460 --> 13:11.580]  Manager tool. And so that's something we're really excited about. We launched that integration
[13:12.300 --> 13:17.720]  a couple of months ago. And if you go to MongoDB's website, if you search MongoDB Tardigrade,
[13:17.720 --> 13:22.760]  there's a great blog post that walks you through the process of basically scheduling backups
[13:23.480 --> 13:29.140]  from DevOps Manager to Tardigrade so that your backups are stored and secured on the
[13:29.140 --> 13:34.400]  distributed cloud. Another great integration that we recently launched was the integration
[13:34.400 --> 13:39.440]  with rClone. So rClone is a really popular, common command line program to sync files
[13:39.440 --> 13:45.520]  and directories. It's often referred to as rSync for the cloud. And so any sysadmin here that's on
[13:45.520 --> 13:50.880]  the call is going to be familiar with rSync. And rClone is a similar tool that enables you to kind
[13:50.880 --> 13:57.080]  of map file systems, you know, basically map commands, whether they're dump commands or any
[13:57.080 --> 14:02.140]  kind of commands to natively integrate with Tardigrade. And we have, again, a native integration
[14:02.140 --> 14:06.240]  with rClone. So if you download the rClone command line suite and go to their website, you'll find
[14:06.240 --> 14:12.360]  that you can just set up Tardigrade just by inputting your API key or your access directly
[14:12.360 --> 14:18.780]  into rClone. Another interesting integration for users that might not be technical that we've seen
[14:18.900 --> 14:24.360]  a lot of managed service providers and just non-technical end users use is our integration
[14:24.360 --> 14:30.460]  with Duplicati. So Duplicati, again, is a GUI-based backup tool. So basically you click on your file
[14:30.460 --> 14:35.020]  system and you choose what you want to back up and it backs it all up. And so it's great for, like,
[14:35.020 --> 14:42.600]  just native desktop backups. And it has a lot of cool features around deduplication and compression,
[14:42.600 --> 14:47.240]  which limit, you know, the actual amount of raw data that gets uploaded, which is more
[14:47.240 --> 14:52.820]  economical than a non-compressed, non-deduped backup. Another really cool thing, which I'll
[14:52.820 --> 14:58.660]  actually show as I stream the workshop, is that, you know, Tardigrade natively supports video
[14:58.660 --> 15:03.540]  streaming today. And so from the command line, you can generate a link that allows you to stream
[15:03.540 --> 15:09.580]  video. It's called Tardigrade Share. And so you can generate an access that's embedded inside of a URL
[15:09.580 --> 15:14.340]  that embeds that macro and logic. You can see here it's a rather long URL string. So you might
[15:14.340 --> 15:18.420]  need to use a shortener if you're going to share it publicly. But it embeds that logic inside of
[15:18.420 --> 15:23.740]  the URL and lets people watch videos and streams it in parallel from the decentralized web. This is
[15:23.740 --> 15:28.860]  something that's really cool and I think really powerful as well. I'm really excited to see where
[15:28.860 --> 15:35.120]  we can start to do things like, you know, map link sharing outputs to decentralized DNS systems,
[15:35.120 --> 15:39.220]  like Unstoppable Domains, Handshake, and some of the other ones that have been mentioned earlier
[15:39.220 --> 15:44.440]  today. I think, you know, decentralized storage with decentralized DNS is going to be something
[15:44.440 --> 15:52.020]  that's pretty cool. We also have great native integrations with a number of hardware providers.
[15:52.060 --> 15:56.880]  And so QNAP, you may have heard of them. They're one of the larger hardware manufacturers out of
[15:56.880 --> 16:03.960]  Taiwan, which there are many. QNAP creates network-attached storage arrays and, you know,
[16:03.960 --> 16:08.940]  you can back those up directly to Tardigrade with a one-click app that also shares any of
[16:08.940 --> 16:13.400]  the excess capacity to storage, monetizing both your storage and your bandwidth. And so if you
[16:13.400 --> 16:18.460]  have a QNAP, a Synology, or Western Digital network-attached storage array, we have documentation
[16:18.460 --> 16:23.760]  that shows how to natively and really easily install an application that both backs up your
[16:23.760 --> 16:29.120]  device to the decentralized cloud and then shares excess capacity to help pay for it. And, you know,
[16:29.120 --> 16:35.440]  that's also, I think, a super cool use case. Finally, we have a great integration, you know,
[16:35.440 --> 16:39.740]  with Kubernetes, and we'll get into kind of a workshop around this in just a second.
[16:39.740 --> 16:45.380]  And so we have a native integration with Valero, which is, again, a VMware-sponsored open-source
[16:45.380 --> 16:50.920]  tool that enables you to back up your Kubernetes configuration object data as well as persistent
[16:50.920 --> 16:56.100]  volumes. And so we'll get into why you might do that, right? You know, as a DevOps manager, you
[16:56.100 --> 17:01.540]  know, for looking at disaster recovery, disaster prevention, it makes sense to have, you know,
[17:01.540 --> 17:07.240]  backup of your cluster on the distributed cloud where it's globally distributed. What that means
[17:07.240 --> 17:11.900]  is that it's really easy to rehydrate your cluster to any compute environment rapidly across
[17:11.900 --> 17:17.160]  the globe with a single backup origin. And so we solve that problem that a lot of developers face
[17:17.160 --> 17:22.260]  around data locality, which is, you know, where do I store my backups? Where do I store my data?
[17:22.560 --> 17:28.040]  Do I store it in U.S. East? Do I store it in U.S. West? Do I replicate it to Asia and Europe?
[17:28.200 --> 17:32.880]  With Tardigrade, data is replicated globally by default, and it's globally available by default,
[17:32.880 --> 17:37.420]  which makes it great for disaster recovery when you need to rehydrate, you know, it could be
[17:37.420 --> 17:40.440]  anywhere, right? Maybe you need to rehydrate to Asia, or maybe you need to rehydrate somewhere
[17:40.440 --> 17:44.740]  in the United States with Tardigrade, you know, one backup solves kind of all those use cases.
[17:45.200 --> 17:49.720]  And so again, right, this is a great platform that was built by developers, really for developers,
[17:49.720 --> 17:55.280]  and really easy to use. All of the kind of the complexity around erasure coding, encryption,
[17:56.140 --> 18:02.360]  audit, repair, and those kind of backend network functions are all abstracted. And so as a
[18:02.360 --> 18:07.500]  developer, you're just looking at kind of a basic, you know, CRUD library, where you can create
[18:07.500 --> 18:12.860]  buckets, put objects in buckets, stream them, delete them, very similar to, say, an S3, but at
[18:12.860 --> 18:18.740]  half the price of S3, you know, with better security, resilience, and often better performance
[18:18.740 --> 18:25.080]  as well, depending on the use case. And so again, super easy user interface, I won't get into how
[18:25.080 --> 18:28.580]  to generate a key for this next demo, we're just gonna assume that that's already happened,
[18:28.580 --> 18:32.060]  where you can create an account and generate an API key in just a couple of clicks.
[18:32.260 --> 18:37.640]  And if you're interested, I recommend you do so. We also drop in S3 compatibility.
[18:37.880 --> 18:42.060]  And so if you, and this is really a great demo that I often show, you can actually reconfigure
[18:42.060 --> 18:47.100]  the AWS command line to talk directly to the decentralized cloud through a gateway hosted
[18:47.100 --> 18:53.080]  process. And so this is a fork of Medio, which provides S3 compatibility for Tardigrade. And so
[18:53.080 --> 18:58.080]  if your application today is using Amazon S3, and you want to migrate to the decentralized cloud to
[18:58.080 --> 19:02.840]  cut your cloud storage bill in half, and have better resilience and performance, you can do that
[19:02.840 --> 19:08.880]  by running the gateway and easily migrate over without having to rewrite any code, which is also
[19:08.880 --> 19:16.620]  really powerful. And so that's the quick overview. Ajit, does it make sense to answer questions now
[19:16.620 --> 19:20.960]  before I get into the hands-on workshop? Or should we wait till the end for questions?
[19:30.380 --> 19:44.800]  Cool. Anyone have any questions? Well, we'll go ahead and get started. And if you have questions,
[19:44.800 --> 19:48.580]  post them in the chat. So for the workshop today, we're going to walk through the process
[19:48.580 --> 19:54.360]  of creating a decentralized storage backend for Kubernetes that uses Tardigrade and Valero
[19:54.360 --> 20:01.460]  toolset to make that possible. And so let's go a little bit deeper in what Valero is. Valero
[20:01.460 --> 20:06.760]  is a tool that enables you to back up and migrate Kubernetes clusters. And so Valero
[20:06.760 --> 20:12.340]  natively uses the Kubernetes API to capture the state of the cluster resources, which makes it
[20:12.340 --> 20:17.280]  easy to rehydrate at any target. And so again, Tardigrade is a great backup option for this tool
[20:17.280 --> 20:21.480]  because it's globally distributed, because it's highly economical, and because it's highly
[20:21.480 --> 20:30.120]  secure, encrypted, and resilient as well. And here's kind of a quick little diagram,
[20:30.120 --> 20:35.220]  by backing up Tardigrade, you can restore your cluster to any compute environment,
[20:35.220 --> 20:40.880]  whether it's cloud or self-hosted globally, really quickly. It's really easy to install.
[20:40.880 --> 20:45.000]  There's a simple install command, and then you point it at your existing kubes environment,
[20:45.000 --> 20:51.580]  and you can back it up. And I'll go ahead and show that off now. And so what I'll do is I'll
[20:51.580 --> 20:57.580]  stream a demo from Ivan, one of our solution architects and engineers at Storage Labs,
[20:57.580 --> 21:02.500]  and he'll walk through that process. But first, in terms of early use cases and wins,
[21:02.500 --> 21:06.040]  we've had a number of customers who already started using Valera to backup their Kubernetes
[21:06.040 --> 21:10.860]  databases, sorry, their Kubernetes instances today. And so what's really great, what we've
[21:10.860 --> 21:15.420]  heard is that backups can capture a subset of the resources, so it's really flexible.
[21:15.420 --> 21:20.400]  You can filter on namespace, or on label, or on resource type. So you can really granularly
[21:20.400 --> 21:29.700]  define what gets backed up. Users also are excited that it backs up the underlying etcd database.
[21:30.840 --> 21:37.260]  So often, other backup solutions don't backup the etcd database, but Valera does. And then also,
[21:37.260 --> 21:42.840]  the resources are exposed to the API servers. And so even if the resources are in separate databases,
[21:42.840 --> 21:47.720]  they can also be backed up. And so for Kubernetes applications that are looking to improve their
[21:47.720 --> 21:52.400]  disaster prevention strategy, this is one piece of a larger puzzle, right? You need to
[21:52.400 --> 21:57.120]  also backup all the state associated with your existing databases and persistent volumes.
[21:57.120 --> 22:01.960]  But this is kind of a really great place to start in tinkering with the decentralized cloud to
[22:01.960 --> 22:08.560]  improve the resiliency of your cluster. And so what I'm going to do is I'm actually
[22:08.560 --> 22:14.920]  stream this demo directly from the decentralized cloud to show you how performant it is. If this
[22:14.920 --> 22:20.840]  doesn't work, if the internet gods shame me, I can switch over. But let's go ahead
[22:20.840 --> 22:28.020]  and get this started. In this video, I am going to show you how to use the Valera storage plugin.
[22:28.020 --> 22:33.700]  Valera is a tool that allows you to backup Kubernetes configurations and persistent volume
[22:33.700 --> 22:40.660]  snapshots. In order to use the storage Valera plugin, you have to create an account in Tably
[22:40.660 --> 22:48.540]  server. You can go wherever Tably server, sign up, create a project, and after you have a project,
[22:48.540 --> 22:54.000]  create an API key for that project. Once you have that, make sure that you write down or you
[22:54.000 --> 23:01.160]  copy and paste that API key because it's the only time that you will see that API key and keep it.
[23:01.440 --> 23:09.420]  So after that, install uplink-cli. That is the command line tool that Tably has for accessing
[23:09.420 --> 23:18.160]  to the network from the command line. So with uplink installed, you call setup. After you select
[23:18.160 --> 23:23.620]  the server where you sign up, in my case it's US Central, select a name or use the default one for the
[23:23.620 --> 23:32.480]  access, grab your API key and set it, and just select a passphrase.
[23:37.820 --> 23:44.020]  Once you did that, you need to grab the access grant that has been generated with this data.
[23:44.560 --> 23:50.520]  The access grant is stored in the configuration file because I haven't specified any configuration
[23:50.520 --> 23:56.880]  file. The uplink has created the configuration file in the default folder. The default folder
[23:56.880 --> 24:03.920]  is in the case of a unit machine in my home directory under local, share, storage, uplink,
[24:03.920 --> 24:10.780]  config file, config.yaml. So I want to grab that access. That is what I need for
[24:12.060 --> 24:19.740]  configuring the developer storage plugin. I copy the access. I am going to export to
[24:19.740 --> 24:25.700]  one environment variable that I am going to name it access, store access.
[24:28.860 --> 24:34.220]  Because I will require that environment variable every time that I need this access.
[24:34.520 --> 24:40.460]  And I will avoid to pollute this demo in every command with this long string.
[24:42.120 --> 24:46.360]  Bear in mind that the API key is not something that you have to share. In my case, I created
[24:46.360 --> 24:51.180]  this API key just for the purpose of this demo. Right after, I will delete it to avoid that
[24:51.180 --> 25:00.660]  anybody can use it for using, obviously, my network. So see my files and create files on it.
[25:03.620 --> 25:13.440]  So the first thing that I am going to do is create a bucket. This bucket is needed because
[25:13.440 --> 25:19.320]  once you set up that, when you specify a backup in Galero, you have to specify a bucket.
[25:19.620 --> 25:25.240]  And the bucket has to exist before doing the first backup. So let's make sure that I have
[25:25.240 --> 25:32.740]  the bucket, uplink.tls. So right now I have this bucket Galero, but I am going to delete it
[25:32.740 --> 25:39.440]  because I want to start it from scratch. I remove the bucket with whatever content it has.
[25:42.590 --> 25:50.190]  Now I don't have any bucket, so I am going to create a bucket that is going to call,
[25:50.190 --> 25:58.010]  I am going to call it Galero. Once I created a bucket, obviously, that bucket is empty.
[25:58.010 --> 26:08.630]  But let's show it. Okay. Now I am going to install Galero in a Kubernetes cluster that I am running
[26:08.630 --> 26:13.610]  in my log. At the same time that I am installing Galero, I am defining a bucket location.
[26:14.090 --> 26:24.230]  The bucket location that I am defining is using the target grade plugin. Okay, so let's
[26:25.970 --> 26:33.390]  install Galero with provider target grade, that is the name of our plugin,
[26:36.810 --> 26:44.930]  and specify the image where we store that provider, that is storage third-party
[26:48.430 --> 26:59.100]  slash Galero. And I am specifying this tag. This is a local image that I have
[26:59.100 --> 27:04.820]  in my local only. This is not available online, but in Docker Hub we have the previous version.
[27:04.820 --> 27:09.200]  We are still working on this plugin, so we are improving, and I am using this one because it's
[27:09.200 --> 27:15.520]  much better. After, I have to specify a bucket. In this case, it's the bucket where I am going
[27:15.520 --> 27:23.960]  to do the backups, that is the Galero bucket that I created right before, and specifically
[27:24.640 --> 27:33.980]  tell to Galero that I am not going to backup as an option, persistent volume as an option.
[27:33.980 --> 27:39.740]  This is because our plugin doesn't support it yet, but hopefully we will support it in the future.
[27:40.200 --> 27:45.400]  And after, so I have to, for this configuration location that I am creating,
[27:45.620 --> 27:51.140]  at the same time that I am installing Galero, I have to provide the access grant
[27:51.140 --> 27:56.800]  that is the only configuration parameter that our plugin requires.
[28:02.350 --> 28:06.350]  Oops, I mistyped the command, but
[28:09.010 --> 28:15.410]  whatever. Oh yeah, and another thing that I have to do is specify no secret,
[28:18.090 --> 28:24.810]  because Galero requires that you specify a secret, or if you don't need it, if you don't need one,
[28:24.810 --> 28:30.190]  you have to specify that you don't want, that you cannot leave it empty. So in our case,
[28:30.190 --> 28:40.850]  our plugin doesn't require it. So now Galero is installed, and I can see that in my cluster,
[28:40.850 --> 28:45.550]  just getting deployment from components
[28:45.550 --> 28:45.910]  components
[28:47.770 --> 28:52.390]  equal Galero from, so from
[28:53.970 --> 28:55.370]  namespace
[28:57.630 --> 29:01.410]  and space Galero, that is
[29:03.710 --> 29:05.810]  components namespace
[29:08.090 --> 29:09.870]  deployment components
[29:15.780 --> 29:21.440]  and deployments of components of Galero namespace of Galero,
[29:21.440 --> 29:28.220]  that's what, this is component. Okay, that is what the installation has created.
[29:31.240 --> 29:34.890]  What I'm going to do for the demo is creating an Nginx service.
[29:35.700 --> 29:40.580]  And this is the service that we are going to do a backup, we are going to destroy it,
[29:40.580 --> 29:44.980]  like simulating a disaster, and after we'll recover from the backup.
[29:46.640 --> 29:53.440]  The Nginx service is something, is an example that it comes with the Galero installation.
[29:53.440 --> 29:57.800]  So Galero has a folder inside of the tar file that has several examples.
[29:58.260 --> 30:03.140]  This is the folder that I copied from the tar file. So let's deploy the
[30:06.660 --> 30:09.840]  the Nginx service.
[30:12.690 --> 30:16.950]  Once I did that, I can see in my Kubernetes cluster
[30:19.070 --> 30:20.310]  that I have
[30:25.160 --> 30:29.100]  they have a namespace that is called Nginx example and I have
[30:33.520 --> 30:39.080]  and I have a service, the Nginx service.
[30:41.100 --> 30:46.960]  So now let's do a backup. But before doing that, let's see if
[30:46.960 --> 30:50.880]  backups, Galero backups get.
[30:52.320 --> 30:59.180]  So this backup get doesn't show anything because we don't have any backup. So let's create one.
[31:09.980 --> 31:11.200]  Galero backup
[31:15.360 --> 31:22.120]  great Nginx backup. I call this backup Nginx backup and I only want to
[31:23.680 --> 31:24.800]  backup the
[31:26.560 --> 31:32.940]  the resources that have the level up Nginx, not everything.
[31:34.240 --> 31:39.740]  So I create the backup. I can do backup get again and my backup is in progress.
[31:40.600 --> 31:44.340]  And I wait a bit more and after it says that it's complete.
[31:44.900 --> 31:49.860]  But okay, what we can do now is see what we have in our bucket.
[31:50.620 --> 31:57.440]  We go away with the uplink ls and just list the, we can list the
[31:58.480 --> 32:04.460]  the Galero bucket. Now you can see that it's not empty. There is a directory
[32:05.920 --> 32:11.940]  that is called backups and with, well it's not a directory because we have keys but there is
[32:11.940 --> 32:15.700]  this key inside of the kubernetes but it's kind of simulating a directory.
[32:16.740 --> 32:25.240]  Nginx backup and we see that under that prefix we have all these files that Galero has created.
[32:25.240 --> 32:32.160]  So great, we have our backup in our target network. So what we are going to do now is simulating this
[32:33.400 --> 32:41.220]  this disaster. For doing that we are going to delete the entire namespace
[32:43.500 --> 32:46.610]  of Nginx, call Nginx example.
[32:49.000 --> 32:55.190]  Oh, a disaster is happening now and that namespace gets deleted.
[32:57.580 --> 33:00.140]  We wait until we finish.
[33:06.030 --> 33:11.350]  And now we are going to see how if we are getting the services
[33:16.380 --> 33:19.180]  the services from the namespace
[33:24.520 --> 33:37.950]  Nginx example. So basically there is no resources found. At the same time if we try to get
[33:38.570 --> 33:49.350]  this namespace from the cluster, so basically it's not found. Okay, that's we are confirming
[33:49.350 --> 33:55.650]  that disaster has happened. Now we are going to restore. Galero has a command that is restore
[33:56.450 --> 34:03.550]  and you have to you can say what you are going to restore. So we are going to restore creating
[34:03.550 --> 34:11.530]  from a backup that is called Nginx backup. That is the backup what we created previously.
[34:12.590 --> 34:24.010]  With a restore. And now Galero restore get says that it's complete. So if we are going now to
[34:24.010 --> 34:29.770]  list this so that is the namespace it should be there and it's there. And after we list the service
[34:29.770 --> 34:36.810]  it should also be there and it's there. So we have recovered our Kubernetes configuration from
[34:36.810 --> 34:44.930]  the delegate network. Okay, but now what we can do as well is at some point you don't want this
[34:44.930 --> 34:57.070]  backup anymore. So we can delete the backup. Sorry, with Galero backup delete and you have to specify
[34:57.070 --> 35:06.110]  the name Nginx backup. And after it asks for confirmation we confirm and after we do Galero
[35:06.110 --> 35:17.390]  backup get we don't have any backup. So basically with this we unregister this backup so the backup
[35:17.390 --> 35:23.230]  is not available anymore in Galero. But obviously we would like to know if those files are stored
[35:23.230 --> 35:31.290]  has been deleted by Galero from our delegate network. Let's see that. So for that reason
[35:31.290 --> 35:32.990]  I am going to list again
[35:35.810 --> 35:42.860]  my backup, my Galero backup, and now it's empty. So basically everything works as expected.
[35:43.170 --> 35:49.350]  I hope that you enjoyed the demo and I will encourage you to try our Galero plugin with
[35:49.350 --> 35:57.750]  our great delegate object storage decentralized object storage network. See you next time.
[36:00.000 --> 36:05.860]  Okay, thank you Ivan. And again that was streaming directly from the decentralized cloud
[36:06.500 --> 36:13.320]  which I think is pretty neat and pretty telling of some of the capabilities of Tardigrade.
[36:13.720 --> 36:20.060]  And so with that, that's the conclusion of my presentation and our Valero workshop for backing
[36:20.060 --> 36:25.500]  up Kubernetes data to the decentralized cloud. Does anyone have any questions?
[36:49.690 --> 36:51.830]  Looks like I see one popping up in the chat.
[36:54.470 --> 37:00.550]  If anyone here is a developer, questions in Twitch. I don't know Ajit if you can rattle
[37:00.550 --> 37:05.590]  those off, I'd be happy to answer them. But in the meantime, if anyone here is a developer,
[37:05.590 --> 37:12.070]  you can get started with Tardigrade at documentation.tardigrade.io and we have a
[37:12.070 --> 37:17.930]  number of walkthroughs on the website around just basically uploading data, sharing data,
[37:17.930 --> 37:23.230]  streaming it on the internet, scheduling backups with databases, creating graphic user interfaces
[37:23.230 --> 37:27.730]  around that data. You can find all of those walkthroughs and more on the documentation for
[37:27.730 --> 37:49.740]  Tardigrade. No problem. So with that, that means the presentation went well. I answered everyone's
[37:49.740 --> 37:54.680]  questions. And if anyone else has any other questions after the call, you can email me
[37:54.680 --> 38:02.080]  directly kevin at storj storage.io. And we're always looking for partners and for developers
[38:02.080 --> 38:07.720]  who want to build the next generation of cloud applications on the decentralized cloud.
[38:07.720 --> 38:12.860]  We're happy to give you the white glove treatment and help you get building or migrate your
[38:12.860 --> 38:18.120]  application to Tardigrade. So thanks again. And thanks again for Ajit for hosting me.
[38:18.120 --> 38:21.940]  And I hope everyone has a great afternoon and happy Friday. Happy almost weekend.