Thank you everybody for attending this webinar and thanks to Linux Foundation for helping organize this. Now before I kick off the webinar, I just wanted to run some polling questions. So I will be peppering some poll questions in between as well. So I just wanted to gather some stats from all of you. So if you wouldn't mind just answering the first polling questions, so there'll be totally five of them. So please go ahead and check the polling questions and select the appropriate answer for yourself. Okay, I'll give a few seconds. Okay, looks like a majority of the people are from the Americas and then a significant size of the audience is from Europe, about 36%. So that's very good to know. Yeah, welcome from everywhere and good day to everybody. All right, so let's head in. So let's look at what we are going to cover today. Let's look at what we are going to cover today. We look at the state of our technology today, state of especially the state of DevOps and then cloud-native technologies and what are the often cited problems that is plaguing modern development teams when they're trying to address or when they're trying to use cloud-native technology in DevOps. We look at a proposed solution that we have come up with. How does it work against these problems? What is the value that we would get and what is the expected outcome? And then we go into the next layer deeper to look into its architecture, understand how exactly it works from a technical perspective and look at what is the technical stack that we would be bringing to the table to address these problems. And we'll wrap it up with a demo. We have an awesome demo. So my co-host Edward Einel is here and we'll be running through a demo of our solution framework. And of course, as always, yeah, please post your questions. We will get to them most probably at the end, but they may be in between before the demo. We may be able to get to some of the questions considering time. All right. So there is an organization called Dora. Dora stands for DevOps Research and Assessment. It is an organization that's been running the DevOps report for the last seven years. They have surveyed 32,000 professionals spread across 5,000 organizations. Again, as I mentioned over the last seven years, and they've compiled these reports. One of the primary things is today's businesses, as we all know, have embraced digital transformation both to survive and to unlock future agile operations, efficiencies and revenue streams. Increasingly DevOps is at the heart of these digital transformation projects. And so the Dora report, which is actually, which is called as the Accelerate report, it has this concept of elite teams. Elite teams are the top 20% of the teams and how they've been performing, how they've been able to leverage DevOps to achieve excellent business results. So if you look at these statistics, the elite teams, they perform 973 times more frequent code deployments than low performing teams. In addition, these elite groups have 6,570 times faster lead times, and 6,570 times again, it's the same number from the report, 6,570 times faster, time to recovery, and are one-third times less likely to see deployed code changes fail. The report has also revealed similar statistics over the last five years. So this is the latest report, this is from March 2021. But we have had very similar numbers. The trend is just going in the same fashion for the last five years, offering us very clear evidence that when development and operations teams properly adopt DevOps technologies and methodologies within their organization, they are able to substantially increase both the speed and stability of software development and deployments, the two main pillars of success within the software development life cycle. This report also examines a successful implementation of DevOps methodologies and how it affects companies' businesses. But the top 1%, so from these elite teams, the top 1% of the DevOps teams that were surveyed, they were able to meet or exceed their commercial goals 1.5 times more than the other organizations. And what this means is the productivity, the profitability, market share, customer growth, all of this have been increased by more than 1.5 times. We have had 50% higher market capital growth on average over a three-year time span than organizations whose implementation of DevOps methods have been less successful. Now if you go to another report, so this is the Kubernetes in the enterprise survey. Now today, as we all know, DevOps is almost synonymous with Kubernetes, and that's how it has become in many organizations. Almost everybody is using Kubernetes. But what we found is most of them are doing it poorly, except for the elite DevOps teams highlighted before. So organizations should not expect better business outcomes just because they're using these CloudNet technology or Kubernetes. So these numbers from this report, they emphasize that. So almost 90% are running Kubernetes, they're using Kubernetes to run all sorts of workloads, so there's not one particular workload that is not being used on Kubernetes. However, 95% of the organizations that use the CloudNet technologies have run into challenges, 95%. And 98% of the organizations they are investing or they're considering investing in Kubernetes training to address these challenges. There are 51% developers who say that building CloudNet application makes them want to find a new job, so it is causing a lot of burnout and frustration. And of course, there's 38% developers who are not able to catch up, who are not able to keep up with all these new technologies. So we understand that Kubernetes, there are many different ways of deploying Kubernetes. There are many different ways of having a Kubernetes cluster, many different ways of running applications within Kubernetes, and the technology just keeps growing. And if you add the CloudNet technology, I'm not sure how many of you have seen the landscape, the CNCF landscape, the link is down below, there are over a thousand cards. I could have put the screenshot here, but it would be so small that nobody would have been able to read what is in it. So if you add these two things, it becomes a very, very big complexity problem. So what can we do about it? We want to enable businesses to streamline delivery of hundreds of daily deployments across thousands of applications, overcoming the complexity of Kubernetes deployment at enterprise scale. So some of the problems or some of the ways that we can address these are we can enable faster deployment on development via increased automation beyond the initial stages of doing a POC, beyond the Kool-Aid, as I would call it, of Kubernetes. We want to see what else does Kubernetes not provide that we need to actually address so that it can provide an enterprise solution for today's team. We also want to address the cultural aspect of it. A big portion of this is cultural aspect and the remaining things are all engineering, as some would say. So we want to socialize data and metrics. We want to provide full scale transparency at all levels. We want to facilitate the faster decisions through making data available to everybody. We want to also measure, measure, measure. We want to quantify the velocity of change. If something's not working, we want to fail fast. We want to try something else. Developers also need to have the capability to self-serve themselves. They should not have to depend on other teams or another process. So they should be able to quickly test what their problems are. They should be able to help themselves. And finally, all this underlines is we want to remove the fear of complexity of yet another tech. And again, I'm not talking only about Kubernetes. It is all about the cloud native landscape, the thousands of technologies that are there, which makes sense. What is suitable for your particular use case? How do developers address that without spending a lot of time in understanding each of those solutions? So in effect, we want to unblock developers. We want to give them the controls back so that they are happier. They continue doing what they're doing. They're more confident in what they're doing. And we want them to be able to overcome the selection of tools, the complexity in selection of tools and its adoption. So what we have to address these things is a package solution. So we have DevOpscare. So in this particular slide, I want to showcase a new product, DevOpscare Powered Violence. So DevOpscare is a culmination of a decade of servicing thousands of customers in virtualization, DevOps, containers, and digital transformation. So we have clearly established that Kubernetes is alone not enough for most teams. There are so many other components that need to be planned, set up, configured, and maintained for an enterprise shop. Our objective is to remove the complexity involved in cloud native technologies and Kubernetes, maximize developer productivity, and handle all the operational tasks that tend to distract. With DevOpscare, we let developers focus on the bright side of development that is building world-class applications and make it a more enjoyable experience. So what is DevOpscare? At its core, DevOpscare is a fully managed service that is delivered through the award-winning Kubernetes ID called Lens and various Lens extensions. It is a packaged software-as-a-service SAS. In other words, it is a prescriptive solution that addresses the management of all aspects of the architecture of cloud native applications, running on any flavor or distribution of Kubernetes on any infrastructure anywhere. The DevOpscare solution encompasses increased collaboration via a Lens cluster-sharing feature called Spaces and Dev clusters and extensions built for Lens and Kubernetes. Additionally, DevOpscare includes an industry-grade CICD solution embracing GitOps principles, SRE, and monitoring to ensure uptime of all applications in all across all clusters, a piece of mind through continuous security and post-wire policies and an up-to-date training model. A large part of DevOpscare would be metrics-driven to ensure the changes are progressing in the right direction and at the right pace. So if you can go one step higher, one step further to understand what is the expected outcome of the DevOpscare for people adopting it. So the underlying factor, as again, I want to re-emphasize. We want to eliminate this complexity of Kubernetes and cloud native app development. We want to unblock developers and let them go. Let them create world-class applications without having these distractions. But how do we do it are these four pillars. We want to provide full-scale visibility. We want to have a single window into all aspects of cloud native development, deployment, testing, building, shipping, detect failures in deployed applications quickly, provide visibility into costs and capacity of running Kubernetes applications, provide application uptime metrics. Through automation, we want to provide a reliable software delivery pipeline through GitOps and CI CD, reduce the friction between Dev and Ops, provide validated tools and methodologies, provide enterprise-grade curated Kubernetes CNCF solutions, increase developer productivity through these mechanisms, provide guidance and solution from Kubernetes experts, have ready-made on-demand training that is constantly kept up-to-date with today's technologies, provide best practices so there is no analysis paralysis on the developer side, provide proactive maintenance through continuous metrics monitoring, provide the confidence to scale up safely and with confidence. Now all of these would directly address the unlocking ability of all these business concerns.  So one aspect I want to emphasize and clarify is the scope of DevOpsCare managed service. So you can look at this sort of chart wherein you have your platform and your infra at the right bottom, this is where you would be running either bare metal servers, VMs in the cloud or what have you. You would also have your container runtime, you could have a do-it-yourself and open source Kubernetes of distribution or you could have one of the products from Red Hat or Rancher or from Rantis or it could be a public cloud provider for Kubernetes like EKS and AKS and GKE. And then if you go further up, you have the application developers who are in charge of building applications. This is the coding team, they build out code. They have configurations to make it work and they have Docker files to convert them into images and then they ship the images into registry. And then these images are used through Kubernetes or using Kubernetes to run them as application parts. Now where DevOpsCare or where DevOpsCare powered by Lensware that comes in a picture is within this blue box. So we would deploy Lens. So Lens are just like any other client. It uses Kubernetes API. It is a very popular ID as I mentioned. It has a graphical interface but it also has the capability of extending its functionality via extensions. And these extensions are what also go through the Kubernetes API and they provide super user capabilities. And through these extensions, we provide all the additional capabilities. We provide a policy enforcer. We provide a secure R-back visualization of that and making sure people are aware of what are the drawbacks of particular role-based access control models. Provide uptime of application health, capacity cost analysis, proactive security audits and remediation. A developer experience through what are known as Dev cluster. I will have a demo of that very soon. There will be experts available 24 by seven in case you have a problem. You want to troubleshoot a particular problem in one of your environments be it in production or any non-production environment or you just want guidance. You want to just know what is the best way to approach a particular problem. So the professional services are experts available 24 by seven. We already talked about training which will be available on demand always kept up to date on Kubernetes and cloud native technologies. And all of this would be provided via the backbone of CI-CD and GitOps. So I want to re-emphasize that the blue box is the only thing that would be part of this. What that means is that it does not matter what Kubernetes flavor or distro you're using. It does not matter where you're running your applications. It could be on-prem or in the cloud or even hybrid, multi-cloud. And it also does not matter at what stage you're in. You could be a beginner. You could be just thinking about moving to Kubernetes or you could be an expert. So DevOpscare would address all these different stages of your journey. Now if we zoom up a bit and look at the technical stack that would empower all of these DevOpscare technologies. So for the Docker images themselves and the application pods we have what is known as a managed Dev cluster. This is another feature available in Lens. This allows you to set up an independent cluster for each developer in your team so that he or she can experiment whatever it is that they want to do. They want to run a Kubernetes part in a particular way. They want to run jobs. All that is possible. It also has the Docker tool chain installed. So you can run your Docker builds directly within your Dev cluster. And then you can reset it back in case you mess it up in case it's not working anymore. You can just click a button and reset it and it gets back to working again. For the policy enforcer, we bring in OPA, Open Policy Agent. We have QV scan, which allows you to visualize your role-based access control and your rules. Prometheus Grafana stack for an application health perspective. We use Goldilocks and Kubecast to provide you capacity analysis and cost analysis in case you're using multi-tenant sort of structure. We use Aqua Conf test and OPA to provide you security audits and the security audits was all the way from your parts to your images as well as to your hosts. We also have a chatbot that would be, again, deployed as an extension within a lens that would allow you to reach the DevOps care team. This is the professional service of the experts, the Kubernetes experts, that is always available from an SRE perspective, from a general tool selection perspective, guidance perspective. And we have on-demand training that we host ourselves. From a GitHub CI CD perspective, we bring in flux V2 as well as GitHub actions. Now, the key takeaway from this slide is that this is a prescriptive solution. We have decided some tools for you based on our experience, based on our analysis. And we have built extensions so that at a click of a button, you should be able to deploy all of these into your environment. Now looking at another view of the solution architecture, how it works. At the bottom, you would see the clusters. You can have n number of clusters and these can be the clusters that you, as a dev team in your organization once, they could be dev, QA test, production, whatnot. The developers on the team, they would use CubeCuttle or they would use Lens. Again, Lens is just a layer on top of CubeCuttle that gives you a graphical interface, but still depends on Kubernetes API. But you would be using Lens to access the clusters and to do all sorts of operations on top of it. Now using the Lens, the capability to share the cluster, you would share this cluster with, you can share the cluster with other teams to enable collaboration or you can share it with the DevOpsCAD team. Now the DevOpsCAD team, they would be able to access your cluster securely. It will be, so it's a secure connection via VPN or as good as VPN.  Again, these are governed by tight role-based access control policies that you can set up. You have complete control over those. But the DevOpsCAD team, now they have visibility into your cluster. They can view errors, they can view warnings, they can set up alerts. They can also install extensions to make it easier for you, for the developer to conduct their business, to continue developing their applications if they want a CI CD stack that can be deployed via extensions. A marketing stack can also be deployed via extensions. At the same time, the developers, they can leverage the managed Dev cluster to do the experimentation. And this is again, this is a hosted solution on our side. The developers can access it at any time. Obviously, internet access is required to do all of this. But the managed Dev cluster provides you a full-scale Kubernetes cluster running the latest GA version of Kubernetes as well as the Docker tool chain, as I mentioned before. And you can experiment on this. You can run Docker builds. You can run even Docker compose if you wanted to do so because it has the entire Docker tool chain installed. In addition, like let's say, for one example, when the monitoring stack is set up on all your clusters, there is another intermediate or there is a centralized Prometheus cluster that we would set up that would aggregate all of the metrics from all of your individual clusters into one place. So that would provide you a place from where you can run additional analytics and telemetry. We can also plug in a Grafano or any other tools that you want as expected with Prometheus. And you can provide exporters and all sorts of stuff to provide you even more visibility. And you can take decisions based on that. Now, we still depend on open source for all of our, for most of our solutions. Some of the extensions we have built ourselves, but they also have open source technologies. So there is also a connection to Helm and GitHub. And these are, these are very, very normal connections, very typical connections that we would expect for any cloud-native project. And then I also wanted to explain one other thing. One of the core backbones of delivering our DevOpscare extensions is through GitOps. Now, GitOps is fantastic because it provides you a seamless architecture and solution to test code as well as configurations. So any of the extensions that we build or any of the tools that we bring in, we would deploy it via GitOps. And this goes to our security tools. It can be policies that we set up. Everything would be pushed via GitOps. So it gives you the same capabilities as testing your application code. So every change is observable. It is verifiable and measurable. You can also do easy rollbacks to a previous state. You'd also get secure deployments. And then you can also put in an approval process which is very lightweight, just in case you don't want things to go without any oversight into your higher environments. And it provides a very modular and two independent architecture. So that is one of our art stones on which we will be deploying the DevOps care solutions. And finally, we would enter the demo. I would like to hand it over to Edward, please. But before the demo, I wanted one more poll. Do you want to remind? Please take a minute, a second to answer another poll. Thank you very much. And Edward, over to you. Thank you Anu. Excellent presentation breaking down DevOps care and why it's valuable to the community. I will give it a couple of minutes or maybe 30 seconds actually for people to answer the polling question. And then we're going to jump into a demo of the backbone technology that allows DevOps care to work and operate for our customers, our prospects and the community themselves. I do want to thank all of you for joining us today out of your busy lives, wherever you are, whether you're in North America, Europe, APAC and so forth, maybe Antarctica. But thank you all for joining today and we will jump into the demo just as Anu ends this poll. I think we have a sizable response. 40% of the respondents say complexity has been the number one Kubernetes challenge. 43% mentioned cultural changes and development as a challenge and 17% mentioned security as a challenge, 0% mentioned storage. That is very good to hear. Very much aligned with what we see from the DevOps reports. Thank you for that. I will end the poll now. Excellent. And when you get a chance, please stop sharing your screen and then I'll be able to share mine. Perfect. Thank you, Anu. Yes, cool. Then navigate over to share my screen. OK, everyone, well, welcome. Today we will be talking about Lens and DevOps Care. Lens is the backbone technology behind DevOps Care that allows us to actually build and operate and be able to actually release and showcase this product to our prospects and community. So without further ado, this is Lens. It is a desktop application. Some of it is open source and Lens allows our users to get a full situational awareness of everything that's happening within the Kubernetes cluster with the ability to actually manage multiple Kubernetes clusters. And as Anu mentioned, any certified Kubernetes distro, whether it's Marantis Kubernetes Engine, EKS, Rancher K3S, and so forth. So what we see here at a high level is actually how our cluster is currently performing in the last hour from our CPU to the memory, the capacity, and of course, some warning messages that Lens is able to provide to us and our users to get a better understanding of what is currently happening within our Kubernetes cluster itself. I do want to mention that Lens also has a smart terminal that allows you to automatically connect to the correct context of the Kubernetes cluster that you're currently leveraging. So right now, we can see I am leveraging a mini-cube cluster. It's connected via the Kubernetes API. I'm a Q-config file. And I can switch over to this dev cluster immediately and begin to understand how this cluster is currently performing. This is the dev cluster that Anu mentioned in the presentation. It is a managed cluster hosted entirely by Marantis. And this is going to give developers direct access to a development cluster all in real time without actually having to leverage their local operating system resources on their laptop and so forth. One of the neat things behind dev cluster is actually the ability to auto-wake and auto-sleep. And what I mean by that is, if a developer is currently not leveraging the cluster, Lens and DevOpsCare will be able to detect the fact that that cluster is currently not leveraging it, not being leveraged, and it will actually be able to go to sleep. The reason why this is so beneficial is we are seeing many development teams currently wasting a ton of resources on clusters that may be living in the public cloud or running on their computers. And they're not necessarily leveraging the cluster to its full capability, but they may be paying for that cluster. So here's the dev cluster. I'm going to switch to another cluster now as well, just to be able to show the true capability behind Lens and so forth and being able to actually switch from cluster to cluster while always maintaining the correct Kubernetes API endpoint. We'll clear this. You can see it's connected here, and if I navigate back to my dev cluster, I can open the smart terminal, clear this out, QCTL version, and immediately see that it's connected to the correct context. So this is extremely neat behind Lens and DevOpsCare. When you're working with multiple Kubernetes clusters, we're really eliminating the complexity of switching from cluster to cluster while being able to ensure yourself that you're working in that correct context. So if you're ever leveraging multiple Kubernetes clusters, whether it's a proof of concept cluster, a dev cluster, a production grade cluster, Lens and DevOpsCare ensures that you're working in the correct context of that cluster, really eliminating user error and complexity when working with multiple Kubernetes clusters. So Anup definitely talked about metrics and observability, the ability to get a better understanding of everything that's happening in your Kubernetes cluster and your applications. What's so neat here is we can immediately see all of my pods that are running and some messages that are associated to this pod, giving us a better understanding of what is currently happening and showcasing and directing us on how to actually troubleshoot an error that we may see within our Kubernetes cluster or an application through DevOpsCare. Clicking into one of these pods, we're going to get a granular view of everything that's happening within this pod from the labels, the annotations, the operating system and so forth. We can see the containers it's currently interacting with and this pod is actually currently killed and that's why we don't see any metrics. So if I actually open a different pod, we are going to pull in those metrics again from CPU to memory, network and file system. If we see a drop in file system, it's extremely important that's going to let us know that we need to troubleshoot debug and so forth. Again, one neat thing behind Lens is also that it's always leveraging your role-based access control from your KubeConfig file and DevOpsCare does the same thing and we actually help you get or we actually give you the necessary details and requirements needed to ensure that you are following the best practices when it comes to role-based access control as well. On the top right-hand side of Lens, we can actually see some admin functions I can perform. Again, these admin functions are based off of your RBAC, so if you don't have the correct role-based access control from your KubeConfig file, you won't be able to perform many of these actions and we'll actually showcase this in just a couple of minutes. We can view our logs all in real time, get a better understanding of how our cluster's performing or our pod. We can download these logs and the neat thing and Anup actually mentioned this is through Lens and DevOpsCare, we actually have the ability to create secure spaces where I can share my Kubernetes cluster securely without ever exposing my KubeConfig file to a colleague. So that's really matching best practices as well from a security standpoint. And Lens Spaces again allows us to share access with colleagues, with the DevOpsCare team to ensure that we are taking care of troubleshooting issues, logs and also being able to do everything that Anup mentioned within DevOpsCare. So from here, what I'm actually going to do is I'm going to create a space. This space is what is used to actually share the cluster with a colleague and I'm going to create this space. I'm going to add my cluster to this space and actually I'm going to be able to share a local mini cube cluster that's running on my current operating system on my laptop with Anup and he's going to have admin functionality and admin privileges to that cluster. And this is exactly how DevOpsCare is going to work when the team comes in, gives you best practices, sets up the GitOps, our CICD pipeline and so forth. Cool, so I'm going to navigate to my mini cube cluster. Again, we can see everything here in one beautiful place. Actually, before I jump into that, I do want to showcase some very cool things as well. So Anup did talk about extensions and we're continuously building many, many different extensions that allows us to enable DevOpsCare for the community, our prospects, our customers and so forth in a beautiful way. So I currently have various different extensions currently added to Lens all by our partners and built by us. Here you can see cube cost, you can see Aqua Security. These are extensions that one, for example, cube cost will be able to tell me how much money I'm currently spending on my Kubernetes cluster and that environment. We have the starboard extension that's going to scan for vulnerabilities and so forth on my Kubernetes cluster. And I do want to note that we are going to showcase all of these extensions in the next webinar where we really go into depth of all of the capabilities that these extensions can provide for us on our Kubernetes cluster and through Lens Dev or DevOpsCare powered by Lens. So now let's go ahead and actually create a space. We're going to create a secure space that we can add my mini cube cluster to. This space is going to be called DevOpsCare one. Excellent, so we created this space and once we create a space we do need to add a Kubernetes cluster directly to this space. So what we'll do is we'll navigate to my mini cube cluster. I'm going to hit this plus icon. That's going to add the cluster to the team space. I do want to note that when you are adding a cluster to a team space we are downloading a Demian set directly to your cluster which actually creates a end to end encryption between your Kubernetes API endpoint and the Lens cloud API ensuring an encrypted tunnel that is happening to ensure that we're meeting best security practices. One of the reasons why we've developed this feature is because, and I think I touched on this a little bit but it's mainly because a lot of organizations need to share cube config files with their colleagues and that's not the best practice. Once you actually give somebody access to your cube config file they have access to that file always although maybe they don't have the correct role-based access control but they do have access to that cube config file and we're really potentially causing security concerns. So here what I'm going to do is I'm going to add that cluster to the space. We're going to download that Demian set that I just mentioned which is going to create that tunneling that end to end encryption tunneling between our Kubernetes cluster and Lens cloud. So as we can see it's been installed. If I navigate to my space DevOps care one we're going to be able to see that cluster here. It's currently disconnected now if I launch it it's going to open up and connect directly to our cluster. This may take a moment and of course this isn't that cool yet but once I add a nuke to this and share the cluster directly with him you all will be able to see the power behind Lens spaces and DevOps care being able to actually give your colleagues access being able to give the DevOps care team access to your cluster and so forth. I do want to mention that when you first share access to the space with the colleague it is read only access to that Kubernetes cluster. Now we have also created specific additional permissions that you can leverage where you create a team within your space itself. And in that team you can create an admin team where they actually get admin functionality and so forth all through Lens spaces and DevOps care. So without further ado I'm going to actually add a nuke to the space. A nuke I believe your name is just a nuke, correct? That is correct, yes. Cool, so I'm going to share the team space with them. We've sent them an invite and before I hand over the ball back to them I'm actually going to navigate over to my settings of this space and this is where we actually can see some really cool things. So within members we can invite new members. We already invited a nuke through a different user interface. I can view my invitees. Here we can see that it expires in seven days. And of course I can actually create teams within our Lens space. And what I mean by that is if you have a team of developers that need to access a specific namespace you can actually create a team titled developers adjust the role-based access control on that kube config file and add those members to that team of developers and they will only have access to specific namespaces maybe to review microservices and so forth. From here, Anup, have you gone ahead and accept that you have? Oh, can you accept the invite? Yeah, okay. I was thinking I may want to share it but maybe I can just accept it. Let's accept it first because I'm going to make you an admin on my space which is going to give you full observability into my Kubernetes cluster and so forth. Perfect, I have accepted it. Excellent, cool. We can see that it's been accepted on our end as well. Now I'm going to add a member here. The member has to already be invited to your space as you can imagine and click Anup. And we've actually added him to the space. So what I'm going to do now is navigate back to our cluster. I can go to my home and the neat thing behind Lens spaces is on the top right hand side I can see various different spaces I currently have access to and within each of these spaces there are various different Kubernetes clusters that I can now leverage, work on, troubleshoot, configure and so forth for my team of developers. So if I click team re-event I just want to showcase this real quick. We immediately have the ability to see all of these different Kubernetes clusters. They are currently disconnected but if I click into one it's actually going to populate and load that cluster on Lens through Lens spaces. And then of course if I navigate back to our DevOps care we can see we have a cluster here. So from here I'm going to stop sharing my screen. I'm going to give the ball back to Anup real quick and he's going to be able to show everybody what he is able to see now that he's been able but now that he's accepted the invite to Lens spaces we've shared the cluster to that space and so forth. So I will stop sharing and give you the ball back Anup. All right. Thank you very much. Yes, I did receive the invite and I've accepted it. I would require you to walk us through to what would a developer do next to enable the cluster. Okay. And here. So I can go into my spaces, manage the spaces and I do see DevOps care. I am an admin here and I can click on this. How would I access this from now? Let's let's escape here on the top right-hand side, Anup. Yep. And then hit it one more time. What you want to leverage is that toggle that you see on your top right-hand side where it says Anup to just click that. Yes. And then DevOps care. All right. And there you go. Perfect. Now we have mini cube. That's your cluster. Correct. Yes. And now I'm able to see the nodes that you have and I will see even all the pods. And I can look at the error messages. I can assist you. I can tell you, hey, this is an error message. You need to fix it. You do this to fix it. Yes. Logs. I can exact into it. I can check the logs directly from here. Oh yeah. This is the error message that you're getting. And that's because that pod is currently not running, I believe. Oh yeah. It's dying. It's the MSR pod. Yes. Yes. That is. So one of the questions, Edward, is does DevOps care team need cluster level admin access to the Kubernetes cluster in order to troubleshoot and resolve issues? So that can be done through Lens Spaces. It just depends on really your role-based access control. And what I mean by that is do the DevOps care team really need access to the entire cluster or do they only need access to specific namespaces? So it's really up to you to decide, but generally speaking, we would like the DevOps care team to have admin access on the cluster. Yes. Very cool. Do you need me to show anything or I can stop sharing? One quick thing I would like you to show is if you can go down to that resource map at the bottom, all the way at the bottom, let's see if we're able to showcase this. Nice. So this is an extension that's also built by us that's really helping people get started with Kubernetes, but also anybody leveraging Kubernetes. This is a great resource map that actually showcases everything that currently lives within your Kubernetes cluster, all of the resources and so forth and how they're related to one another. So great extension here will help you troubleshoot. It's going to also teach you how everything's related to one another and so forth. And this is another extension that is built for DevOps care and for Lens and so forth that anyone can leverage. Just one of many, there are over a hundred extensions currently built on top of Lens. And of course majority of those extensions are around security vulnerabilities, scanning for security vulnerabilities. Flux is an extension on top of this as well. And also being able to understand your current costs on your Kubernetes cluster and so forth. So yeah, I think that is everything that I wanted to demonstrate today, Anup. I will hand it over to you. All right, thank you, appreciate that. Thank you so much, Edward. So let's just look at some of the questions that we have. One question from Gyan Rajkumar. Where can we use Keynative? Yeah, so Keynative is something that we are actively exploring. One of the places that we want to leverage serverless solutions is where a cluster might not have enough resources to install all the extensions. So pretty much if a cluster is small and it's just enough to run the applications, we do not want to make it any more worse and cause performance overhead by deploying extensions. And that is where we want to leverage Keynative and generally serverless solutions. And one of the key pieces that we're looking at is in CI CD. If you're familiar with Jenkins X, that's one of the solutions that utilizes Keynative. Another use case would be in security and vulnerability analysis. We do not want to keep something running all the time. We want to surgically run a pod. It would just collect all the metrics. It would run the vulnerability scans, whatever is necessary and produce a report and it gets out of the way. So those are some of the places where we would want to leverage Keynative. Again, we do not have Keynative today at this point in time, but this is coming very soon. And another question from Mick McGrath. Thank you for that. So how do you handle local development iterations? For example, how best to wire up a local file change of a Node.js project to auto reload a running container in a Kubernetes Spark? Fantastic question. So the way we are approaching this is, again, if you go back to one of the things, and we do not have a demo for that yet, is that the Docker Toolchain would be installed in the managed dev cluster. Each developer gets his or her own managed dev cluster. And what this does is this would enable you to treat it as though it is something that is running on your own machine. Like, for example, if you were to bring up a pod, if you were to just keep Kotl or whatever and run a pod and expose it as a service, you will be able to hit local host and the node port and access that particular service. So similarly, when the Docker Toolchain is deployed, you would be able to do this auto, this hot reload of your files directly into the container, and you'll be able to do the tests. So that is something, again, that is something that is being planned and being tested out as we speak, but we have a lot of interest in very similar things, similar workflows to make it easy and seamless development. So that is something that's coming. Please watch out for that. Another question, can you choose the Kubernetes version for the managed dev cluster? Today, you cannot. We run a very lean, minimalistic Kubernetes. It is CNTF, but it is minimalistic. It will be run K0S because that helps you conserve the compute resources and everything, but still, but at the same time, there's a full-fledged Kubernetes distro. So you cannot use your own Kubernetes version at this point in time, but it is something that we would explore in the future. All right, any other questions? Okay, is it possible to customize the metrics that are shown? Yes, absolutely, absolutely. So that is the self-service component that we talked about. There would be avenues where the metrics that are collected, as well as the metrics that are displayed, that you would be able to customize that. We'd be also deploying Prometheus exporters that would be able to collect application-specific metrics. So it could be a particular, it could be a Java application or it could be a MariaDB or something else. So bespoke metrics, that would be definitely something that would be available. Okay, great. Well, if there aren't any other questions, Edward, any closing remarks? The one closing remark that I have, again, thank you so much for everybody for attending. The closing remark is we would have another webinar, the part two, if you will, and that would go much deeper into the technical stack and it'll have much cooler demos than this. We wanted to use this opportunity to introduce DevOpsKit to all of you, but this is something that we are building actively. We have a team behind it that is very excited to address today's DevOps and cloud-native complexity problems. So please watch out for that webinar demo too. Okay, wonderful. Well, thank you all so much for being here today and big thanks to Anup and Edward for speaking today on this topic. Please look for the recording leader today on the Lennox Foundation YouTube page and we hope to see you back at another webinar. Thanks, everybody. Thank you.


