Hi, how are you doing today? I am your host Rich here on behalf of Rich TV Live with our very special guest, the chairman of Fury Goldmines, symbol F-U-R-Y on the Toronto Stock Exchange and the New York Stock Exchange, Ivan Bebek. How are you doing today, Ivan? Doing very well. Thank you. Thank you for joining us. Very excited for you to be here with us today. Very excited about learning more about your company. I have a few questions for you. First and foremost, Fury Goldmines is a gold exploration company that is positioned in three prolific mining regions in Canada. Can you tell us a little bit more about the company and your high-grade assets as well a little bit about your experience? Great. Thank you. Great to be here. I've been doing this for 21 years and I've been a gold bug that whole time. My goal since I've entered the business was to go and find some of the biggest gold discoveries in the world and I feel Fury offers that opportunity in three different places and it's something that's the best thing I've been part of on the gold side. I've had some tremendous successes. The first company our group created was called Keegan Resources, went from $0.49 to $9 per share, $5 million market cap to about a billion dollar market cap in a period of about four years and that's the kind of returns and that's why I'm a gold bug because we're looking for those share price returns. We followed that with a company called Keegan where we drilled 100 holes in Mexico in the bear market and we came up with an asset sale. We sold the company with 67 cents a year before we sold it. We sold it for 350 a share to Agnico Eagle and if you hold the shares of Agnico for 14 months after that transaction, they would have traded around $10 per share. So this is the kind of returns we're chasing and that's why we're looking for gold in Canada. Canada is the best jurisdiction as far as I'm concerned. We can raise all our money at 40% or 80% above our spot price because of mechanism the government allows us to do it and we've got some of the best assets. We've got two assets, Homestake Ridge in BC, million ounces of about 7.5 grams gold which is really high grade and one of the most prolific regions were some of the largest gold mines in the world have been found such as SK Creek. We believe that this is highly underexplored and there's a lot of room for it to get bigger and we're about to show that to the world here in the coming weeks. Eau Claire is in Quebec, number one place globally, you get to raise money at 80%. There's a million ounces of gold that a company drilled in one spot for 25 years and that's running about 8 grams per tonne. Again, extremely high grade and when I say high grade, I'm talking about profitability and appeal for investor share price performance. In that deposit, they never stepped away from the million ounces of high grade and we just did that two weeks ago and we see this incredible expansion on basically day one on the first hole out of a massive drill program we just started. And thirdly, Committee Bay, this project here is a huge gold greenstone belt. It's a piece of land up in the Arctic. It's a belt because there's a certain type of rocks that have a lot of gold endowment 300 kilometers long and we've sampled the entire 300 kilometers. We spent $60 million in the last five years getting closer to discovery up there. There's a bit of cover on it so you need to add a bit of science. We've used cool things such as artificial intelligence and so on. But the team we have backing us is really the secret weapon. They're all former Newmont global experts. Newmont's the largest mining company in the world, gold mining company in the world. And these guys have put together this portfolio. So when I talk about fury and when I think about fury, when you think about fury, you have to think really big and not just because we're going to find big mines, but we're going to try to generate those share price returns for investors. Because the second phase of a success that we're going to try to create is going to be to buy producing mines and actually turn our mines from explorers into producers. And we put a CEO in place, Michael Timmins, who comes from Agnico Eagle, amazing guy. I met him when they were buying our last company and he's leading that charge. And he was at Agnico Eagle when they went from one mine to nine mines in a 15-year period. That was an extreme growth. Agnico went to $100 per share. And so that's kind of the thought behind fury where we're coming from. The capabilities are really strong and the portfolio is awesome. And all three projects are in a very mature stage of massive discoveries that could be made here in the coming months. Now, you mentioned three projects. Which project are you the most excited about and why? That's like asking me which is my favorite child if I have three children and I have two and I couldn't tell you, I love them both equally. I love Committee Bay for the scale. It is actually a gold bug or a gold explorer's dream. You can make a few 10 million ounce discoveries up in that part of the world. It would be incredible. However, Eau Claire is starting to show us a lot more potential away from the deposit that we're going to make bigger this year. And that's what's really got my attention as of lately. Big land position, gold everywhere. The group before never ever gave it the proper exploration to go see if it's there. It's in a part of Quebec where some of the largest gold mines in Canada occur. And we have about seven targets that we see that will get into this summer that could possibly compete with that Committee Bay kind of huge scale opportunity. And then the third one, Homestake Ridge. It's something that we've explored for a few years. Just turn the corner on it. You'll see in the coming weeks, it has a chance now to compete with the other two. So Committee Bay is my first, but the other two are close behind. Company has multiple drill program scheduled throughout the year. Can you talk a little bit about your plans for advancing your entire portfolio of assets in 2021? Sure. Drilling is the number one way to perform as a share price. And that's the only way we're going to get rich as investors. And so we're going to do probably well over 100,000 meters of drilling in the next 18 months. About 80 to 100,000 meters of that will be this year alone. The drill is there's two drills training as I'm talking to you today. That is that is the way we're going to advance our projects. Before we say development, before we talk about building mines, you have to know how big they are. And the first two that have really advanced assets that could be mines today, according to some economic studies we've put out, these ones actually are looking like they could get double or triple the size. It would be the big miss to build the mine before you know how big it is because you have to know how big of a plant to build, right? So from us, you're going to get drill results every month for the next 18 months. Every month, we're going to provide a lottery ticket type of a drill hole that may or may not give us that lottery type of return. And every month right now, I know categorically, after the first drill results came out of Eau Claire, that Eau Claire is going to get bigger. We're going to go into a bull market with our first gold asset. We're drilling, getting bigger every month for the next 12 months. Wow, that's impressive. A lottery drill program, that's interesting. Never heard that before. I like that. What differentiates fury gold mines from other Canadian based gold producers and explorers? Great question. And a lot of people will be critical towards it because we've broken the mold. And what we're doing, it's a very big company way of thinking like a major. We're putting together a pipeline, three projects that could all give us a home run for different reasons or the same reasons in terms of discovery. As I mentioned, that lottery ticket kind of drill hole each month, we will provide that possibility for shareholders month after month for a very long period of time across all three projects. The biggest differentiator behind us, outside of a very established branded reputation as a group since 2005 for the last 15 years and the fact that we found a mine and built a mine previously, it's the caliber of our technical team and the aggressive nature of our exploration programs we're taking. If you have a very good technical team in terms of the geoscientists that work for you, you can take bigger swings and we're not shy. We are bold. We are ready to go out and take those huge swings because you don't get paid well and our business plan doesn't work. You don't make money as a shareholder if you're conservative and drill safe holes. You make money for drilling the holes that are a kilometer away from your deposit or are going after brand new discoveries and that's really what differentiates us. We're more aggressive than all of our peers and we have different capabilities. And lastly, we cannot just find it, we actually have people in place that could build the mines that we're going after which will provide a big premium on anything we make as a discovery going forward. Now you mentioned on it, a little bit about your leadership. Fury's leadership has a track record of success starting with yourself, many, many 20 over 20 years of experience in this industry. Who are your key members and what experience do they bring to the table? Great question, touched on them a little bit. Mike Timmons, the CEO that we brought in and he was drawn in by the assets that we have. Came from Agnico Eagle was a superstar on the corporate development side. He was building their first mine and then he was in a corp dev acquiring the additional nine mines they had that made Agnico what it was today. So he has the training and the background by I'd argue the most profitable gold company in the world. It trades at $90 a share. I mean, that kind of understanding of how to create that value in the share price by somebody that can actually build mines is rare. That's the first guy, Michael Henriksen, our SVP expiration. He was a global structural geologist for Newmont. Him and his colleagues were drilling a mine called the Hoffo in Ghana. It was about eight million ounces. His team was challenged to see if they could make it bigger or if Newmont would sell that deposit. It grew to 25, 30 million ounces under his watch. And so he's a legendary mine finder. He was called the Gold Ninja when he was at Newmont, which is really great. But the smartest thing about Michael Henriksen, the SVP expiration is he's smart enough to surround himself with different world experts with different science backgrounds that complement what he knows versus try to do it all himself. And the third person that makes this happen is our CFO, Lindsay. She's Lindsay Sherry. She's amazing because she comes from Gold Corp. Gold Corp was the largest gold company in the world and she was there out there being the controller and she was there through the financial growth. So we have the ability to grow quickly, to grow large and to perform without any hiccups along the way. The mentality is think big, start small and think big. And when I say start small, I mean start where we are now with a really good package of assets. Think really big of what it can become and have the team to go execute behind it to make it happen. And then just on my record, I've raised close to a billion dollars in the companies I've been involved in. They've all been successful to date. And so, you know, for me, it's how can we do things better over a period of 20 years? The formula is really good. The team's really strong and the opportunity has never been better aligned with the gold market that's in front of us. Now, Rich TV Live is simulcasting in countries all over the world. We're well over 90 countries. I always want to remind everyone that Rich TV Live is strictly for education and entertainment purposes. Always do your due diligence, always do your research before you invest in anything that we talk about and discuss on our show. If you guys liked the video, please smash the like button, comment on the video, share the video everywhere and subscribe. I really liked this company, in my opinion, just learning from you directly and doing a little bit of research. It seems to me like it has incredible future. Now, what should special interests be focused on by investors? If an investor had to look at one specific thing or a few key catalyst over the next couple of months, what would they be? Drill results every month for the next 18 months. Drill results that could make each mine or deposit much bigger or make that world-class discovery. The fact that we offer that every month there'll be drill results out of this company. And that's the most unique thing about it because of how much drilling is gonna happen and how long we're gonna be able to offer that kind of huge return. So it's probably one of the most catalyst-driven gold companies, exploration companies that I know of globally right now. So that's what I focus on, absolutely. And our investors love to get in contact with companies. A lot of times there's other companies, other gold companies that are going to see these videos that might be wanting to get in contact with you as well. What's the best way for potential joint venture partners, investors, shareholders to get in contact with you, Ivan? I would say our website, www.furygoldmines.com. Our email address is info at furygoldmines.com, I-N-F-O-A-T-F-U-R-Y-G-O-L-D-M-I-N-E-S.com. And I'm quite active on LinkedIn personally. And if anybody has a question wants to reach out to me directly, Ivan Bebic on LinkedIn, please reach out. And I do add a lot of commentary along the way with a lot of our catalysts as they go forward. And so look forward to hearing from anybody that wants to know more. That's fantastic. Well, thank you so much for joining us today. The chairman of Fury Goldmines, symbol F-U-R-Y in Canada and the United States, Ivan Bebic, thank you for joining us today. Thank you for having me, great pleasure. My pleasure, thank you for watching. If you guys are not winning, you're not watching. This is Rich from Rich to Be Live with Ivan Bebic, the chairman of Fury Goldmines. Have a nice day.