I'm about to do a clean with me y'all. My room is a mess.  Hello, my name is Kyra. Happy blog miss baby Okay, so today's blog. I mean every day's blog this month. Hello, but Yeah, I just got home. Well, no if you're new here subscribe leave a comment. Give this video thumbs up. Okay, anyway So I just got home. It's currently just 9 30 I got home. I didn't exercise today. Y'all my body is so Bucking Soar my back. Oh my god my legs. I haven't worked out with my trainer since after like I've worked out with him before Thanksgiving, but after that I haven't seen him. So but I was working out on my own. So I see him yesterday girl.  So I didn't go today. So I'm gonna go see him tomorrow But today I need to you know, we're juveniles But I am gonna continue to eat healthy So but this morning I just went to Whole Foods and if y'all didn't know Whole Foods has breakfast hot food But the last time I got Whole Foods girl, I got so sick I had ate the fish salmon from there But usually the breakfast doesn't really do anything to me But I just got this vegan burrito And I cannot wait to eat it.  It's looking real Christmasy in this mug Got the Santa chair covers then some stockings So cute lights And oh looking real Christmasy in this motherfucker So Oh my god So yeah, y'all I'm just about to eat this as breakfast and I'm probably going to Just look at some footage some of the videos and Yeah And I gotta take a nap though. Wish I was tired So I'm about to do that and then wake back up So I'll probably check in with y'all once I wake up and do what it do Continue on my day So yeah, I will check them with y'all later.    I mean like I don't get like so mad about views because You have to just leave it up for a couple days. Like it's not Like if it's something your subscribers are you too used to It won't do that to the book it still is gonna go elsewhere because people People's interests are different people's interests.      No, I'm sorry I'm playing playing y'all. I don't even want to show y'all. So I was recording yesterday and I had to use this light And this light I'm gonna set it up right now because I'm about to do a clean with me.   Bitch. I got ice cream over there. Y'all me ate ice cream yesterday Shit on the floor my laptop bed messed up Look at all this look at this and y'all don't even want to see this other corner Oh my god, this is so nasty.  It's gonna be a little bit of a time lapse obviously, so I'm just gonna set y'all up and So we can get to going because I gotta edit another video and I'm not gonna be In this mess and I want to go get some ice cream I know I'm horrible, but okay, let me set y'all up Real quick So once upon a time looking at This is what I look like, but oh my god y'all So this is the view Okay, we leased this So, yeah, that's the end of this video. I hope you guys enjoyed.  I didn't need to clean anything else in the house because it was already, you know Done. So like, yeah, I hope you guys enjoyed this clean with me video.


Growing County Land Services is seeking a public comment on the proposed 2017 AIS plan. Written comments will be accepted until January 20th. The county board has received $450,000 from the state legislature to prevent the spread of aquatic invasive species within county lakes. The plan proposed to accomplish this through approaches such as boat landing inspections, decontamination units, treatment of Eurasian water mill foil, as well as education and awareness. We haven't spent all the dollars from previous years and so we have approximately $35,000 in rollover funds that we want to use kind of more of a regional approach to look at other area counties and also within the city headwaters board counties and see can we do more as a group together as and trying to spend a little bit more money together as a group and try to do that versus you know going at it alone on a county by county basis. The county board will review the plan at the regularly scheduled meeting in early 2017. If you've enjoyed this segment of Lakeland news please consider making a tax deductible contribution to Lakeland Public Television.


Microsoft Activision deal moves closer as judge denies FTC injunction request. The deal moved closer. This isn't the end. A lot of headlines kind of implied. Microsoft wins, as if that was it. They have a deadline to complete their deal by July 18th. Remember, this this deal is like two years old at this point. After July 18th, it's possible some penalties would kick in, etc. The FTC has not shown a likelihood it will prevail on its claim. The FTC has until July 14th to appeal that decision. Microsoft and the UK's CMA have agreed to pause their legal action against each other in order to negotiate. That's a very good sign for Microsoft. Judge saying, I'm not going to give you a preliminary junction because, I don't know, you might win, but it sure doesn't look to me like you're gonna. So it's not worth holding up the merger if you're just going to lose. And then this company now suffers because they have to pay breakup fees and extra lawyer fees and stuff like that.