Hello everybody, welcome to the introduction to SIG Cluster Lifecycle. My name is Justin Sanababra. I am one of the SIG Cluster Lifecycle co-leads. I'm also a software engineer at Google. My github handle is just an SB. Lubomir and myself are going to be giving this presentation together, but we are representing the work of a great many people within the SIG. Hello, my name is Lubomir Ivanov. I'm a sequence lifecycle co-lead, software engineer at the VMware open-source program office, and my github handle is Neolit123. So here is what we are going to talk about today. We are going to explain what is SIG Cluster Lifecycle, what is the mission and philosophy of the special intense group. Also, we are going to cover the stack of sub-projects that we maintain. In particular, we are going to highlight three of them. These are Quaster API, Component Config and ImageBuilder. And finally, we are going to show you how you can get involved into contributing to the special intense group. What is SIG Cluster Lifecycle? In Kubernetes, we have special intense groups, also known as SIGs, and SIG Cluster Lifecycle is one of those. All the SIGs also have charter documents, and a charter document is something that defines what are the goals and non-goals of a particular group. SIG Cluster Lifecycle's objective is to simplify the creation, configuration, upgrade, downgrade and tear down of Kubernetes Quasters and their components. As a special intense group, you also have a vision to develop the tooling necessary to build a highly automated metacloud. A metacloud here means imagine something that is a Kubernetes cluster that can be deployed on any cloud provider. We want to avoid the pitfalls of the past because we had some unsuccessful experiments in the past. Everything should be declarative, API-driven, Cades-like deployment type of style, and managing these Quasters should be as easy as managing the Kubernetes objects like pods. That is a familiar button to everyone. We want to make the 80% use case simple and the 20% use case possible. Always consider a simple configuration available to everyone, but there has to be this advanced configuration that is still possible to the rest of the users. We also want to commoditize or standardize Cades-Quaster deployments. So if somebody is looking at your cluster, eventually they are going to know that, okay, this is following a standardized way, a standardized pattern for Quaster deployment. So on this slide we have a diagram of the current stack of tools that we are working on. At the bottom we have FEDCD-ADM. FEDCD-ADM is potentially a manager of FEDCD-Quasters, a CLI and a library that is working progress potentially consumable by high-level tools. On top we have CUBE-ADM. CUBE-ADM is a Quaster boost wrapper, as a lot of people should know already. A Quaster-ADM is a project where we are working on standardizing the way others are deployed in a cluster and they are managed as a life cycle. How do you upgrade them, how do you downgrade them? Quaster API, a lot of people should be familiar with Quaster API as well. This is a project where you can create Quasters using a declarative model. It's very similar to the Kubernetes declarative patterns. So if you combine these tools, you can potentially produce artifacts that you can then feed to an image builder. An image builder can create a virtual machine image for you, and the virtual machine image can then be fed to the Quaster Provisioner, which is a layer on top. The Quaster Provisioner can create you a Quaster that uses this virtual machine image. Finally, on the left we have the component config. The component config's idea is that we can configure all these components on the right side with a declarative API that is very similar to the Kubernetes API and in fact it uses the same machinery. As a group we are also trying to follow a particular philosophy, and that is arguably the UNIX philosophy. We want to make each program do one thing and do it very well. The boundaries between the separate projects should be clear and there should not be ideally that much overlap. Every computing infrastructure project that initially meets one's needs will eventually expand in scope to only meet several needs poorly. This is something that we have to avoid. We also expect the output of every program to become the input of another program and combining all the tools that we have we want to create this Voltron-like software. On this slide you can see a Pseudo Voltron example. It's an immutable node update type of scenario. So on the left side we have a CI that triggers a rebuild of artifacts, notifies an operator to update costar manifests that are potentially consumed by the costar API. The costar API can then perform a rolling update, then a bootstrap provider, which in this case is QBADM to trigger the new nodes to join the costar. During KubeCon AU 2020 we created a survey to let our users get back to us with some feedback. The main takeaways are users are still struggling to keep up with the release cadence of Kubernetes. Currently there is a proposal to shift to three releases per year processing instead of four. This seems to be a very favorable option by all of the users. The upgrade process can be difficult due to core API changes and deprecations and removals. Basically, we saw a number of comments about this as direct responses in the survey itself. Ubuntu as an operating system for VMs, Docker as a container runtime using docker shim in this case, and Calico as a CNI appear to still be the most used projects in their respective areas. We also saw that projects like costar API and QBADM are gaining more traction and are getting positive feedback from the users, but there is still desire to improve the overall UX of these projects. In this section we would like to highlight some projects that we are currently working on. Okay, I'm going to highlight another one of our projects, the cluster API. Cluster API is building a declarative Kubernetes style API for creation and management of clusters. It also manages some of the infrastructure that is cluster scoped, things like networks or IAM policy from your cloud provider. It's focused around a declarative specification of the machines that become the nodes of the cluster. Some important things to understand. This is different from the Kubernetes cloud provider which provides workload cloud resources like volumes and load balancers. This is provisioning similar infrastructure but for the cluster itself. And one of the important design decisions was that the specification of a machine is immutable. But it's interesting in that cluster API still provides the ability to upgrade the cluster. You may be asking yourself, how is this possible? How can the machine be immutable? Yet the cluster can be upgraded and therefore be mutable. And the answer is that we follow a similar pattern as Kubernetes does. We don't just want to use Kubernetes CRDs, we want to follow the Kubernetes API design patterns. And in Kubernetes, there is indeed a similar design pattern. Pods are immutable, but pods are wrapped by replica sets which runs a number of them. A replica set remains immutable, but a deployment creates mutability over those replica sets. It is able to create a new replica set and scales down the old one and scales up the new one. So we use exactly the same pattern in cluster API. A machine like a pod is immutable. A machine has a number of replicas in a machine set, like a replica set. And a machine set is still immutable, but a machine deployment can create a new machine set and scale down the old machine set and scale up the new one. A machine deployment is just like a deployment. And that's how we can achieve mutability at the machine deployment level. The machine is the same CRD, whether this is on AWS or GCP or VMware. And there's an analogy here to storage classes in Kubernetes. There is similarly a machine class. A machine class is a Kubernetes object that describes attributes of the machine that are specific to that cloud provider, just as a storage class describes attributes that are specific to a particular storage backend. Cluster API is a newer API, and we've actually developed our thinking around this design pattern over time. Machine class objects are actually typed objects. It has a different kind on AWS than on GCP. AWS is an AWS machine template. GCE is a GCE machine template. This allows for the fields of a machine class object to be specific to the cloud or infrastructure provider. And that allows us to get richer type checking and validation than we do in a storage class, where a storage class has the same kind across all the storage backends. So, not only reuse, but also evolution of the Kubernetes design patterns. So let's talk a little bit about the cluster API roadmap. Cluster API is still in alpha, so how does it get to beta? Generally, the main goal is to get it into widespread real-world use and continue to get feedback on whether our expectations match how this thing is used in production. More automation also helps with this goal, both automation of testing and of the project processes. But the next couple of alphas are going to focus on some of those blockers, robustness of the control plane. A few features like auto-scaling and spot instances. Some improvements to the primary user-facing tool called cluster CTL. And in the alpha after that, resiliency of the nodes, extensibility of load balancing, using the latest features from some of the other SIG sub-projects. In order to get to beta, the really big thing we need is better documentation which goes hand-in-hand with more feedback from real-world users like you. Also, getting it integrated into some of those higher-level tools. So, for example, COPS is planning to support cluster API initially for the nodes. And getting the existing Kubernetes E2E tests using cluster API on GCP and on AWS. To learn more about the cluster API, you can join a deep-dive session we have about it here at KubeCon NA 2020. It's going to be presented by Cathy Gimangi and Carlos Panato on Friday, November the 20th. Another project that we wish to highlight is component config. Component config is a Kubernetes-style API for configuring components. And component config is trying to solve some problems. The first one is that the core Kubernetes components are not consistent in how they are configured. They use a lot of flags. And oftentimes, the flags across different components that do exactly the same thing have different names. The solution for that is that the core components should implement component config. And in fact, most of the core components have already started doing that. Another problem is that it's pretty hard to write a case-like component with declarative config. So adding a component config itself is not that easy. So the solution for that is that we should factor common logic for component-related code in the repository designated for that. That is component-based. And it's a toolkit. It's going to make it easier to write a new component that immediately implements a component config that uses Kate's API-style of configuration. And existing components should be retrofitted to use the same toolkit. Component config gives us a lot of benefits. It has maintainability. So when a component has a flag set that grows over 50 flags, configuration becomes painful. Upgradability. So for upgrades, versioned configuration is arguably easier to manage than flags, since flags are unversioned. Programmability. Configuration expressed as JSON in YAML objects are also consistent manipulation, templating, patching and introspection. And also possibility. Many types of configs simply cannot be expressed as key value pairs. And finally it's also declarative. Open API information can be exposed using component config and used for generating documentation for your config. To learn more about component config, you can watch this talk that Lucas Kallström gave at a previous QubeCon. And in this talk you can actually see some of the details, implementation details around how we are actually implementing component config in existing components or how do we want future components to implement it. In Kubernetes we have a working group that is called component standard. It's a combined effort between SQL Still Lifecycle and CKPI Machinery trying to tackle some of these problems around component config. To get engaged or find more about it, you can follow these links. Another project that we wish to highlight is ImageBuilder. ImageBuilder is essentially a tool for building virtual machine images not to be confused with container images. It includes Ansible and Packer scripts which are well supported by VMware, Microsoft and other companies for creating cluster API machine images. The current list of supported operating systems include Ubuntu, CentOS, Real7, Photon, Amazon, Linux and Flatcar support is coming soon. ImageBuilder is targeting VMware, AWS, Azure, QMU and Azure as providers of infrastructure. The project has also started working on a conformant test suite which uses GOSS which is a YAML-based server spec alternative tool for validating server's configuration. The repository of the project also includes some other tools such as CubeDeploy which is still used by cops for creating images for AWS. Config ADM which is a tool for generating cloud in it and cache for configuration of virtual machine images. Here are some of the goals of the ImageBuilder project. Provide a consistent tooling for all approaches for building images so that we can create more standardized, reusable and testable images. Make it easier for downstream consumers to customize their own images and keep their customization up to date. Testing of images to verify conformance using tools like InSpec and GOSS. Release of images for different cloud operating system combinations with regular updates. ImageBuilder is a fairly new project so we have a big roadmap for it. The COI still offers one of the goals is to get it to beta. PR testing for builds on AWS, GCP and QMO are planned. Azure is already running on PR submits. Flood card support and window support are also on the roadmap. Conformant testing and testing suites. Stress testing for long rotation and immutability. Submissions to the Kubernetes test grid which is the tool we use to monitor end-to-end tests. And finally image publishing, signing and release which is similar to a way the official Kubernetes containers are promoted today. To learn more about ImageBuilder you can see our deep dive session here at KubeCon NA 2020 is going to be on Thursday, November 2019 presented by Moshe Emerman and Tushar Agarwal. I wanted to talk a little bit about how you can get involved. Most of the projects we've described are not yet in GA. KubeDM is some of the high-level provisioning cluster provisioning tools are, but otherwise the projects are in beta, in alpha or even pre-alpha. So we need your help. And I'd suggest this is also an opportunity. Sometimes as a Kubernetes contributor it can feel like everything that can be done has either already been done or there are 10 existing issues stating why you can't do it. That is very much not the case in SIG cluster lifecycle. There's a lot of work still to do that work is very concrete and we are very oriented around encouraging contributors. Specifically we have some onboarding documentation which is a great place to start along with our community page. Many of the sub-projects are excellent at triaging issues. They label issues with good first issue or help wanted to try to steer you to issues that don't require the in-depth knowledge that you'll likely gain over time. A great way to get involved is with documentation or even just trying out different things and reporting any issues you encounter. There are a number of Zoom meetings, there's an overall SIG cluster lifecycle meeting bi-weekly and many of the sub-projects are owned by weekly meetings as well. So please attend, ask questions introduce yourself introduce yourself on Slack. There's a very active Slack channel where you can find people at all hours of the day and night. If you're not yet a Kubernetes contributor I encourage you to attend the new contributor sessions that are run by SIG contributor experience. In general the Kubernetes community philosophy is that you earn your place at the table by chopping wood and carrying water by taking on the tasks that need to be done. So everyone is expected to get involved and the flip side of that is that you are therefore welcome and encouraged to get involved. We have reached the end of the presentation. Thank you very much for your time and now we can have a Q&A session.