Hello, everyone. How's it going? I want to welcome you all to warm, sunny Florida. Yeah, right.  That's okay, too. AXIS Conference. Luckily, no one came in their bathing suits. Good stuff. Yeah, you guys know what we do. We do the Rails-NV podcast on a weekly basis, amongst other things. And in this talk, we thought we'd go over some of the innovations that we see while doing the podcast. We've been doing it for over a year now, and give you a taste of a couple different libraries that we find really useful. So I give you Jason Seifer, which is a great gift. I will turn this conference right around to take you home, whoever did that. Okay. So we're going to take a little trip into the deployment landscape of Rails with my first innovation. And that is going to be a mod passenger from the Fusion guys. But in order to really take a look at this, we have to go back in time. Okay. The Rails deployment landscape has changed considerably since Rails came out. Back when Rails 1.0 was around, the preferred way of deploying Rails applications was mostly fast CGI. This was really, by today's standards, not one of the best ways to deploy Rails applications, as has been graciously pointed out by some members of the Ruby community. Because as we all know, deploying Rails with a fast CGI process needs restarting about a thousand times every 10 seconds. Zenshaw, despite his exit from the Ruby community, did give us Mongrel, which changed the Ruby deployment landscape considerably, and a lot of us are still using this today to deploy our Rails applications. And Mongrel works a little bit like this. So you have your web server, and what your web server is going to do, you're going to set up a proxy. The proxy is going to go out to all of your different Mongrels that are going to be serving your Rails application. This saved considerable memory, and it gave you a lot of speed boosts when deploying your Rails applications. After Mongrel, we got Thin and Ebb, and those different servers as well, that kind of built on the Mongrel way of deploying your Rails applications. But there was some contention in the community, because everybody thought deploying Rails applications should be easier, and by everybody, I mean dream host. So I'm sure everybody remembers this drama. Dream host kind of put out this blog post that said, hey, we would really like to be able to deploy Rails applications much easier for our customers. And DHH wrote back and said, yes, I agree, do it. And then the Fusion guys came out and said, you know what? We're going to do that. You want the job, you got the job. So they came out with ModRails, which is ModPassenger, and that's their website. It's awesome. See, look, you got Rails in a box right there. That's how easy it is. And it's really easy to install and really easy to deploy.  ModPassenger has gotten a lot of widespread use now. 37 signals guys are using it. Dream host is definitely using it. Greg has a couple of blogs deployed on passenger, on Dream host, and the world is good for Rails deployment, quite innovative. So it changed from that mongrel that you saw before with the web server in your proxy to basically just having your web server and defining how many different Rails instances you wanted to have.  But what exactly was ModPassenger without Ruby Enterprise Edition? What is talking about speed without some benchmarks that I pulled straight from their website? Ruby Enterprise Edition uses a different garbage collector to speed up the application, reduce memory, uses a different implementation of TC malloc. I don't exactly know what that does, but it's awesome as you can see from the graphs here. Lower is better, yellow is the best, see, right there. By using Ruby Enterprise Edition and ModPassenger, you can get significant speed savings and scalability with your application. That's right. I'm talking about Rails scalability being improved with ModPassenger because there are some naysayers out there about Rails scalability. If you should passenger help that. Those are mine, by the way. I just got my first Google ad payment the other day, $104, but that's also from ismurbrails.com as well. It's kind of skewed since there's three sites and I only put two up here, but thank you everybody for clicking on the ads. If you did, talk to me, I'll buy you a beer. Next up, shoulda. I find shoulda to be innovative. It was not the first behavior-driven development testing framework for Rails, and I'm doubtful that it will be the last, but shoulda brought some really nice macros to the table to help you test your code much easier. Everybody's testing, right? Okay, good. I have to throw that in there every once in a while or people get angry. So here's what shoulda code looks like. It gives you some very, very readable macros to put in your code. This is a test for a model which kind of took the application of don't repeat yourself and applied it to testing. Like I said, there were macros before, but shoulda by the thoughtbot guys packaged it up and made it very easy to do. Here's what a controller test looks like. One thing that you get is different contexts that you can use in your application testing as well. One thing that makes testing much easier is factory girl. How many of you like fixtures? I didn't see one hand for the record. Not one hand, no applause. That's right. Fixtures make your tests really brittle, so what kind of came out of the, hold on, not really brittle, kind of brittle. You have to keep refactoring your fixtures and tests as you go along. So the thoughtbot guys, again, taking the Rails community by storm, came out with factory girl. And what factory girl lets you do was have fixture factories to define your test, like your test data that way, so you can go through and create all sorts of fixtures. Well, not fixtures, but you can actually create your data on the fly. It is maybe negligibly slower than fixtures to the point that it really doesn't matter. I've sort of converted all of my applications to using factories instead of fixtures, just because it's that much easier. And you can really keep all of your different logic and date-like test data in the different contexts. So here's how you would define a factory with Shuda. You can see right here you get some easy ways to get the next thing for an email address, and that's how you would use it in your application. This will create it in the database for you while using your tests. So next up, cash money on a scaling roll. This is not the cash money that you guys are probably thinking of. Ten years of bling volume one, I would just like to point that out. Volume one, like there's going to be ten years of bling volume two. Do they have to wait another ten years? And how much more bling did they accumulate? But I digress. So what is cash money? I took this straight from the Cash Money website. It's a plug-in for Rails that basically gives you transparent, write-through, and read-through caching in your Rails applications to help you scale. We saw the scaling slides before, right? Can Rails scale? Okay. It can scale. Cash Money is used by Twitter right now, a version of it is used by Twitter. And so basically one of the big problems when you have a really large website that you need to have a lot of data replicated across your databases is something called replication lag. So what can happen is, let's say you have three database servers, a master and two slaves. A user goes into their account and updates, say, their login. Now as soon as they update their login, there's a chance that by the time they actually get back to that page and refresh the action, that the data will not have propagated into the other slave databases. This is where Cash Money comes in. What you do is, so you have a separate memcached, memcached D, is that it, memcached D or memcached? Okay. So you have a separate memcached D cluster and what you're going to do, what Cash Money will do is it will write that data into your memcached D cluster and into your database at the same time. When you go back through, it reads from the cluster. So that provides basically transparent, I don't want to say scalability, but transparent write and read through caching. Helps immensely when you're dealing with these larger scale websites. Oh, and it uses all of the active record functionality. That's why it's transparent. All right. Next up, WebRat. How many people have heard of this or used WebRat? Awesome. Half the rooms. You guys know why it's awesome. It gives you really, really easy integration testing. This is an example from the WebRat documentation about a sign up process. Instead of actually doing all the, you know, let's say you were going to get the sign up method in an integration test, you don't have to do get sign up, yada, yada, yada. It provides a really nice DSL for filling in all these things doing the submits following redirects. And you can still do all of your asserts or should equals if you're using our spec or matchy or something like that. Merb actually used WebRat for its testing. It was compatible out of the box with Merb. And as we all know, Merb is being merged into Rails 3. Next up, JRuby.  JRuby is just about the fastest widespread Ruby implementation out there. 1.9.1 beats it in some benchmarks. But for the most part, JRuby is the fastest Ruby implementation that we have. And they're getting 1.9 compatibility very, very rapidly if they're not there already. One other thing JRuby did really innovatively this year is give you the glass fish gem which I think is production ready now. I'm not entirely sure, but the new glass fish gem provides very, very simple and easy JRuby deployment of your Rails applications. Basically, all you have to do is go into a directory and type glass fish. Your Rails app is up and running. All right. Another innovation from the Rails community this year is sample applications. I'm really not too involved with other web development communities, but I have not really seen anything like this anywhere. A common theme among these sample applications that we have now, including different plugins, RESTful authentication is pretty common, we'll paginate. And Rails already provides a really good base for your application to get you up and running. The sample applications further that along by including all the different plugins, Capistrano recipes, basically even take you to the next step with user authentication, login system, things like that. And they're fully tested. One of the reasons I find this so innovative is because new users can see how you're supposed to code a Rails application when they get into it because following tutorials doesn't always cut it. So it's really good to see some code in there that's actually used in the wild. Some different sample applications that we have out there, Bort, Blank, and Suspenders. Bort is from Jim Neath, Blank is from, hold on, got it right here, oh, I spoiled the whole thing. Sorry, guys, James Golic does Blank and the Thoughtbot guys do Suspenders. Next up, as you guys have probably guessed, is Workling. Last year was the year of the messaging queue with Ruby and Rails. We have so many different solutions for messaging queues.  Well, this is where Workling comes in. Just like ActiveRecord kind of abstracts away the database, Workling kind of abstracts away your messaging queue. It works with a bunch of different messaging queues and what you do is define jobs. This is from their documentation, say, you know, we had a cow that we wanted to move. We would just define our worker, which inherits from Workling base, and then to call it from our controller, we would just have a asynchronous move. Who doesn't want that? You can actually download this sample application from the Workling project, there's a link that we'll be providing at the end with links to all of these different projects. Workling supports all these queues, Starling, RabbitMQ, Root Queue, Background Job, or BJ, and any queue that follows the, yes, I said it. You guys. Okay, moving on. Next innovation from the Rails community, open source social networks. I don't know how many of you are freelancers, but there was a time where about every other week someone would call and say, you know, what I need is a social networking website for my startup. It has to combine YouTube, MySpace, Facebook, LinkedIn, and Yahoo. I need it done in about a month, and I don't really have any money. So if you guys want to work for equity, that would be awesome. But the Rails community answered this and said, you know what? We can help you out. You need to repeat all this code every single time you're doing a social networking application. So there are open source ones. First one that came out was Love by Less. Let's give them a hand. Stephen Bristol, stand up. Stephen wrote Love by Less. Another one we got, Ensochi and Tog. Tog is a little bit different from Love by Less and Ensochi in that it just gives you the different parts of the application, sort of as plugins that you can integrate into your own application. And the world was good. You had a really solid base to start with. And finally, the last innovation is not from the Rails community, but the Rails community uses it extensively. It's GitHub. Yes, I know, the guys who wrote it are Rails users. You guys know the config.gem syntax in Rails 2.2 in your environment.rb? You can use them from GitHub. No longer do you have to wait for all your gems to be updated by authors just for the project. Develop the gem yourself. GitHub has contributed a lot to innovation in the Rails community by providing such an easy framework for developers to work with it. And with that, I'm going to turn you over to Greg. Yeah, let me show you guys. We put up a little page on Rails.mv.com. Let me open up. Those are Greg's kids. It's not stock photography. Yeah. Okay, that's not going to work. Try that. If you go to the following web address, which you'll see in a second, I know you can't see nothing. There we go. All right. Sweet. If you go to this web address here, you're going to see a list of links to everything that we talked about. So if you want to follow up, get some more information, got it, got it. So about how long ago was it? About four or five months ago, Jason and I put out nvcast.com, where we tried to do our own, you know, felling screencast thing for $9 just like Jeffrey Rosenbach. And the most recent one that we put out was Scaling Ruby. Can I get a show of hands? How many people here have downloaded it? Yeah, not too many. A couple. Okay, cool. Cool. Cool. I appreciate it. CS later. Yeah. I was going to say get out. And you know, putting out these nvcasts are good, but yet, you know, not everybody accesses them. You know, they've got a good amount of downloads.  But you know, I'd like to do our own part to help along the community, but it would be really cool if we could release these for free, like something like that for free. And so I was trying to think a few months ago, how do we take that and release something like that for free? And you know, we do the podcast, right? And we get sponsors with the podcast. And so I thought, well, what if I go one of the sponsors, like, say, New Relic, and see if they'd be interested in sponsoring the next screencast, which was going to be Scaling Rails. And they were open to it. And so what came of it was a bunch of screencasts, which we're actually going to announce today and put out the website today, which has, I created the 13 little mini screencasts. We're releasing the first five today. And I'm going to show you guys the intro video to these screencasts right about now. You see this on the website. Over the past few years, as Ruby on Rails has grown in popularity, there have been several big success stories.  But unfortunately, there's been some doubtcasts. No thanks to these guys that, well, Rails can't scale. Thanks to the support of New Relic, over the next few weeks, we're going to be releasing a series of screencasts, which will show you exactly how to scale Ruby on Rails. And I think what you'll find is that Ruby on Rails scales pretty much just like any other web framework out there, with the exception that we use Ruby to do it. The Ruby programming language allows us to be more productive as programmers, write code that's more understandable, and thus, more maintainable. And in my opinion, it's just more fun. As you can see here, we've got a great number of topics to cover, starting with the basics with page caching and moving all the way to using memcached, and even we're going to get into reverse proxy caching, some advanced stuff. At the very end, we'll be talking to three Ruby on Rails professionals and asking them how they recommend scaling Rails websites, starting out with Taylor Wiley, who works for Engine Yard. After we talk to him, we'll be doing a little discussion on database feed, followed by Jesse Newland, who works for Rails machine, enter discussion on deployment strategies, and finally, we'll be talking to Jim Goche, who works for New Relic, and we'll be looking at some of the advanced New Relic RPGM features, and how they allow you to scale your Rails app. I've got two favors to ask of you before we get going. First of all, please be telling you guys to subscribe to the RSS feed. Basically, here's the website that we came up with, that you were all down there. It's also on that web page that I gave you guys a minute ago. Yeah, so you can go on here, you can subscribe, we've got lots of links here. I tried to frame it a little bit like Railscast, because everybody's really familiar with Railscasts and how that format is set up. You can subscribe to it, you can subscribe to iTunes. If I clicked on one of these links, I'd be given code samples straight out of the screencast so you can have a quick reference. Now the one thing, if you scroll down on this page, the one thing I get kind of annoyed at with Railscast.com, when you go back to those screencasts, the comments, there's people troubleshooting in there, and some of them are months old, maybe years old now. And so instead of people submitting comments, I changed this so people can actually just submit links. So if somebody watches the screencast and says, oh, hey, Lino, I know of this great blog entry that describes how to do this advanced feature that has to do with page caching or performance, I'll submit the link here. Or if you have an opinion after watching the screencast, you go, oh, he did this thing wrong here. I'm going to write a blog post about it so people know how to do it right, you can then submit the link here. So hopefully what we'll end up with a few weeks from now when all the screencasts come out is a centralized resource for all the scaling information you could possibly want with Rails. So of course what I hope to do with this website is a couple things. I'm not only educate Rails developers, but I'm hoping to get enough publicity so it'll make an impact sort of on the perception that Rails maybe can't scale. Because there's still people in the enterprise that have that perception that maybe it's not the best framework to go to if I need to create a big website. And that's completely not true. And so I'm hoping this will clear up those misconceptions. So, Jason? Where do you think they got that idea? Does anyone else can scale? Yeah, I have no idea. So, and notice over here on the right hand side, there's a little promote link. If you want to do me a favor, click on those links. You're not making me more money by doing it. So once we're releasing, we're doing the official announcement next Tuesday, but feel free to publicize it and help us get the word out. I'd appreciate it. Of course, nobody's reviewed this on iTunes yet, either. That's another idea right there. But yeah, you can subscribe to it just like any other podcast, which is nice. All right, now back to innovation. The first topic I'm going to talk about is really rat cash. That's where we want to end up, is have a full understanding of rat cash. But we have to have a base understanding of a couple different things before we get there. So it's going to be sort of a long road. And rather than taking the perspective that I was going to talk about a couple little things, I like to educate. So I want to educate you guys with a couple of topics. Some of this content, you'll see again in the screencast, but I kind of refactored it, add some stuff for this presentation. So here we've got a Rails server. And when we talk about caching, server side, Rails comes with four different ways to cash right out of the box. You've got page caching, action caching, fragment caching, and then sort of a low-level object caching. But with Rails 2.2, we were given a way, a couple of different ways, to control the cash on the client side, which we didn't have before, with the power of three different headers. The max age header, e-tags, and last modified. Who here feels like they have a solid grasp of what e-tags are? OK, oh, good couple of people. So I'm not going to spend too much time on it, but I do want to review these different tags, these were headers. So here we've got our common controller. And to use max age, we basically add expires in 10 minutes. What this is going to do is it's going to set a header, which gets sent back to the server, max age 600. So it's saying, for the next 10 minutes, this content can be locally served, locally cached. Content's valid for 600 seconds, unless, of course, refresh is pushed. It sort of seems to be a default with browsers. If somebody hits refresh, then it's going to go to the server anyway. But if a server clicks off, I mean, sorry, if a client clicks off of that page and comes back to that page, it's going to load it out of their local cache. For the next 10 minutes, then you've got e-tags. E-tag is basically a key we can use to see if the page is the same in a nutshell. And by default, Rails uses e-tags, whether you know it or not, your application's using it. What it's doing is every time a page is requested, the whole body is being generated. That body is getting turned into a hash using this function here, and then that's what gets sent back to the client as an e-tag. With Rails 2.2, we were given the ability to specify a custom key for that e-tag. Typically, this is where we have models. So we might call the post.cache key method, which I'll explain what that is in just a minute if you're not familiar. Let's take a look at a function with e-tags. So we get a user, and now we're going to call ifstale e-tag user. What this one line of code does is two things. The first thing that it does is it calls cache key on the user model when this comes in. It's going to create a string which looks like this. This is basically the ID of the model and the updated add field of the model. It's going to take that, work into a hash, use that as the e-tag which gets sent back to the user. Now, if the client comes back to that page, it's going to send that e-tag back. It's going to check to see if the e-tag that it was given the first time matches the one it just generated the second time it came in. If it matches, it's simply going to send back head not modified with nobody back to the client browser. The client's going to render what it has in its local cache. So we can actually add some functions here in the conditional statement. So if the e-tag doesn't match, if it's stale, we can actually do extra stuff, render out a web page, whatever we need to do. Another way to write this is to use the fresh win command. The benefit of using the e-tag is that we don't have to do any extra rendering. By default, Rails out of the box is going to create the e-tag by kind of hashing up the entire body of the page, whereas here, we're only hashing the values that came out of the user model using the cache key method. I hope that makes sense. It's a pretty complex topic. But we need this to get further towards reverse proxy caching, which is where we're headed. So ratcache, varnish, squid, and akamai. These are reverse proxy caches, and I don't know about you guys. But when I first saw this, I was like, what the hell is that? How many of you guys feel like you know what reverse proxy caching is? OK, a couple of you guys. Well, I'm going to try to define it in very simple terms, which is what I like doing. But before we define what reverse proxy caching is, we need to figure out what a proxy cache is. So here we have a big corp. This is a corporation. A lot of people from this corporation like to visit the wallstreetjournal.com. They go out and visit that. Now, they might have a lot of traffic, a lot of traffic going in and out. So the boss guy goes to the sys-edman, or the IT person, and says, hey, we need to reduce network traffic. There's always people visiting, always websites. Let's save some money. What can you do to reduce network traffic? The sys-edman, one solution, might be to put a proxy cache in the middle between the server and the users. So now when a user comes out and goes to wallstreetjournal.com, the first time that happens, it's going to cache the wallstreetjournal.com locally in the proxy cache, send it back. Now, the second time somebody goes to that website, it's going to load it straight out of the proxy, saving network traffic. So now that we know what that is, what is a reverse proxy cache? So here we've got our typical client, browser, and server configuration, as most Rails apps have. Let's see. And again, boss goes to the sys-edman and says, hey, we need to make our website more responsive, handle more throughputs, and save bandwidth, maybe, save CPU cycles. So what the sys-edman might do is create a reverse proxy cache on the server side. So a client comes in, requests a URL. That gets pushed through to the server, back to the reverse proxy. Reverse proxy cache is that, sends it back to the client. Now, of course, the second time a different user comes to that same URL, and it's going to load it at the reverse proxy, rather than going all the way to the server on the server side over here. So to review, proxy cache is an extra layer of caching on the client side. Reverse proxy cache, or gateway cache, as it's referred to sometimes, is an extra layer of caching on the server side. And this is where rat, cache, varnish, square, to knock them out come in. These are all reverse proxy caches. Now, with this diagram here, if you went to implement it, there's one thing that I've kind of left out that you need to be able to deal with. And that is, how do you deal with expiration? It's something we deal with a lot with when you're dealing with all types of caching. How do you invalidate the cache? How does that happen? And it turns out that you can do expiration by going and using the headers, which I just talked to you about a second ago, using maybe max age. So how would we deal with expiration using max age? So here's Bob. Bob goes into the reverse proxy, goes to the server. The server maybe has this Rails code, which I showed you a second ago, that gets sent back to the reverse proxy with max age 600, that gets stored in the reverse proxy, and back to Bob. Now, if Bob, at any point in time within 10 minutes, goes back to that same web page, well, it's going to load it out of his local cache, right? However, if Cindy, a different user, requests that same path, it's going to load it directly from the reverse proxy. It's not going to hear a Rails server anymore. So for the next 10 minutes, all requests to that URL are going to get served through the reverse proxy. So the benefit of this, of course, is we avoid lots of server hits. We can handle more throughput. Maybe it's important for your website to stay up to date, but maybe if it's only up to date every minute or so, that's OK. If you can change it and set max age to 60 seconds, you're going to save a lot of bandwidth. OK, now eTags is another way to deal with this. Bob requests there, does a request, goes through the server. We set the eTag, gets sent back to the reverse proxy, stores it along with the eTag in the reverse proxy, and that gets sent back to Bob. Bob then requests the same page. What's going to happen here? It's actually going to send to the server again. It's going to validate the eTag, send back head not modified, and send back head not modified to Bob. So we're saving server side time here, because we don't have to render out the entire page. And we're saving client side time, because the client isn't having to get all this data from the server back and render the page. They simply render what's in the local cache. Now here's where it gets really, really cool. Different user, Cindy comes into the web page, requests a URL. This is where it's really cool. What the reverse proxy is going to do is it's going to append the eTag to Cindy's request. So it's going to go to the server with the eTag that it has stored. If server returns head not modified, it's going to return what's in the cache from the reverse proxy. That's really cool. So max age eTags and last modified. I skipped over last modified, because I was trying to keep things short. But last modified, it's a lot like eTags. You can watch the screen cache to learn more about it. I go into it in more detail. So the benefit of using these is we can decrease server load, increase the speed of our website. However, with a lot of these, as you saw with eTags and last modified, we're still going to hit the server on each request. That might not be too good. So what do we do to deal with that? Well, we might end up using a combination of both max age eTags or max age and last modified. Here's where things get really powerful, and you can start serving millions of requests. So what would that look like if we combined the two? Bob comes in again. And now on our server, we're going to use both the eTag and it expires in max age header. If I could send back to the reverse proxy, send back to Bob with max age. Now here comes Cindy. Cindy requests the URL, and it's been within that 60 seconds, that minute of time. Well, it's simply going to return the HTML and the eTag back to Cindy. Now Cindy comes back and requests that same URL, and it's been after 60 seconds locally. Oh no. If it hasn't been after 60 seconds locally, well, it's just going to run out of her local cache. But if it's been after 60 seconds and it's been after 60 seconds at the reverse proxy level as well, well, it's going to go to check with the eTag. I guess I'm missing the eTag there. Send back head loss modified. And send back head loss modified again. And now what's in the reverse proxy cache is going to be valid for another 60 seconds. Now just to give you another perspective of how scalable this really is, let's take a look at a convoluted benchmark that I hypothetical benchmark. Let's say we have a million page requests at 0 seconds, a million refreshes at 30 seconds, and another million refreshes at a minute. What is this going to look like? So first of all, 1 million page requests at 0 seconds. We've got down at the bottom here how many times a Rails server was hit. First thing that's going to happen here is we're going to hit the Rails server for that first request. So we have one server hit. It's going to store all of these HTML eTag in MaxAge in a proxy cache. It's then going to reserve the remainder of the hits out of the cache. OK, at 30 seconds, what's going to happen here? Well, it's going to serve them all out of the proxy cache. What's going to happen in a minute? Well, now it needs to revalidate to make sure that data is valid. So it's going to check to see if the eTag is fresh. So hit our server once. And then it's going to serve the remainder of the requests out of the proxy cache. Now, obviously, this example has some flaws in it, but it just goes to show you how amazingly scalable something like this is using Rails and a proxy cache. So Akamai. What is Akamai, and how does that work? So here's our Rails server. What Akamai does is it puts reverse proxy caches all over the world. So if we were dealing with 3 million page requests really, that's going to be split up over different proxy caches. So maybe each proxy cache is only handling 600,000 each if they were evenly distributed. And each one of those, when it needs to get the code, when it needs to get the page, well, that's going to hit our Rails server. So in this case, our Rails server is going to get hit maybe 10 times, and not only that, but we're going to get a quicker client load because all of the data is going to be loading from a closer server to our client because things are locational. So now to Rack Cache. We took the path. So now what's Rack Cache? Rack Cache, in my opinion, is reverse proxy training Rails for your Rails app. It runs inside your Rails app, and you can run it as middleware in Rails. And I'll show you guys how to do that in a minute. So here's how we do it. We can install the gem. And in our environment, we do something like this. It might be a simpler way to do this, but this is what I had to do to get it working. And here we're using Rails 2.3 syntax, where we're simply saying use this middleware. So what does that look like when we run it? Basically what this does is run a reverse proxy inside of our Rails process. So when a request comes in, it's going to hit the reverse proxy, go through that first, then it's going to go to Rails. Now what you might be thinking, when I first thought, when I saw this, is wait a second, what if I run multiple Rails processes? Is each one going to have its own reverse proxy with its own reverse proxy store? Well, no, because it's more intelligent than that. You can use a file store, or you can just put memcache in the middle to store it all. Pretty simply. So I went ahead and tried this. Right, I was like, let's get this working with the configuration you see here with these different headers. And the first time I tried it with ratcache, it didn't work at all. Totally did not work at all. I was like, what the heck is going on here? Well it turns out that Rails by default sets this cache control header, which looks like this. So all of your requests, all of your responses have this cache control header, which looks like this. And this private variable right there is saying to proxy caches, don't cache this. Whatever you do, don't cache this. So not only at the reverse proxy side is it saying, don't cache this, but the real reason we have it there is because we don't want maybe the regular proxy to cache this information either. Oh, it's like that's annoying. Why would we want things to get cached as much as possible, right? Rails runs faster, let's make everything cached. So I was like, why isn't this public? Why don't they create this header as public? Well it turns out, well when you have this sort of scenario and you've got this proxy cache from this big company. If the wallstreetjournal.com was coded in Rails, that's fine, we don't care, Wall Street Journal, it's news, that'd be fine if the default was public, it'll cache everything possible. But what if somebody coded a bank application in Rails? Okay, and what if they forgot to set the cache control header? Now it's gonna store your bank information in your company's proxy cache. Not good, right. That's why the cache control here is by default set to private. So how do we deal with this? Well, you gotta add a little bit more code, look something like this, so in order to make these work, you have to make sure that the public, that the header is set to public, and you can do that using these code bits right here. This isn't very pretty, I hope it gets changed. Maybe because you hoot is sitting here in the audience, it will. But this is how you do it right now. So I thought I'd put together a little screencast so you can actually see this in action. So check this out, here's my little basic blogger Rails app. And we're gonna use rack cache with the new middleware in Rails 2.3. So add a top, now at the bottom here I'm going to say that I wanna use the middleware. That's all there is to it in the environment to config. You can see here, I've got the typical post controller just for a blog, nothing out of the ordinary there. I'm gonna go ahead and start up my server. Oops, go to the index action. And as you can see here, up at the top, it's using a rack cache, so it's intercepting every request and right now it's just a cache miss because I haven't set any of these headers. Now I'm gonna add my expires in piece of code there. So expires in 10 seconds, I have to set this private false public true so it'll set the appropriate header, save that. Now if I go back to my server here and I do a refresh, now it's gonna be using rack cache. And you can see every time I do a refresh down here, you see these numbers, it's saying it's valid for five seconds, three seconds, it's loading out the cache, one second, and now I do a refresh. And hey, the cache was stale, it then stored it for another 10 seconds, did the request down here, and it's storing that in my reverse proxy cache. Now let's do some ETag business. I'm gonna go down to the show method and I'm gonna say if stale ETag, so I'm simply gonna use the post model in there, need to set the appropriate header. Now if I go to the show page, I can see down here that it rendered the page. Now the second time I do the request, check it out down here, I can see that it sent over 304 not modified. Cool, but that's not the real test. The real test is using another user, remember Cindy? So I've got a little browser up here, I just called it Firefox, so this is a brand new request, Firefox is gonna go, and hey, it also did 304 not modified, and it delivered what was in the cache. So basically appended the ETag to this new request and sent that back to the user as you would expect. And of course you can have some fun with Firebug, with Firefox, so I can see right now if I do a refresh on this page, you can see this time it sent out 304 not modified as you would expect, loaded the content out from my local cache. So Rack Cache is training wheels, meaning of course that it's still in beta, right? It's not a full French production application, don't go and throw this on your production app, but it's really good for getting familiar with using these conventions and starting to really take advantage of a reverse proxy. So an interesting configuration might be to use this maybe in development and staging, and then in your production interface, use one of these, because each of these is going to behave in the same way, it might have a slightly different configuration, but it's going to behave the same way and you can take advantage of ETags and max seconds and whatever. So, okay, there's lots of other middleware that you can install with Rails, although I haven't seen too many people blogging about how to do it, I'd like to see more people do that. There's a list of middleware, the URL to get to this page is of course on that Rails envy page that I linked you guys to, and there's a couple other options here for middleware. This isn't just for Rails, this is for any rack application. One of these in the list is CloudKit. CloudKit is awesome. CloudKit makes web services look so easy. I mean, kind of like the first time you looked at Rails and you saw how easy it was to create web apps, I get the same feeling when I look at CloudKit for web services. Basically, CloudKit, all you have to do is this, and you've got a JSON web service, which properly uses rest, as most of us are already familiar with, so that you can add new notes and add new projects and manipulate them in that. This is all you need to create a web service using CloudKit. I'd like to see somebody use this with Rails. I haven't seen anybody write a tutorial on how to use this. It might be useful if, for instance, you've got some models on the back end that you simply want to expose as a web service. So you just plug it in, and all of a sudden you've got a JSON web service that goes straight into your models. No brainer, pretty easy, without having any, why create the scaffold for it? If you don't need all that scaffold, if all you want is a web service, why not do something like this? Next thing I want to talk about with innovation is internationalization. There's been a lot of really great work with internationalization over the past few months with Rails 2.2 coming out with IE-TNM. I found this page, the other week, which is a wiki, listing a bunch of great tutorials and a bunch of great libraries so you can very easily make your web application international. It's fantastic, the support we have for that now. One of the most recent libraries that I saw that we talked about in the podcast this last week was one called Translate. So with the internationalization in Rails 2.2, what you end up with is a bunch of YAML files, right? You've got your English translations, you've got your Spanish translations, you're each in another YAML file. But when you've got a big website and you have these hugely YAML files, they might get a little more difficult to maintain. You might want to have outside people, translators come in and give you translations, but you might not want them missing around in your YAML files, right? So what these guys did is created a plugin which gives you a web interface which will manipulate your YAML files for you. So you can give them a web address and they can say, okay, I want to translate from English to Spanish, go, and it'll list out everything in forms and they can just type in the translations, update the YAML files for you. Awesome. Metric Foo is also worth talking about just because it seems to bring in all of the great code metric applications. Every time a new one and standardized one comes out. Jason and I do a lot of code reviews, right? Companies come to us and they say, can you take a look at our application? Can you help us refactor it, let us know where we need to improve? What's the first thing that we do? Run Metric Foo, it'll show us exactly where things need to get refactored, where the tests are lacking, where their code smells, you know? So it's a great way to figure out why do you need to improve your code because it runs a bunch of different metrics on it. It's also worth mentioning. If it rails innovations, we have to mention MIRB, right? With MIRB 1.0 coming out earlier this year, and now merging with Rails, I mean, it's taking all the innovation which they've put into MIRB, the MIRB team, and bringing that into Rails, and Rails is gonna be better because of it. I'm really excited to see where Rails 3 goes. Also, Ruby on Rails guides, I'm really curious here, how many of you guys have read through one of the Rails guides? Okay, so most of you guys, that's good. Some of you haven't yet. There's some really amazingly useful information in these guides, like here's the list. There's a lot of stuff in there. Some of the really cool stuff, like I read through the securing Rails applications guide earlier. Oh my gosh, so much information about security, everything you need to know about that. The kind of information that, you know, you go to like an enterprise corporation, you know, someone's bound to ask, well, what are the security concerns with running Rails? And this guide goes through everything you need to know. It's awesome. Also something I was really impressed with it, came out recently is Noel Rappin, came out with railsprescriptions.com, which is like a blog, slash a book, slash a PDF. And on here, he's got this awesome PDF which shows you how to do test-driven development with Rails for so long. There was not a good guide for showing people how to do this. And, you know, he's got stuff like this, you know, first test first, and he walks people through, okay, we're creating our test for our application, now we're gonna go implement it, and here's how you do it. It's like a 60-page PDF, shows you how to do TDD. It's just awesome for beginners. And if you're not entirely sure how to do TDD. Lastly, I thought I'd mention HTTP, or HTT Party by John Noonmaker. John Noonmaker, if you're not subscribed, who's blog, like Rails Tips, please do, comes out with a ton of great information every week. HTTP Party, it evolves out of some of John's project, because what he ended up doing, you see here, he wrote like a Twitter API interface, Last FM, Magnolia Delicious, all of these Ruby interfaces, like Gems and a valued interface with these APIs, right? And what he found is every time he implemented one of these APIs, he was like redoing the same code over and over again to kind of take in the XML, you know, translate it, put it into objects, blah, blah, blah, right? So what he did is he kind of took the common patterns and he created HTT Party. So if you ever need to create a web service interface for Ruby, you know, interfacing with anything, this is your starting point. Look at HTT Party and use his gem, because it'll make things a lot easier. And you know, that's all I've got. If you guys have any questions, you wanna come back up here, Jason, about any of the things we went over, I'd be happy to take them. And don't forget to check out the screencasts, the free screencasts on Scaling Rails. I hope you guys find them useful. Any questions? Is it too early to call? Yeah. So for HTT Party, if there's already an active resource declaration, so that you can process it, you can create an object pretty automatically, if you, the fact that for that it's more for services that aren't implemented in active resource declaration, that's a good, well, active resource. You know, it's good if somebody, if a web server is really stuck to the web principles, right, to the, like the RESTful principles, like, you know, we all do, but most APIs out there aren't gonna stick to the standardized REST principles, so if you really needed, if you wanted to use active resource, you could, but you'd end up having to probably hack it up a little bit more, and I think you'd probably be better just going with HTT Party to interface with it. What's the short answer? Any other questions? Yeah? Just to follow up on what you said, active resource is really intended to talk to your own Rails apps mostly, like for an API between your own, we haven't had a long conversation about this, not only about extending active resource to make it more viable for API that are kind of an active resource-ish, at the conclusion, one of which probably is HTT Party, and we're not really having active resources more for talking to your own APIs. Can you go ahead? No, I mean, Hoot is up here, but he was saying that active resource is more for just talking with your own Rails applications locally, and if you need to interface with other web apps, web services are probably better off just using HTT Party. Any other questions? No? All right, thanks for your time, guys, we appreciate it.


What's good YouTube?  Make sure you click Post notification so you will be notified the time your boy Johnson. He and today we finna do a little blog man Y'all finna be following me all through the day And what I further do like get into the video I Know that thing off in the man So what been good with you guys you feel hope everybody getting up man having a good day today I Action Airplace to finish up We'll let y'all see what I got so far. It's coming along pretty good And if y'all want me to do more blogs just let me know in the comments below and I will be making more videos like this Yeah, y'all just let me know man if y'all want to see more balls you feel me y'all do your boy Your boy will be glad to let y'all follow me And we talk about nonsense Yeah, man, like I know y'all been wondering why I've been posting a lot because this is what I've been doing every day Everyday just coming out here working on this building as soon as I finish man. We're gonna turn back up We're gonna turn right back up you feel me the grind on stop I'm gonna try to hit I Want to hit a million subscribers in like a year man? You feel me so I know I'm gonna have to put in more work to accomplish that Instead of just not posting videos I decided just to bring the camera with me see how it works man They got here dancing y'all can't even see on that nigga.  That's a little good I want to grab me a smoothie man. Yeah Just walking with the game. You know I'm saying me and the creative game for the go-ahead check out the bed You want to come with us? inside the My followers you gonna see you're gonna act like she don't see y'all Come on go in you want park over there by me All right, we can see about it. It's just sitting in the car But yeah, man, you know I'm saying It's all just It's all just about you guys man. You know I'm saying I decided to start bringing my camera alone Y'all tell me if y'all like this man because if y'all don't like me blogging We're gonna strap the whole thing you feel You want to get in you want home? Well, it's a little soapy you want some Lord have mercy now. I'm trying to eat healthy man Trump ah that fry what trying to get it back and lead to the set Another place. I wouldn't take y'all inside After we're going actually I want to take y'all inside second and Charles They got so much dope stuff. I'm talking about from old video games coming books Just a lot of vintage special man, and I've been buying comic books from there lately For inspiration or like some art ideas So we're gonna walk in there and look at a couple coming Time I hide and where we on our way walking inside the place now action there And I would like to thank you guys for all the lovings I don't be like pull up.  I want all the smoke. I want all the smoke. I wouldn't eat natch Why you gonna give me the thing so it can say This is no food. There ain't no food. That's a drink Fools or solids Give me my god. I know you ain't reliable It's almost finished though.  It was all a dream.  Oh, no, she wanted to I just had to hurry up and get it over with you feel me She wanted to color it in Interesting so yup, it's coming together man Everything's Everything's coming together Right now