In this study, the authors provide a global overview of SARS-CoV-2 genome sequencing and estimate the proportion of cases sequenced and time to genome upload. They identify disparities and highlight the need to strengthen surveillance in lower and middle-income countries. This article was authored by Anderson F. Brito, Elisaveta Semenova, Gittys Judas, and others.


From Santa Clara, California, in the heart of Silicon Valley, it's the Cube. Covering Altitude 2020, brought to you by AVIATRIX. Our next panel is the AVIATRIX certified engineers, also known as ACES. This is the folks that have certified their engineering, they're building these new solutions. Please welcome Toby Foss from Informatica, Stacy Linear from Teradata, and Jennifer Reed with Victor Davis to the stage. I want to know where, oh there it is! I was just going to ask, where's the jacket? You got to show it, maybe. Where's your jacket, Toby? I forgot it. Okay. You get it, that's awesome. I was just going to, I was just going to rib you guys and say, where's your jackets? And Jen's got the jacket on. Okay, good. Love the AVIATRIX ACES pilot gear there, above the clouds, soaring to new heights. That's right. So guys, AVIATRIX ACES, I love the name, I think it's great, certified. This is all about getting things engineered. So there's a level of certification, I want to get into that. But first, take us through the day in the life of an ACES and just to point out, Stacy's a squad leader, so he's like a... Squadron leader.  Jennifer, we'll start with you. Sure, so I have actually a whole team that works for me, both in the North America, both in the US and in Mexico. And so I'm eagerly working to get them certified as well, so I can become a squad leader myself. But it's important because one of the critical gaps that we've found is people having the networking background because you graduate from college and you have a lot of computer science background, you can program, you've got Python. But networking and packets, they just don't get. And so just taking them through all of the processes that it's really necessary to understand when you're troubleshooting is really critical. And because you're gonna get an issue where you need to figure out where exactly is that happening on the network, you know? Is my issue just in the VPC, is it on the instant side, is it a security group or is it going on-prem? And is it something actually embedded within Amazon itself? I mean, I troubleshot an issue for about six months going back and forth with Amazon and it was the VGW and VPN because they were auto-scaling on two sides and we ended up having to pull out the Cisco's and put in Aviatrix so I could just say, okay, it's fixed and actually help the application teams get to that and get it solved. But I'm taking a lot of junior people and getting them through that certification process so they can understand and see the network, the way I see the network. I mean, look, I've been doing this for 25 years when I got out, when I went in the Marine Corps that's what I did and coming out, the network is still the network but people don't get the same training they got in the 90s. Well, it's just so easy to just write some software. The network takes care of itself, right? These software guys. I know, it's 60 desks. Toby, I'll come back to that. I want to come back to that problem solved with Amazon but Toby. I think the only thing I have to add to that is that it's always the network fault. As long as I've been in networking it's always been the network's fault and even to this day, it's still the network's fault and part of being a network guy is that you need to prove when it is and when it's not your fault and that means you need to know a little bit about a hundred different things to make that work. And now you got a full stack DevOps you got to know a lot more times than another hundred. And these times are changing, yeah.  I get that right. What is a squadron leader first? Can you describe what it is? I think it's probably just leading all the network components of it but I think from my perspective when to think about what you asked them was it's about no issues and no escalation so if my day is like that, I'm happy to be out there. That's a good outcome. That's a good day. Yes, it is. Is there a good day? Is there a good day? Well, you just said you had a good day with Amazon. Jennifer, you mentioned the Amazon thing. This brings up a good point. When you have these new waves come in you have a lot of new things, new use cases, a lot of the finger pointing it's that guy's problem, that girl's problem. So how do you solve that and how do you get the young guns up to speed? Is there training? Is this where the certification comes in? This is where the certification is really gonna come in. I know when we got together at re-invent one of the questions that we had with Steve and the team was what should our certification look like? Should we just be teaching about what Aviatrix troubleshooting brings to bear? Like what should that be like? And I think Toby and I were like, no, no, no, no. That's going a little too high. We need to get really low because the better someone can get at actually understanding what's actually happening in the network and where to actually troubleshoot the problem, how to step back each of those processes.  Because everything is abstracted in Amazon and in Azure and in Google. It's abstracted and they have these virtual gateways. They have VPNs that you just don't have the logs on. And so you just don't know. And so then what tools can you put in front of them of where they can look? Because there are flow logs. Well, as long as they turned on the flow logs when they built it, you know? And there's like each one of those little things that, well, if they had decided to do that when they built it, it's there. But if you can come in later to really supplement that with training to actually troubleshoot and do a packet capture here as it's going through, then teaching them how to read that even. Yeah, Toby, we were talking before we came up on stage about your career. You've been networking all your time. And then, you know, you're now mentoring a lot of younger people. How is that going? Because the people who come in fresh, they don't have all the old war stories. They don't, they don't. They talk about, you know, that's never fall. I walk in bare feet in the snow when I was your age. I mean, it's so easy now, right? They say, what's your take on how you train the young people? So I've noticed two things. One is that they are up to speed a lot faster in generalities of networking. They can tell you what a network is in high school level now where I didn't learn that till midway through my career. And they're learning it faster, but they don't necessarily understand why it's that way here. You know, everybody thinks that it's always slash 24 for a subnet and they don't understand why you can break it down smaller or why it's really necessary. So the ramp up speed is much faster for these guys that are coming in, but they don't understand why and they need some of that background knowledge to see where it's coming from and why is it important. And that's old guys, that's where we thrive. Jennifer, you mentioned you got in from the Marines. Tell us about when you got into networking, how, what was it like then and compare it now? Oh my God. It's almost like we heard earlier static versus dynamic. Don't be static. Back then, you just set up the network, you got a perimeter. Yeah, no, there was no such thing.  And you know, we had Token Ring. And I had to set up Token Ring networks and figure out why that didn't work because how many of the things were actually sharing it. But then actually just cutting fiber and running fiber cables and dropping them over shelters to plug them in and oh crap, they swung it too hard and shattered it. Now I gotta figure eight polish this thing and actually shoot light to see if it works. I mean, that was the network, crimp five cat five cables to run an ethernet. And then from that to setting up the network switches, dumb switches, like those were the most common ones you had then actually configuring routers and logging into a Cisco router and actually knowing how to configure that. And it was funny because I had gone all the way up and was a software product manager for a while. So I've gone all the way up the stack and then two and a half, three years ago, I came across to work with Entity Group that became Victor Davis, but we went to help one of our customers, Avis. And it was like, okay, so we need to fix the network. Okay, I haven't done this in 20 years, but all right, let's get to it. Because it really fundamentally does not change. It's still the network. I mean, I've had people tell me, well, when we go to containers, we will not have to worry about the network. And I'm like, yeah, you don't, I do. Yeah, yeah, yeah. And then with this program abilities is really interesting. So I think this brings up the certification. What are some of the new things that people should be aware of that come in with the AVHRX-A certification? What are some of the highlights? Can you guys share some of the highlights around the certification? I think some of the importance is that it's, it doesn't need to be vendor specific for network generality or basic networking knowledge. And instead of learning how Cisco does something or how Palo Alto does something, we need to understand how and why it works as a basic model and then understand how each vendor has gone about that problem and solved it in a general. That's true in multi-cloud as well. You can't learn how cloud networking works without understanding how AWS, and Azure, and GCP are all slightly the same, but slightly different and some things work and some things don't. I think that's probably the number one take. I think having a certification across clouds is really valuable because we heard the global SI as you help with the business issues. What does it mean to do that? Is it code? Is it networking? Is it configuration? Is it AVatrix? What is the, I mean obviously AVatrix is the ace certification, but what is it about the multi-cloud that makes it multi-networking and multi-bender and what is it? Easy answer is yes. Yes, it's all of us. So you gotta be a general. Let's get your hands in. You have to be. Right, and it takes experience because it's, every cloud vendor has their own certification, whether that's SysOps and advanced networking and advanced security or whatever it might be. Yeah, they can take the test, but they have no idea how to figure out what's wrong with that system. And the same thing with any certification, but it's really getting your hands in there and actually having to troubleshoot the problems and actually work the problem and calm down. It's going to be okay. I mean, because I don't know how many calls I've been on or even had AVatrix join me on, it's like, okay, so everyone calm down. Let's figure out what's happening. It's like we've looked at that screen three times, looking at it again, it's not gonna solve that problem. But at the same time, remaining calm, but knowing that it really is I'm getting a packet from here to go over here, it's not working. So what could be the problem? And actually stepping them through those scenarios, but that's like, you only get that by having to do it. And seeing it and going through it and then get it. I have a question. So I just see it, we started this program maybe six months ago, we're seeing a huge amount of interest. I mean, we're oversubscribed on all the training sessions. We've got people flying from around the country, even with coronavirus flying to go to Seattle to go to these events, we're oversubscribed. The good squadron leader would put there. Yeah, that's right. So is that something that you see in your organizations, are you recommending that to people? I mean, I'm just, I guess I'm surprised, I'm not surprised, but I'm really surprised by the demand, if you would, of this multi-cloud network certification because there really isn't anything like that. Is that something you guys can comment on, or do you see the same things in your organization? I see it from my side, because we operate in a multi-cloud environment, so it really helps and it's beneficial for us. Yeah, true. I think I would add that networking guys have always needed to use certifications to prove that they know what they know. It's not good enough to say, yeah, I know IP addresses or I know how a network works and a couple little check marks or a little letters by your name helps give you validity. So even in our team, we can say, hey, we're using these certifications to know that you know enough of the basics and enough of the understandings that you have the tools necessary. Right, so, okay.  And then second part, share with the live stream folks who aren't yet A certified or might want to jump in to be AVH or certified engineers, why is it important?  I think my view is a little different. I think certification comes from proving that you have the knowledge, not proving that you get a certification to get, I mean, they're backwards. So when you've got the training and the understanding and the, you use that to prove and you can like grow your certification list with it versus studying for a test to get a certification and have no understanding of the... Okay, so then who's the right person to look at this and say, I'm qualified? Is it a network engineer? Is it a DevOps person? What's your view? You know, is it a certain... You know, I think cloud is really the answer. Yeah. It's the, as we talked, like the edge is getting eroded, so is the network definition getting eroded. We're getting more and more of some network, some DevOps, some security, lots and lots of security because network is so involved in so many of them that it's just the next progression. Yeah. Casey, you wanna add something there? I would say I expand that to more automation engineers because we have those now, so I'd probably extend that field as well. Jennifer, you want to add something? Well, I think that the training classes themselves are helpful, especially the entry level ones for people who may be quote unquote cloud architects but have never done anything in networking for them to understand why we need those things to really work. Whether or not they go through to eventually get a certification is something different but I really think fundamentally understanding how these things work, it makes them a better architect, makes them a better application developer but even more so as you deploy more of your applications into the cloud, really getting an understanding even from our people who've traditionally done on-prem networking, they can understand how that's gonna work in the cloud too. Well, I know we got just under 30 seconds left I want to get one more question in, just one more. For the folks watching that are maybe younger that don't have that networking training, from your experiences, each of you can answer why should they know about networking? What's the benefit, what's in it for them? Motivate them, share some insights on why they should go a little bit deeper in networking. Stacy will start with you and go down there. I would say it's probably fundamental, right? If you want to deliver solutions, networking is the very top. I would say if you fundamental of an operating system running on a machine, how those machines talk together is a fundamental change, is something that start from the base and work your way up. Jennifer? Well, I think it's a challenge because you've come from top down, now you're gonna start looking from bottom up and you want those different systems to cross-communicate. And so you've built something in your overlapping IP space, not that that doesn't happen, but how can I actually make that still operate without having to re-IP and re-platform? It's just like those challenges, like those younger developers or assist engineers can really start to get their hands around and understand those complexities and bring that forward in their career. They gotta know how the pipes are working. That's right. It's the plumbing. That's right. And they gotta know how it works and how to code it. That's right. Awesome. Thank you guys for great insights. ACE, Certified Engineers, also known as ACEs, give them a round of applause. Thank you. Thank you. Thanks for telling me that was great. Thank you. Okay. All right. That concludes my portion. Thank you, Steve. Thanks for having me. John, thank you very much. That was fantastic, everybody. Round of applause for John Furrier. Yeah. So, great event. Great event. I'm not gonna take long. We got lunch outside for the people here. Just a couple of things. Just call to action, right? So we saw the ACEs, for those of you out on the stream here, become ACE certified, right? It's great for your career. It's great for knowledge is fantastic. It's not just an Aviatrix thing. It's gonna teach you about cloud networking, multi-cloud networking, with a little bit of Aviatrix, exactly what the Cisco CCIE program was for IP network, that type of the thing. That's number one. Second thing is learn, right? So there's a link up there for the join the community. Again, like I started this, this is a community. This is the kickoff to this community and it's a movement. So go to community.Aviatrix.com, starting a community on multi-cloud. So get trained, learn. I'd say the next thing is we're doing over a hundred seminars and across the United States and also starting into Europe soon, where we'll come out and we'll actually spend a couple of hours and talk about architecture and talk about those beginning things. For those of you on the live stream in here as well, we're coming to a city near you. Go to one of those events. It's a great way to network with other people that are in the industry as well as to start to learn and get on that multi-cloud journey. And then I'd say the last thing is we haven't talked a lot about what Aviatrix does here and that's intentional. We want you leaving with wanting to know more and schedule, get with us and schedule a multi-hour architecture workshop session. So we sit out with customers and we talk about where they're at in that journey and more importantly, where they're going and define that in-state architecture from networking, compute, storage, everything and everything you've heard today, every panel kept talking about architecture, talking about operations. Those are the types of things that we solve. We help you define that canonical architecture, that system architecture that's yours. So many of our customers, they have three by five plotted, lucid charts, architecture drawings and it's the customer name slash Aviatrix network architecture and they put it on their whiteboard.  So this becomes their 20 year network architecture drawing that they don't do anything without talking to us and look at that architecture. That's what we do in these multi-hour workshop sessions with customers and that's super, super powerful. So if you're interested, definitely call us and let's schedule that with our team. So anyway, I just wanna thank everybody on the live stream. Thank everybody here. Hopefully it was very useful. I think it was and join the movement and for those of you here, join us for lunch and thank you very much.