Hi and welcome to our talk about patterns of multi-cluster in Kubernetes. It's awesome to see so many people. We weren't necessarily expecting a packed room, but it's really cool. I'm Dan McKean. I'm a product manager at MongoDB. And I'm George Hansaras. I'm an engineering director at MongoDB. Together we lead MongoDB's effort to support Kubernetes, specifically through Kubernetes operators. And you probably have spotted that there's a third person in the presentation, but only two people here. Our colleague Mircia, he's contributed a lot of information and insight to this presentation. He couldn't make it today, so this is our way of crediting his contributions both in our multi-cluster journey as a product and as a presentation. He's also following closely the multi-cluster SIG. And there's obviously a lot of overlap of the topics discussed there and what we're going to present here, but we're going to try and keep this through our perspective and try to tie theory with kind of our decisions on multi-cluster. Yeah, we're not claiming to be absolute experts. And if you are a member of the SIG, please don't raise your hand. We don't want to be even more nervous. So MongoDB's interest in multi-cluster Kubernetes started a few years ago before either of us actually joined the company. It came about because we had customers wanting to run MongoDB within Kubernetes across multiple clusters. This was something we already supported with MongoDB itself on kind of VMs or bare metal, but we didn't yet support it on Kubernetes. And although a few did kind of go ahead and build it themselves, the time and the complexity to do so made us realize we needed to do it formally and properly. So that's kind of where it came about. So we've come a long way since then and we've invested a lot of time and effort. We've reviewed. We've revisited a lot of our decisions. So in this presentation, we're going to try to kind of squeeze in all of this experience in this half an hour. So we're going to cover a few things today. And to try to keep it interesting, we're going to keep on alternating between theory and our decisions and what we are doing. So we're going to, we're going to present some concepts and considerations before showing you how we chose to implement them. So for that, we're going to look at our own multicluster implementation in the Kubernetes operator for MongoDB enterprise. We wanted to hold their hands up at this point and admit that while it's not all open source at the moment, we are, we are heading towards that direction. As you can see, it's quite a packed agenda and in all honesty, each of these topics could easily have been a 35 minute talk all by themselves. So we're going to do our best to give you an overview and kind of explain our experience as our perspective with some time for Q and A at the end. We can start with the motivations and benefit from multicluster. Talk a little bit about the architectures before kind of digging into the network centric pattern, which we'll explain in a minute. We'll talk about each of the three key challenges that kind of revolve around implementing multicluster, cluster inventory, workload, distribution across clusters and networking. And then we'll cover the considerations for multicluster operators and controllers before finishing off with our own thoughts on this topic. So multicluster offers a number of benefits. Improve performance and reduce latency by hosting services closer to the end users. Companies can significantly improve the application performance and the user experience by reducing latency. Compliance and regulation. Some regions have strict data sovereignty rules that dictate where data must be stored. Some even require that data has to be stored in a certain way, such as different clouds to ensure that the data is never lost. And finally and probably the biggest and most obvious reason for most companies is the high availability, disaster recovery and data redundancy, hosting both the services and the data across location ensures that failure at one has minimal impact. So we wanted to dig a little bit deeper in terms of MongoDB itself to illustrate how this actually works in practice and why we decided multicluster made sense. So MongoDB offers two topologies that work well with multicluster. Replica sets that offer data redundancy and high availability by maintaining multiple instances of the same data. And sharded clusters that split the data into shards and each shard is effectively a replica set. This ensures that each shard has redundancy and that the data can be split for performance or geographical distribution. So both replica sets and sharded clusters are supported by MongoDB Enterprise operator and with replica sets directly supported at the moment for multiclusters and sharded clusters coming soon. So that gives geographic distribution of data across different Kubernetes clusters that can be in different availability zone, different data centers, or even different cloud providers. And once sharding is supported that gives the ability to segment data and localize data in a specific Kubernetes cluster. We were able to get a lot of a leg up by the fact that MongoDB already has these capabilities. We just had to make it work within Kubernetes. And when it comes to multicluster, there's two major architectural models, though each has a lot of, there's a lot in each about different ways of doing things. So on the left, we have the Kubernetes centric model, kind of more often known as cluster federation. It's all about establishing some sort of shared control plane where the goal is to enable developers and operators to treat the multiple clusters as one when deploying managing workloads. To do it, you have a federation control plane and a high level that's that's the kind of two main components. There's the API server to provide the single unified API point for users to interact with the federation and manage workloads and a controller manager that actually manages the lifecycle of federated resources. Now, on the other side, we have what we call the network centric centric model. The concept there is distributing workloads across multiple distinct clusters, each of which has its own control plane. Now, Kubernetes operators deploying and managing workloads on the clusters have to interact with each cluster independently, using each of the API servers in the different clusters. But the underlying clusters are managed individually by the administrator. So we don't try to provide the view of one single cluster. So while neither is simple of the two models when it comes to actually deploying and managing workloads, federation simplifies things by allowing you to treat everything as one cluster. And the multicluster tooling helps you kind of put all the complexity under the hood. On the other hand, distinct clusters can offer more resiliency as one cluster failing has no direct impact in the rest of your infrastructure. Now, in our case, we're focused on distributing workloads across distinct Kubernetes clusters to support users who've not yet deployed federated solutions, federation solutions, and who want the increased resiliency for their data of totally separate clusters. So the network centric model is the primary focus of the next slides as well. So the network centric or workload distribution comes with its sets of patterns and concepts. So the hub cluster pattern refers to a model where you have one central Kubernetes cluster, typically known as the hub, managing one or more additional member or spoke clusters. We're mostly going to call them member clusters through the rest of this talk. In this setup, something in the hub cluster, usually a Kubernetes operator and controllers, is responsible for centralizing the management tasks and acting as the multicluster control plane for workloads running across the member clusters. This includes deploying applications, managing the workloads, setting global configuration, potentially distributing shared secrets, controlling access, integrating into and leveraging CICD pipelines, centralized monitoring and logging, and more potentially. Applications can be deployed across the member clusters from the hub cluster, taking into account factors like their workload requirements, the need for geographic proximity to users, optimizing the use of resources, their high availability needs, etc. There's different schools of thought about whether workload resources should be run on the central cluster or not, but from the customers that we have already deploying MongoDB, which uses the hub cluster pattern for multicluster, we've not seen anybody that isn't deploying their workloads on the central cluster as well. So another model can be described as the replicated architecture, replicated application architecture. In this case, an entire workload or it can be even an entire stack is replicated to another cluster, and the whole cluster itself, in my cases, might even be cloned to another location, to another cluster. Depending on whether the database backing the application is also replicated, centralized, or somehow distributed, it's possible that this architecture could still serve to provide some of the benefits like performance increase, reduced latency, load balancing, and so on. Now, if the secondary cluster is not actively serving traffic, it becomes more of an active passive setup, which we might be familiar with. And this is a less cost effective option, though. And lastly, multicloud, which is arguably less of a pattern on its own, and more of an implementation choice that can apply to either of the other two. Here, you can see the hub cluster pattern is implemented over three clouds, two private clouds, and in this case, Amazon EKS, just as an example, third cloud. It's something we're seeing from a few companies with the highest requirements for resilience. It also seems that a lot of customers are using this kind of hybrid on-prem and public cloud approach as a tentative step towards trusting the public clouds with their most critical workloads. The biggest challenge with multicloud is ensuring that your choice of tools and mechanisms are supported across the different environments. This makes it incredibly important to choose tools and mechanisms that are compatible with base Kubernetes, because that's the consistent elements across different Kubernetes-based distributions. This does limit how much you can use the value add capabilities of different clouds, whether private or public, that they typically layer on top of their own Kubernetes offerings. In the case of the MongoDB operator, we've chosen to go with the hub cluster pattern, the first pattern you saw. So the central pattern has a few different capabilities. First off, it hosts the Kubernetes operator and acts as the control plane for multi-cluster deployments. It hosts the MongoDB multi-cluster custom resource in which the operator defines a deployment. And optionally, it can host the MongoDB management server that we call OpsManager. And as we mentioned before, it can also host members of the MongoDB deployments. It can host a replica out of a replica set. Member clusters, the only thing that they do is that they host MongoDB replica sets. And while the data plane is already resilient to a cluster failure, we're currently working on making it easier to recover both our operator and their management server, OpsManager, to another cluster. So until we can offer a highly available operator, this will at least make disaster recovery quicker and easier. Now we're moving on the three key challenges that we need to be solved to successfully implement multi-cluster. The first of those is cluster inventory. So cluster inventory is kind of what it sounds like. It's all about keeping track of the clusters included in a multi-cluster environment. But this covers more than just listing them. There's cluster credentials, which arguably are bare minimum. You need these in order to be able to access the clusters and to manage workloads across them. And between the kind of cluster addresses and the credentials, you can actually deploy and manage workloads. But another arguably pretty firm requirement is cluster health checks. There's really no point in trying to deploy to a cluster that's missing. Many solutions, ours included, provide an inbuilt mechanism to monitor clusters and redistribute workloads to healthy clusters if a single member cluster goes down. And lastly, cluster resource tracking. This is less of a hard requirement, but very much a nice to have. It's something most multi-cluster efforts seem to be aiming for. It's very similar to how Kubernetes monitors nodes within a single cluster, assesses their resources, and works out which you can reschedule or schedule pods to to ensure that they have sufficient resources. In the case of multi-cluster, that's more complicated as you're not just talking about the nodes in the cluster. You're talking about multiple clusters. It's also valuable to be able to configure rules that actually govern and dictate when and where things should be moved to give users the control over where things are running. And it's useful to support affinity and anti-affinity to ensure that workloads are running where they're needed to. Now, in going back to our use case, for the cluster inventory, we have a relatively simple approach that we've built in-house. Firstly, we require the creation of a number of our back resources on each of the member clusters. This creates the service account used to manage resources via the cluster API, via each cluster's API server. Next, we need a cube config secret for the member clusters. You can see an example of that on the right. So, the cube context needs to contain the address of the cluster and the certificate created with the service account. And at the bottom, you see the user to use, including the token created for the service account. Now, while we see some companies automating this, we also provide a cube-cuttle plug-in that does it all for you by creating the namespaces, automating the application of the RBAC on the clusters, and creating the cube context on the central cluster, the hub cluster. It's worth mentioning here that our automation uses the legacy long-lived API tokens for the service accounts. And in the future, we'd like to switch to using the token request API to refresh credentials used to access the member clusters. Now, we're on the second key challenge that someone needs to solve to successfully implement multi-cluster, which is workload distribution. So, that relates to how workloads are actually distributed across the clusters. For example, in this simple diagram, we've got a hub cluster pattern across three clusters shown vertically. Each of the three workloads shown horizontally has a different distribution across the three clusters. And there's a number of considerations that can factor into how you distribute a workload, the required level of redundancy, the required geographic spread, either for resilience or to locate workloads near to users or other systems, and the resources available on each of the clusters. For example, workload one in blue may be serving users in each of the three locations where the cluster is running. And it may also need three replicas to provide the level of performance that's needed. Workload two in the yellow may primarily serve users in the location of the central cluster, but want the resilience of running copies in each of the other two clusters. And finally, workload three in the orange may have arguably the simplest requirements, primarily providing a service in the central cluster with resilience only needed on one of the others. So, it's also possible that there may be affinity or anti-affinity considerations in play to ensure that certain workloads remain co-located or distributed from each other. Going back to the MongoDB operator, we've chosen a declarative approach for workload distribution across multiple clusters. So, you can see that in the custom resource, we include the cluster spec list parameter. Users can set how many members of the replica set they want on each of the member clusters. And then we deploy the appropriate stateful sets on each of those clusters. Now, in case of a member cluster failing, the operator is able to automatically redistribute those workload, those stateful sets on the available clusters. And this is currently enabled in the operator level, so this is not shown here. Using the automated redistribution seems like it kind of undermines GitOps workflows, which are usually used, but the changes are stored as annotations and they persist while the administrator is able to restore the lost cluster. They can then manually reconfigure the distribution. So, multi-cluster is pretty impossible without the networking needed to connect the clusters. So, there's actually two subtopics within this, larger topic. There's inter-cluster connectivity, connecting the clusters and their workloads together. But there's also egress and ingress to or from within the clusters. They have pretty similar set of considerations. There's network topology. It's critical to consider how connectivity is already or can be established between the clusters and also to external services and users. There's security, what kind of security, what level of security do you require between the users and the workloads or between the workloads? And is it going over private networks or the open internet? Changes things considerably. Performance, how can you maximize the performance of the connectivity? Is it sufficient for the workloads you're running multi-cluster? And finally, reliability and resilience, how will you ensure that the connectivity is reliable and fault tolerant? So, looking into inter-cluster networking, there's a number of different options. First shown in the top left, we've got the VPN option creating a secure tunnel between the member clusters. On the top right, we have VPC peering, which creates a private network connection between different VPCs where our Kubernetes clusters live in. On the bottom left, we have load balancers and they expose traffic services externally and they connect through the internet. And lastly, we have the service mesh option. Service mesh is the most popular option amongst our users. They can provide routing, load balancing and security for communication between the clusters and even for services and users that are external to the clusters. So, we found that it's rarely the case that MongoDB is the first workload spanning multiple clusters for our users and most of the users already have a service mesh like Istio, Lingardee or something in place. And there are also cloud providers, specific service messes like MeshApp for AWS, Anthos service mesh for Google and so on. Moving on to Ingress and egress, which we're going to cover quickly, there are a few different options. Again, top left, we've got load balancers. They expose the services on a public IP providing ingress and egress. For multi-cluster ingress, typically you need a global load balancer that actually distributes and balances the traffic between the different clusters. On the top right, we've got service meshes again, again the most popular choice for our own users, which enable inter-cluster connectivity and provide routing, load balancing and security for external access. Bottom left, we've got network policies that can control the traffic to the clusters and between the clusters, but again they need something to distribute the traffic between the clusters. And finally, bottom right, we have the ingress controllers, great for managing ingress traffic, but again they need something to distribute the traffic between the different clusters when you're running multi-cluster. Now in the case of our operator, we wanted to allow users to choose how they want to handle networking. We've based our own quick start on the use of service mesh and specifically STO, which we use to do our own testing, but ultimately users just need to meet the minimum networking requirements, which is FQDN resolution between the workload pods across the different clusters. We also have guidance for using load balancers, but so far we've seen most companies choose to use service mesh for network connectivity. If they don't, as we just saw now, there's a number of options that they can use, but it's ultimately up to them to ensure that the connectivity between clusters is there and working to support the deployments. Now we're going to move on to multi-cluster controllers and operators. This could be a huge talk in and of itself, and it's actually one we're thinking about doing perhaps in Paris next year for the next KubeCon and CNCF. So there are a number of considerations when designing controllers and operators. Consistency is a massive one. You need to maintain a consistent state across all of the clusters. That can be challenging if different clusters are running different flavors or versions of Kubernetes and may even have different hardware and software configurations. Again, this makes compatibility critical. Resilience, mainly to cluster failure. This ideally covers both the workload and your multi-cluster control plane, whatever you're using. And scalability to support a large number of clusters and workloads. And finally, a big one, security to protect both the control plane and the workloads being run. Now in terms of functionality, there are a few key areas that unsurprisingly align with the topics that we just covered. First off, cluster inventory and workload distribution. Ideally, it should take into account the available resources on each cluster and what performance requirements the workloads have. Failure, handling. Ideally, the workloads remain healthy even with a cluster down, but at the minimum, a user should be able to reconfigure as needed. Preferably, this would be automated. So able to detect failures and take corrective actions such as rescheduling workloads to remaining healthy clusters. Monitoring and observability. Administrators need to be able to monitor both multi-cluster control plane and its managed workloads. This means that your solution should emit metrics and logs that can be used to track their performance and health. Ideally, via external and commonly used systems like Prometheus, alert management, manager and so on. Now, we're taking a slight departure from the pattern of covering a bit of theory and then looking at what we did at MongoDB. Instead, we're going to take a quick look at a couple of prominent options that already exist for implementing and deploying multi-cluster. So these solutions are agnostic of any particular vendor's offering, which means they don't take into account the logic of a service like MongoDB, for example, but they do allow you to run existing workloads across multi-cluster environments. Kamada and Open Cluster Management are two of the more prominent CFCM projects that we're aware of. I don't doubt there are probably others, but these are two that we're aware of and we picked to talk about. They've been a source of inspiration for us for both the existing and future iterations. They're both great solutions for implementing multi-cluster distribution in a unified manner, without relying on custom controllers for each piece of software that you're trying to deploy. Like I said, some tools like MongoDB have this kind of multi-cluster functionality built in and it has the advantage of catering to our own logic and requirements, but obviously at the cost of not necessarily being able to support other services running multi-cluster. We're not going to go into massive detail here, since both of these do a lot, but there is a lot of overlap, such as considering cluster availability and resources, automated or manual failover of workloads between clusters, and cross-cluster service discovery. They also both offer solutions to cross-cluster networking, which as we mentioned, we don't. We are relatively unopinionated about that, though each does do it in a slightly different way. One slightly subjective difference between the two is that Kamada is a bit more abstracted, while open cluster management offers more control through prescriptive configurations. They can both run with an agent on each of the spoke or member clusters, which pulls the config from the center cluster and applies it, but Kamada can also run on an agentless mode by pushing configuration to the member clusters, again through the respective API server of each cluster. And one last difference that we can see being useful to some users is that Kamada supports retrofit fitting a single cluster workload to multi-cluster. So having a look at a couple of great existing solutions and also talked about the considerations for building your own multi-cluster offering or just choosing one off the shelf, we wanted to reflect on some of our decisions at MongoDB by sharing some of the changes we'd like to potentially have made in the past, but at least make going forwards. And perhaps some of these might help you on your own journey identifying what you need and what you need to do. So as you saw today, we offer a relatively prescriptive approach to workload distribution. We mentioned the declarative approach. So you said how many instances of a replica you want on each of the member clusters. This works, but we would love to abstract it a bit more. It is a bit counterintuitive if you think of Kubernetes primitives and the philosophy behind it. So today we compute an index of each of which instance of the database lives on which clusters. Users can see the index in annotations, but can't edit it even though if you would like to. But what they really want is to decide where the primary instance of their database lives since that's the only one that they can write on. And that's the important part. They don't really need to edit the index. They just need to prioritize the list of clusters and have the operator manage things so that the primary ends up in the right place. That's one of the things that we hope to offer in the future. For us, resource awareness is also another existing piece. Although we check the availability of the clusters in order to potentially reallocate workloads in need and also to deploy them in the first place. We don't currently check the available resources. Essentially, for us, this pushes the resource allocation problem onto the users, which is, again, something we'd like to make easier for them in the future, as it's especially something you don't want to have to consider in a DR scenario. On a similar note, we do offer automated failover, like we said, but it's not highly customizable. It's also on or off at the operator level. And while it's valuable, we'd like to make it on a per workload basis and iterate to give more rules and more control over when a workload should be redistributed and even potentially how it should be redistributed. And lastly, we'd like to make the operator highly available, have it spun multiple clusters. It's easier to restore it on another cluster than it would be for our database or management server, but it still is a single point of failure for this setup. Having the operator also run on other clusters could also have an added benefit. We would be able to offer a pull model, as we described before, for that similar that Carmada does. This would allow secondary operators on each member cluster to intermittently pull configurations from the center cluster and apply it locally instead of the current model which, well, the model of having, of pushing from the central cluster to the member clusters. This would be really good for scaling and supporting multiple Kubernetes clusters, but also allows for secondary operations to member clusters to make changes in the event of losing the central cluster, electing a new primary or putting a database in read-only mode on a single cluster cutoff, and so on. So we're very close to the end, which also means you're all quite close to getting lunch, which I'm excited about. Before we wrap up with some Q&A, we wanted to share some final thoughts on what we see being the future of multi-cluster. Some of this may already be more in progress than we're aware of, but this is kind of what we imagine coming up. The first and most significant thing we expect is that it becomes significantly easier to run multi-cluster systems, likely through more powerful and user-friendly multi-cluster management tools. There's always a drive to simplify across kind of our ecosystem and community and automate and abstract the complexity further and further away to make it much easier to manage. We've already outlined a couple of existing projects that are making great progress here. We don't think that it will stop, but simplifying for the cluster admins either. You also need to consider the developers who want a simplified and abstracted way to actually deploy across multiple clusters without knowing all of the finer details about how it necessarily works at a deeper level. Most application developers don't have the time or the inclination to become Kubernetes experts. The next is almost a cliche now, increased use of AI and ML. It's already started. There's a load of boots in the expo hall that you can go and see that are already working on this and integrating this into what they're doing, but we're expecting this to be used in multi-cluster management and arguably Kubernetes use in general. This can free up the administrators to work on more strategic tasks. We're also expecting better network support for multi-cluster Kubernetes. This is one where there's already a lot of work happening. There are a lot of interesting CNCF projects. Some of them are cloud agnostic, commercial offerings, and of course, this is something that cloud providers already have many solutions. And finally, the bullet that's been there all along. Better support for hybrid and multi-cloud deployments. As we mentioned, we're seeing some of our users spanning across more than one cloud providers, some even using it as a stepping stone towards cloud adoption, some on-prem, some on-cloud. And multi-cluster Kubernetes management tools need to provide better support for these type of hybrid and multi-cloud deployments. And that's it. This QR code or link, they go to the same place on the right. We'll hope you get to various related reading materials from docs about where an operator, if you're interested in that, to infer about the CIG multi-cluster.  It's really interesting reading. If you enjoy this, then you'll probably enjoy that as well. To more about Commada and open cluster management, because we talked about them and we're fans. But now I think we do have a little bit of time for questions. If you do have any, please make your way to the microphone as this is being recorded. And that way, people will be able to hear your questions as well as our answers. The MongoDB has two modes of operation. All the writes go to the primary and then the reads can't come from secondary. Sorry, can you get a little bit closer to the microphone? So yeah, so MongoDB has two modes of operation. Strongly consistent and more like eventually consistent. Reads can come from stale secondaries, right? It's multi-cluster setups. What's the typical deployment? Your customers run them in a strongly consistent manner or eventually close to the manner? And how's that specified by your users? It varies on the use case, but through our operator, whether it's multi-cluster or not, they can configure how many nodes need to be written to before it's confirmed as written to. So effectively they have control over it on a per application basis and it does vary based on the use case as to whether they need the speed or the guaranteed consistency. The reason I ask is that how do customers specify a strongly consistent or eventually consistent to the federated services or community subtraction? Is there a way for them to tune them? Yeah, it's the same way across both types of solutions. I think the terminology is called write concern and I think the default is that it has to be written to the majority of members of the replica set, but they can alter that. They could say that the write concern is one in which case as soon as it's written to the primary, they'd get an acknowledgement that it's written. They could say that it's all in which case they get maximum consistency and it's guaranteed to be written before the application gets a response saying that it's been confirmed written. You did speak about the improved resilience with the multi-cluster design. I just wanted to get an idea of how you undo same maintenance modes across multiple clusters. Sorry, I missed that. How you undo like maintenance modes across multiple clusters, cluster upgrades, post them, replacements, etc. Like that kind of thing. How that process, how you orchestrate it and move it. Did you catch that? No? Sorry, we're not hearing you that great. Okay, the summary is how do you handle maintenance modes across the multi-cluster design that you are selecting? Did you say maintenance modes? Yes, maintenance, yeah. Like Windows rather, maintenance modes. In what sense do you mean maintenance modes? No, maintenance windows is the question. Oh, maintenance window. All right, okay, I see. Well, that's not something we've necessarily got a great solution to that we've built into Kubernetes. MongoDB already takes into account that. Our upgrades, for example, though, are done in a rolling fashion even across multi-cluster. If you needed to upgrade, the operator will actually handle that and do it in a rolling fashion. MongoDB already has support in for that. Most other impactful changes are done in the same rolling fashion as well. That mostly covers most of the maintenance that's required. That's covered by the part we said that you use a declarative configuration to define what number of replica sets lives in each Kubernetes cluster. If for any reason, one cluster is brought down for maintenance upgrades, whatever, then these are going to be rescheduled to the remaining clusters. The control plate manages that automatically. Yeah, the operator manages that. Transparency moves the visit in the same easy, and you try to attach the same volumes, or how does storage, basically, how does the new replicas coming in the new cluster get seated with the right storage? Well, that's something that happens not because of the operator, but because of Mongo. Essentially, because as we said at the beginning, we want different Kubernetes clusters to be isolated and not managed in the same way. We're talking about different PVCs, so it's not easy to... Essentially, what happens is that you spin up a new replica set, and Mongo takes care of replicating the data there. Yeah, as if you would add a replica set into your Mongo deployment and then it takes care of it. It's similar to if you scaled and you added new members of the replica set, they would just synchronize the data. That's automated, so they're identified as effectively new members of the replica set. At the moment, we haven't gone that far in that sense in addressing that. That's something we're very conscious of and pod disruption, as you say. It's one of the iterations, but if we listed all of the changes we'd like to make, we'd have been here all day. But yeah, thank you. At the moment, we're using static API tokens to actually manage the workloads on the member clusters. As we mentioned, we'd like to switch to the more automated model with the automated rotation and so on. At the moment, we're avoiding it by having static. If someone were to rotate those on the member clusters effectively, we would lose access to manage the member clusters. That's one of the reasons why we want to move forward and iterate on that. How does the hub cluster call each of the API servers? That's if I understand correctly. The first step of setting it up is we set our back in all of the member clusters, and we create the roles to give access to the member cluster API. We issue the tokens and those are all stored in CubeSecrets in the hub cluster, and those are used to make the API calls. Don't remember that. Yeah, I'm not sure. But this is one of the advantages of moving to a pull model. If we could have the operator BHA, then we effectively have an agent running in each of the member clusters, and a lot of those considerations get easier. Well, essentially, it's just a cube cluster where you just install the operator, and then that becomes your hub cluster for their MongoDB deployments. There's no other official designation other than the fact the operator is running there. And then the other question is, how do you handle it? So that's another thing on our to-do list, eventually. At the moment, you'd have to go on to any of those hub clusters to pull the relevant logs for our workloads running there. That's why we propose you use something external, like Prometheus, because then you can add an extra layer like Add Thanos or something else, and then you can have a unified view of what's happening in the different clusters. Thank you. Thank you. You're one of the scary people for us anyway. So when I was doing research, and I was talking to, in particular, Mertz here about this, I kind of asked, like, are these tools solving some of the problems that we want to solve? Now they're gaining maturity. Why wouldn't we move over and stop worrying about building our own? And we kind of had this long and in-depth conversation about the fact that there's so much bespoke logic to MongoDB that we want to take into account. Building those considerations on top of that would probably be as expensive as us just continuing our journey with our own solution that already takes into account lots of that logic. And it's also a matter of reducing the number of tools that our customers need in order to use it. We have seen cases where people don't even want to use hell more. Like the bare minimum, so we try to use only the bare minimum, so we make it easier for everyone. In general, we're very unopinionated about third-party tools, because if we recommend anything, let alone require them to be running anything, then they expect us to know loads about that and support them on that. And we honestly, we don't have the time and the expertise to be able to do that sort of thing. So yeah, thanks. I have a question about Rob Cluster. How did you set up watches across different clusters running a single copy of an operator? Did you use some kind of framework or all your own? Do you have any issues with latency, et cetera, watching remote clusters? So we're using, I don't quote me on the terminology, but we're using a health endpoint on the member clusters to basically check their availability. We'd like to go deeper and check their resource availability as well. In terms of latency, no, we haven't experienced any latency problems either in the kind of control plan of our multi-cluster setup or in the workloads, but we can't take credit for the workload aspect. That's MongoDB's inherent functionality. But there's no MongoDB operator? No, they're not. The operator on the central cluster is literally just using the API server on each of the member clusters to manage the stateful sets that it's running there that, although they're individual stateful sets across all the clusters, it effectively amounts to one replica set. And it's watching, right? For changes across one group of clusters. Yeah. Okay, thanks. Well, because we deployed the stateful set, within that Kubernetes cluster, a lot is managed automatically using the inherent stateful set functionality and so on. So like if the pod is last, it will be replaced and so on. And we get a lot of that for free because of Kubernetes is brilliant. And somebody deletes a stateful set there. You can make that again and stuff. Yeah. So we're still reconciling periodically to make sure that what's running on the member clusters is correct. Okay. Thanks. Thanks. Sorry, I don't know if we're positioned badly to the microphone, but we've been struggling to hear a lot of people. So regarding to the rolling upgrade to the multi-cluster, so do you provide the new features running well, like on a single cluster, while the deployment is finished by the first cluster? So is that seamlessly so that there is no chance to test on the separate cluster to see if the feature is deployed or not? So if I understand correctly, if we have a rollback mechanism, if we do a rolling upgrade on multi-cluster, do you have the answer? I know we have visibility of it and we expose it in the status of the custom resource that you deploy in the central cluster. I don't know if that answers the question. So it will be exposed from the central cluster that some of the features deployed to maybe one or several parts of those multi-cluster racks. So maybe I can have a denies to only just separate clusters so that I can test if the feature is already deployed there or if some arrow comes up so that I can roll back the deployment or something. So you upgrade only one member and if it goes okay, then upgrade the others? Yeah, actually that's what we are currently doing now. So I'm wondering if that is implemented in your system, so maybe it's an automatically process so you roll up rolling updates to all the multiple clusters. So I'm wondering if there is a point that I can check if that's running well in the deployed cluster with this new feature. So for the actual kind of functional features of MongoDB itself, we don't have that at the operator level. There's a lot of interaction with the management server which provides the automation config and all that. At a kind of upgrade level for instance though, if we upgrade a given member of a replica set, we wait until it comes up and reports healthy before we then move on to any of the others. So if it failed and got stuck, we wouldn't proceed. I think that's all the questions. Thank you everyone for coming.


Hello friends, I am Naval Emul, working as an assistant professor in Mechanical Engineering department, Walsh and Institute of Technology, Solapur. In this video, we are going to study the introduction to SyLab Part 1, Learning Outcome. At the end of this session, students will be able to explain different mathematical functions of SyLab software, content, introduction to SyLab, MATLAB, history of SyLab, how to download and install SyLab references, introduction to SyLab, SyLab is pronounced as Sy that is scientific and lab that is laboratory. SyLab is a free and open-source cross-platform numerical computational package and a high-level numerically oriented programming language. SyLab is a free software alternative to MATLAB. It is free and open-source software. It is free and open-source software. Figure 1 shows the logo of the SyLab MATLAB. MATLAB believed to be used by over a million users in industry and academic appeared in late 1970s and has become a hot favorite of users who are either not skilled or simply uninterested in getting entangled with syntax of languages like C or Pascal even to solve a simple problem. MATLAB is a numerical computing environment and fourth generation programming language. It is developed by the MATWARKS. Among MATLAB's capabilities, the key is matrix manipulation. The name MATLAB itself is an acronym of matrix laboratory handling of functions and data, implementation of algorithm and creation of user interface. MATLAB is a proprietary software and a license fee is mandatory for its use. The free software movement attempts to offer technically, ethically superior and free alternative to proprietary softwares. There are many free open-source alternatives to MATLAB. In particular, SyLab is very popular. So Figure 2 shows you the window of the MATLAB. Free software. Wikipedia defines free software as follows. Free software or software liberal is software that can be used, studied and even modified without restriction and which can be copied and redistributed in modified or unmodified form either without any restrictions. Free software is available free of charge in most cases. It may be noted that there are currently alternative terms for free software such as software liberal, free and open source software that is called FOSS. SyLab is free and open source software that is called FOSS. A free software generally permits four kinds of freedom to its users. The freedom to run the software anywhere and anyway. Freedom to copy and distribute. The freedom to access to the source code of the software. The freedom to modify and redistribute. So we will see what is the history of SyLab. In 80s the CACSD that is Computer Aided Control System Design software was created at IRIA in France. Then at the beginning of 90s the software name changed to SyLab. It was then developed by the SyLab Group composed by six researchers from ENPC. SyLab 1.1 the first released version of SyLab was put on site on January 2, 1994. Think what is the necessity of SyLab? Why you should choose SyLab software? Think for few seconds pause the video. Okay let us see why it is necessary to use SyLab software. So the syntax of SyLab is very easy as compared to any other software like C and C++ or Java. SyLab is free software and it is easily available. Numerical problems can be expressed in a reduced number of code lines as compared to similar solution using traditional languages. There is a very large user community in SyLab that uses and supports SyLab by contributing in the form of mailing list, usenet groups with internet discussion system and their websites downloading and installing SyLab. It is very easy to download and install SyLab. So SyLab works and it is available for different platforms such as it works on window platform and Linux and Mac. The homepage of SyLab is www.sylab.org. So this is a homepage of SyLab. Once you open the homepage click on download. There are various options which are available for windows platform, Linux as well as Mac. You can click on that your file gets downloaded and just click on the downloaded file and run the file. The setup file will be installed in your PC or laptop and that SyLab is ready to use. So after installing the SyLab window it looks like this. So this is a freshly launched SyLab window. You can see the console window and above the console window there is a file menu which is described in the next video. So let us see the simple calculations on SyLab. What we can do on SyLab is with this example we clearly understand how simple the SyLab is. Suppose if we type x is equal to 5 and use semicolon followed by that then followed by enter then take y equal to 6 semicolon then followed by enter. Here the value of 5 is assigned to x and value of 6 is assigned to 5. Then if we multiply 5 and 6 just we need to type x into or asterisk y we get the result as 30. This operation is performed on the SyLab and the image of that is shown in the figure. So it is very simple just assign the value of x assign the value of 5 and the operation which we need that is x into y just type x into y you will get the answer. So we will see what are the different operators that are frequently used and accepted in SyLab. Plus sign for addition, minus sign for subtraction, asterisk sign or multiplication sign for multiplication. Then for division we use slash sign and raise 2 that is cap sign for power operations. So we have taken a few examples how we can use SyLab. So first we have taken addition, addition operator that is plus sign 5.5 plus 3.75 the answer is 9.25. In the same way we have taken a minus that is subtraction operator 6.0 minus 2.36 we get answer as 3.64. Just you may need to type 6.0 minus 2.36 then press enter you get the answer. In the same way we use for multiplication we use for division and we use for power also. Very simple just you need to type 2 raise to 6 and press enter you will get the answer as 64. All these operations are found in the SyLab and it is shown in a screenshot. So all the operations are performed. It is very simple and very easy as compared to the traditional languages like C and C plus plus. These are the references I have used. Thank you.


Welcome to Chrome Dev Summit. I'm Ben Galbraith. I lead product for the Chrome platform teams. And I'm Dion Almer, and I lead product for our developer ecosystem efforts. Thanks for joining us here at the Yerba Buena Center for the Arts here in San Francisco, and a special shout out to those of you watching on the livestream. We look forward all year to this opportunity to gather with developers from around the world to celebrate the web platform. And of course, it's an opportunity for the Chrome team and others here at Google to provide updates on our latest work and get feedback from the community. 2018 marks 10 years since the launch of Chrome, but it also marks Android's 10-year anniversary and 20 years since Google was founded back in 1998. So this is a really big year for us, and it's got us reflecting on these past 10 years. Back in 2008, Dion and I were at Mozilla working on developer tools when we received probably the most unique product announcement we'd ever seen, the Chrome comic, which walked through Chrome's new features, like the OmniBox, and architectural innovations, like the multi-process architecture, and the high-performance V8 JavaScript runtime. And years later, it's really fun to note the V8 was reused by Node.js and plenty of other open-source projects out there. Chrome launched in this time in the midst of a web renaissance back in the Ajax movement that saw developers pushing the boundaries of what was possible on the web, doing things that we just hadn't seen before. And it's amazing to see just how far the web has come in these 10 years, with publishers like Huffington Post transforming the typical documents of the web into rich interactive experiences. And Google Maps, an early pioneer of the Ajax era, had gone from maps of tiled images to a street-to-space continuum combining 360-degree photos, vector maps, 3D models, and satellite imagery, all just in the browser. And productivity apps have come into their own on the platform with pro tools like the incomparable AutoCAD and the collaborative design platform Figma. And because they're on the web, you can get right into these things. And when you're done being productive, you can pop into high-quality games like Crossy Road for just a minute. Just a couple. Just a quick minute. And Chrome's changed quite a bit over this time, and more than just these subtle changes to the logo. Earlier this year, we highlighted Chrome's new refresh design and updated usability enhancements, such as better tab treatment for people like Dion that have like 500 tabs open at a time. That's true. And also a smarter omnibox and autofill features. But the most important update was clearly the birthday mode in the Dino game, which run for the entire month of September. Do you know this has played over 270 million times a month? That's incredible. It kind of is. But here at CDS, it's really the platform-related features that we want to talk about. So let's highlight a few. So back in 2008, Chrome launched with Process Isolation, an architecture that put each tab in its own operating system process, making Chrome exceptionally stable, but also exceptionally secure. The process boundary acts as a line of defense in the event malicious code is able to exploit a bug and attempt to read data from another tab. Over the past 10 years, this model has become the industry standard. This year, desktop Chrome browsers took this model further with the launch of Site Isolation. So now Chrome ensures that even within a single tab, content from different domains is isolated. So in this example, in the iframe, this new site is using a display ad, and it's running in a different process than the rest of the page. We've wanted to extend Process Isolation this way for some time, and we think it's an important protection for the web. Now, we've also been continuing our efforts to encourage developers to use HTTPS for all web traffic. This ensures that the content of a site isn't maliciously modified while in transit, and also that user data is transferred securely. In the latest Chrome, we mark pages as not secure when they're served from HTTP, and when the user begins to interact with form fields, we further emphasize the point with a stronger warning. The HTTPS movement is a collaborative effort with organizations like Let's Encrypt plan a big role in lowering the barriers to upgrading sites, and it's working. In Chrome itself, we've seen big shifts to HTTPS, and over 80% of the top 100 sites are now all HTTPS. We think this is actually a major accomplishment because the web is such a massive ecosystem. All right, in addition to security and stability, speed was a big theme for Chrome at launch, and V8 is a big part of that story. The team recently posted a retrospective highlighting its improvements over this period, including significant gains in JavaScript execution speed and a 100x decrease in garbage collection jank. And the team is looking forward to the next 10 years of improvements by optimizing V8 for the latest JavaScript language features like Promises and Async08, supporting the Node.js server-side community, and being responsive to the needs of the framework ecosystem. There's a fun recent example of this. How the team rapidly responded to JavaScript inefficiencies related to the React frameworks recently announced Hook's feature, finding ways to make this feature work much faster on V8. Now, V8 has also expanded to support WebAssembly, also called Wasm, a cross-browser standard for executing low-level code like C and C++ at very high speed. Earlier this year, the team launched the new Wasm compiler called Liftoff, and the popular Unity game engine found that it resulted in a 10x reduction in the load time for their Wasm code. And WebAssembly threads are now available in a Chrome origin trial, which opens the door for more complex code to come to the web. Now, it's been really fun to see the community explore the power of WebAssembly, both through new creations and by bringing old codebases. Actually, I think I prefer the term vintage codebases. Vintage, vintage, high-quality codebases to the web. This tweet was one of my favorites, kind of an inception moment, because now I think you can run, i.e., on Windows 95, on Chrome, on Android. It's crazy. What a world we live in. It's hard to believe, but back when Chrome launched, video on the web wasn't a thing. We had to use plugins. And now, of course, HTML video is ubiquitous. This year, Chrome landed support for AV1, which is the next-generation media codec, completely royalty-free, that provides a 30% bitrate reduction, even over HEVC, which makes streaming video on the web faster as this becomes adopted. And because AV1 has major industry backing, we can expect to see it receive significant adoption over time. Now, one constant over the past 10 years is the importance of optimizing images. This is sort of like flossing for the internet, vital for your site's health. Yeah, plenty of us don't really seem to do it enough. And as a Brit, trust me on that one. Now, a few years ago, Chrome added support for WebP, a new image format that results in an average 30% savings over other formats, like PNG, JPEG, and GIF. GIF, was it? Oh, sorry. And this year, Edge and Firefox ship support for WebP, so make sure your images are fully squished. All right, so the web and Chrome have come a long way these past 10 years. So where do we go from here? We've just spent the last few minutes talking about the importance of speed and the enhancements to the web platform that make that more possible. And we think this will continue to be a major focus for all of us into the future, because speed is one of the defining features of the web platform. It's what makes it so magical to go from a link right into a rich experience seamlessly without any delay. Now, deliver and speed is a partnership between the browsers and developers, because no matter how fast and efficient browsers become, a poorly optimized site will always ruin the fast load in experiences that our users want. And increasingly, JavaScript can also become a major factor in slowing down sites. It's because since 2001, sites use an average eight times more JavaScript than they did before. And that's a problem, because in addition to having to be downloaded, all this code needs to be compiled by the browser and executed. And with mobile, many of the devices that our users are using are slower than they've been before. And so increasingly, performance can include the CPU as a bottleneck. Now, we've created tools like Lighthouse, PageSpeed Insights, and the Chrome User Experience app that can provide deep insights into your site's performance and how it can be improved. However, as helpful as these tools can be, a pattern we've seen is that a site's performance will degrade over time, because we're constantly adding new features to enhance our site. And these new features create pressure for the site to get bigger and bigger. And that includes more script and more resources that have to be downloaded. Of course, we're not saying that we shouldn't be constantly enhancing our sites and adding features. But as we do so, we have to take care that as we add these features, we ensure that our pages continue to load fast. So an approach that we've seen that's led to great results here is the practice of establishing a performance budget. And popular tools and frameworks, like Angular, Preact, and Webpack, have built in support to define budgets and enforce them. These budgets can be based on the bite-size of your resources, or they can ensure you hit target metrics and scenarios. For example, you can specify that your site should load in under five seconds on a mid-range smartphone and a high-latency 3G network. The team at Pinterest have set a great example of using a budget to guide their optimization efforts. We'd love to share a video that explains this process now. Let's roll the video. Pinterest's mission is to help people discover things, collect them, organize them, and then find ways to apply them in your life. With more and more people on the go, the mobile web has become central at providing our discovery experience. But our mobile web experience in the past was basically an upsell for the native app, which brought us to the realization that we needed to fix it. The technology was already in place for us to be able to do so. And so we brought a team together to rebuild the mobile web from scratch. Having a fast mobile web was crucial to the success of the project. We made sure that we split out what was sent down to the user to be only the crucial things to start, and then everything else that wasn't immediately important sent down later on. We made sure to test out on average devices on 3G, just like our users would be using. And we could see the dramatic difference that there was on that initial time to interactivity. By using modern caching best practices and service worker, even if you're on a bad connection or have no connection, we were able to preload the user interface for follow-up visits. Like the native app, our site was optimized for touch interactions. This immersive experience resulted in mobile web becoming our top platform for new sign-ups. We wanted to make sure that the users for our mobile web continue to use the product as time goes by. And one of the most important technologies that's been added to browsers was the ability to add that site to your home screen. Pinterest is not just about the content, but about what you do with it. The browser is a discovery platform, so making it easier for Pinterest to use our own discovery service is really a perfect fit. Thank you. Pinterest is a great example of doing performance right. And Zac from their team is here to share more with us later today. Now let's talk about another example, Wayfair. After experiencing some performance regressions, they created an internal dashboard that provides a simple stoplight system for their developers and keeps performance top of mind. Since they implemented this system, they've seen consistent speed gains across their sites, and their year-over-year conversion rate has increased by over 10%. OK, while we're talking about speed, we'd like to tell you about two new web platform features that we're implementing in Chrome that we think may lead to more instant and seamless web experiences. Web packaging is a new feature that allows developers to sign a web page with a special encryption key that proves the page's original domain and creates a sort of package that can be served from anywhere and that the browser can securely represent with the page's original domain. Now, Portals. Portals adds a new iframe-like element to HTML that allows users to seamlessly transition into the portal's content, making it a new top-level web page in the process. Taken together, these new standards enable the browser to securely preload pages and deliver experiences like this that transition to the new site instantly. Maybe I'll show it again. Sure. Tapping you're right there instantly. Tomorrow, we'll talk through more of the details and explain how you can start experimenting with web packaging right now. We're pretty excited about this in the impact that we think it can have on the web. Loading fast is important, but so is delivering a buttery smooth UI once the page is displayed. Buttery means responding to user input, like taps and typing, instantly and ensuring that the page doesn't jank or sort of skip around as the user scrolls and interacts with it. Now, traditionally, this hasn't maybe been the strong suit for the web, but we think that things are changing. So today, we're releasing Squoosh and is an example of how responsive complex apps can be on today's web. It demonstrates a really fast-loading experience using WebAssembly to compress images using C and C++ libraries and employing web workers to handle long-running tasks in the background, enabling a smooth UI even while the app works really hard. Now, this is a full PWA. It works across mobile, desktop, tablet, and offline too, thanks to ServiceWorker. Let's use Chrome's DevTools to go under the covers of Squoosh for a moment and take a look. Here on the screen, we can see different browser processes that work in the app. And if we zoom in to three of them, the main process and the workers, we can see in the main process all these vertical lines. And each vertical line indicates when the main thread's busy and the app can't respond to user input. And you can see here they're all generally pretty narrow. And then you can see in the workers, we have these really long bars representing these long-running tasks that would shank the snot out of the UI if they were in the background. Now, if Jake can get his nerves back, he and Mariko are going to join us later and do a session on how they're able to build this application. So sometimes there are tasks that you can't actually move off of the main thread, such as code that updates the UI. With the recently released off-screen canvas feature, now in Chrome and behind a flag in Firefox and Opera, helps here by letting you paint to image surfaces like canvas and WebGL in a worker. And then copy the image buffer back over to the UI in a single fast operation. The video here shows how off-screen canvas maintains a smooth UI even after we artificially add code to make the painting process expensive using that jank bottom in the middle. It's pretty smooth. Tomorrow, we're going to tell you about more features that are coming to the web to help with smooth, buttery UIs, such as new APIs for background code called worklets that make tasks like animation, audio, custom painting, and custom layout easier, a new web component called a virtual scroller that makes it easy to develop really smooth scrolling views over large data sets, and a task scheduler API that gives developers more control over how the browser spends its time. That's a lot, but as Mariko said, you could never add enough butter. How true. So having a fast-loading responsive website is key, but so are the things that it actually does. So on that note, let's talk about some of the web's latest integrations with the underlying device and operating system. Let's take the Spotify PWA as an example. With it, users can go straight from a link right into Spotify without having to install anything. And with the web's full support for background audio, DRM, and offline, Spotify can provide a full featured web experience. And now Chrome supports desktop PWAs, letting apps like Spotify run in their own windows and be easily installed on Chrome OS, Windows, Linux, and soon on the Mac. I think desktop PWAs are really handy when you've got lots of tabs open, like Dion, as I mentioned earlier, and you want to keep your favorite stuff really easy to get to, like with the Twitter PWA that we're showing here running as a desktop PWA in Chrome Canary on the Mac. And what's really cool about Twitter is that they've got experimental support that enables their mobile PWA to run at desktop screen sizes, as we're showing here, which has kind of been sort of the dream of web development for a long time. Well, on the topic of desktop web apps, we also recently implemented new web APIs in Chrome that enable unfettered access to input devices. So web apps can receive full keyboard input elements, sample games pads at high resolution, and enter immersive full screen modes. All of this is perfect for apps like the recently announced Google Project Stream shown here. Speaking of media, we've also taken the recently released picture-in-picture feature that we have on mobile video over to the desktop, which makes web video on desktop more of an integrated experience. And another important new web API is WebOrthN, which enables websites to integrate with biometric sensors and other forms of multi-factor authentication. It's currently implemented in Firefox Opera Chrome, coming soon to Edge, and it can make web checkout a seamlessly secure experience. So in here with the checkout and with PayPal, and it displays the authentication challenge as integrated with the device. So as the web's capabilities increase, it's also important to augment the security and the privacy of the platform and ensure that everyone has an opportunity to participate in the open digital economy. This is why we've been leading the development of advanced new privacy techniques, like federated learning and secure aggregation, that enable personalized digital experiences that also have the strongest privacy guarantees. And we've been hard at work reviewing the fundamentals of how the web works with respect to privacy and personalization. And in the next year, we'll be shipping new features into Chrome, as well as new server-side technologies that help us uphold the highest standards of user privacy with regards to data collection and usage. Now as the web evolves and we get new capabilities, we're constantly focused on interoperability, on how well web apps work across browsers. And we know this topic is top of mind with developers too. To this end, we've been collaborating with other browsers on an open-source, comprehensive web platform test project. And we're pleased to share that these tests, the browsers are becoming more interoperable as measured by these tests. And we're continuing to collaborate with the other browsers on reference docs for the web on the Mozilla developer network. These efforts are resulting in a less fragmented developer experience for all of us, which frees us to spend our time not chasing down compatibility bugs, but on adding more features to the platform and performance budgets. We also think it's more important than ever for us to make it easier to create high-quality web experiences. So to this end, we've been working on a new learning website called web.dev. On web.dev, we start out by explaining the principles that we've found lead to top-quality sites, such as speed, discoverability, and reliability. And we follow these up with guides that explain why you should care about a given concept. They provide clear tutorials and offer plenty of sample code. We've also partnered with Glitch to embed their popular coding tool right into the experience, which provides an interactive learning environment for getting hands-on and letting you remix and test your code. And we've integrated Lighthouse into the web.dev experience, giving you a platform that lets you track the scores of your websites over time. And if your site isn't quite at a perfect score yet, it also gives you instructions on how to resolve the specific issues that it's found with your site. So that's web.dev. We'd love to get your feedback, especially while we're here together at CDS. And by the way, if you like that .dev domain, check out get.dev for details on how you can register on for yourself in the future. We also have another fun learning project that we want to share with you. We've collaborated with Dave Getties, who's created interactive tutorials like Flexbox Zombies and CSS Grid Critters. These are real things, and they're really cool, to develop Service Workies, an online adventure that helps you really deeply understand Service Worker soup to nuts. It's a fun, free, engaging way to learn. So please head over to serviceworkies.com to sign up and start the preview levels that launch just now. Now, we've also got plenty of updates to our developer tools and libraries that we're going to share over the next two days. But there's one new tool that we'd like to tell you about. We call it Visbug, and it puts a new spin on how developers and designers can interact with web pages. We'd like to give you a demo. And to do that, let's invite Adam Argyle up to the stage. Please welcome Adam. Hello, guys. Thanks for this opportunity. So developers, you got a lot of tools, and, well, your keynote is amazing so far. You're spitting fire. I'm back there laughing, and I'm telling you, it's awesome. So I wanted to give some tools to people that don't generally feel like they have a whole lot of power on the web unless they open up the Chrome DevTools. Chrome DevTools, of course, are omnicapable. But, oh, that's right. I got my screensaver. Came on. Let me just type my huge password here, because. That's a cool screen site. Oh, for sure. Got to love that. OK, so I'm going to hit Play on this side, because, OK. So I wanted more people to be able to contribute to good web experiences and be able to inspect and dissect things. And so consider what Zeppelin is as a designer to develop her handoff. I've created this thing called Visbug that essentially gives those tools in reverse. So this first tool here is the guides tool. Have you ever held a piece of paper up to your screen and be like, ooh, this is lined up? There you go. There's even, like, I think, a Chrome extension that just does this one thing.  That looks generally aligned. Yeah, let me just kind of hover a little. Yeah, well, it's great. And this is kind of interesting. Look, I can go into a nested hover state and still check what's going on there. So that's just the grid tool. There's a whole bunch of tools. I'm going to do my best to show you more of what's going on here. This is the accessibility tool. I really want accessibility to be something that more people are aware of. It's a little, there's just too many steps to find what is there. So this, you just hover now. You just hover for color contrast. You hover for surfacing aria roles and tab indexes. So basically, the things that you're generally looking for are now a hover away instead of maybe a five or six clicks. And the same sort of thing is for styles. So you can hover over SVG. You can hover over buttons. Nothing is off limits to Pixelbug. It's kind of punk rock. It's like, hey, is there Dom there? I'll look at it. I'll tell you what's there. And so here's what you. And so let me go through a couple more tools. I really like the hue shift tool. And so if you go download this Chrome extension, you just have to hover over a tool. And it'll show you how it's used. I'll do my best to walk through the keyboard shortcuts that I'm doing. But it's kind of like design Vim at the moment. Anyway, it's super fun. So what I'm going to do, I'm going to select this path. I'm going to make sure I got my hue shift tool. I'm going to hit Command E to expand my selection. I'm just going to hold it. And look at that. So I selected all of those path nodes. The way that that worked is it expanded based on the node name and the class name. It found similar elements that were siblings. And I'm just going to add some black here. Is that magical? It feels magical. If I hold Control, I can make my selections go away. So I can be like, ooh, do I like it? And in this case, I think black's wrong. I'm going to add some white. I'm going to hit Shift and Right to add some hue. And then I'm going to rotate the hue with Command Shift and down. So I'm rotating the hue by values of 10. And now I can explore color palettes. I love this particular tool. It's HSL-based. It's awesome. So another thing I want to show you real quick too is the Move tool. You can just move things in the DOM around.  Right? Why haven't you had this before? It seems to make so much sense. So I'm just going to rearrange it here a little bit. I'm going to hit M for margin. And I'm going to hit Shift Up. So Shift Up, Shift Up, Shift Up. I'm just adding 10 pixels of margin to the top. So consider that these little quick tasks were things that you had to nest and find. And now you can do them in the chaos of the browser in production. I wanted the DOM to be the source of truth. I wanted a design tool that treated the DOM as a source of truth. Anyway, I like this site because it's like, ooh, super flashy. And this tool doesn't care. Let's get a little meta and take a quick look at Squoosh, which was just introduced. Super rad. And the first thing I want to do is talk about some of the additional tools in here. But I want to troll Jake a little bit while I'm up here. So what I'm going to do first, I'm going to grab this image. And I'm going to turn it into myself. So have you ever wanted to just swap an image on a web page? It's just drag and drop. Why hasn't that been there? A lot of the stuff I do, like here's another one. Double click for text editing. Let's just make this drag and plop. Because, again, I'm trolling him.  We'll look at what styles he's got in here. Nice and good flex box. So I'm going to select this image. I'm going to hit Command E again. Here's a fun idea. I borrowed from XD. So I'm very inspired from XD and Figma and Zeppelin and even developer tooling, too. So watch this one. I love this one. I'm going to go in here. I'm going to grab two images. I want to grab a picture of me. I wish I had other pictures. Who wants to see my face multiple times? Anyway, I want to drag in two images.  Take focus. Take focus. Take focus. Oh, good. I was just impatient. Here you go. And I'm going to hover there. Ping-pong. Just sort of was like, hey, how many? I don't care. It'll just fill it up. Super fun. OK, so we're done kind of like trolling his home page. Let's actually go do something meaningful. He asked me to do a design review. OK, so I hid my tools. The site doesn't even know I changed it. Let's drag in something fun. I like this Christmas eggnog picture. Yeah, this is good. Me and my wife. Hello. And so we have this very complex website. It's backed with Wasm. And maybe conceptually, you're just like, there's no way I could kind of help design that. Well, of course you can. It's Pixelbug. It doesn't care. So I'm going to expand it. I'm going to get some things into like a nested state. Something that's theoretically harder to design with.  I'm a fan of like Retro Wave right now. And I love those like purples, pinks, and stuff on dark. Let's do that to this site really quick. So I'm going to launch Pixelbug. And we're just going to use a couple of features here. So I'm going to hit this header, because I think these need to be a little bit more pronounced with some accent color. I'm going to expand my selection by clicking a class name. So what's cool is BEM and just dynamically generated class names. What they do is they create a consistency between related nodes. And so I leveraged those. You just make a selection. And you can hover on the classes tool. And they'll pseudo-highlight. Anyway, this tool is so full of features. I'm having a hard time talking slow. OK, so anyway, I got these headers. I just want to spoof these up. So I'm going to get rid of their opacity by doing command shift right and left. You can manage opacity.  I'm going to add some hue by adding shift right. And I'm going to change the hue to hot pink. Super rad. OK, so then I'm going to go in here. And I'm going to darken this up. I like how transparent it is, but I've got this darkness vibe. I just dark. Just darken it up. OK, and we'll come down here. And this should look like magic right now. So I'm just doing shift down. I'm just adding black.  Look, he's a number input. You can navigate the entire DOM with your keyboard. So I'm going to hit Tab. I just tabbed me to the next child. Hit shift down. I'm going to black that out. That's fun. I'm going to grab this. I'm just going to black that out. And we'll get rid of the tool. And I will send a screenshot to Jake. And be like, this is how it should look, dude. It should be pink and blue. Come see me in the forum. I've got more stuff to show you. I mean, there is like, it's weird. It does a lot of weird stuff. And it's really fun. Nothing is awful amidst this tool. And I hope content writers, web designers, just people finally have a tool that helps empower them in the DOM. It should feel like a document. It should feel like an art board. That's the illusion I'm trying to go for. Awesome. Thanks, guys. Thank you. Give it up, Adam. That was awesome. Thank you so much, Jeff. It's been a pleasure to reflect with you on the past 10 years and what's new for the web. Before we go, we want to give a brief mention to Chrome OS. It's a great way to engage with the web and with support for Linux and Android apps. It's also ready for web development. We're offering a 75% discount on the Google Pixel book to all CDS attendees so you can check it out. The vouchers will be available tomorrow morning before the first session begins. So don't party too hard tonight. And with that, thank you very much for joining us here this morning. And let's all work together. Thank you.


Fran, are you still down in the labyrinth or have you escaped? I did a rover, but it's a little bit of sort of out of the frame pan and into the fire for me because I am here with a robotic arm behind me which apparently is used for eye surgery which Carlo, who is from King's College London, you're not going to do the surgery on me, are you? I don't know, we'll see. No, we won't. So what is it that we've got here? We have a nice setup with a 7 degree of freedom robotic arm which holds the surgical robot which helps surgeons to deliver a better and faster surgery for the patients more precise and at a microscopic scale. Amazing, can we take a closer look? Yeah, absolutely, follow me. Here we go. So here we have Shamsa who will also help us run in the robot, run in the automatic functions and keeping us safe. Brilliant. And this is our fake eye. So we'll do the surgery here. And this is our robot. Brilliant. Okay, so that's got the 7 degrees of freedom which means it's sort of, I suppose, is that 7 joints that can move in 7 different ways? Exactly, yeah, that's perfect. And in a second we are going to manipulate it and if you like you can help me to do that. I would love to do that Carlo, yeah. What do we do? So, let's go. You can press play. Thank you very much. So now we gently, you can hold the handle. Okay. And we gently drive the robot towards the eye. You've said gently twice, I will be gentle. Yeah. Okay. We don't want our wrist to damage the patient. Yes. So. Especially on the eyeball. Yeah. Because it's not heavy, it's sort of holding its own, unless you're having the weight. Exactly. It's holding its own weight. That's exactly the idea of co-manipulation. Shamsa, could you please stop it please? Thank you. So this is a co-bot, so it's designed to work with humans. Exactly. Brilliant. Thanks to the programming we do, we basically measure how much torque and forces are applied to the robot so that the robot knows how we are interacting with them. Brilliant. And the robot knows where we want to go and it sort of helps us in going there by compensating its own weight. Great. Yeah, right at the eye at the moment. Yeah, exactly. So now in the real surgery, we would be inserting surgical tool. I thought you were going to do that to me? Yeah, you can do it. You can help me. So you can pull this trigger towards the patient. This way? Yeah. Okay. And it slots in. Yeah. And this one will slot in. Right. So now essentially the surgeon would be sitting at the console and looking through the microscope image like an inside man inside the eye and basically driving the surgical tool to perform the injections around the macula rather than other therapies that are required. Brilliant. And so by using this robot and by using the microscope, you can just make tiny, tiny incisions and I suppose tiny surgery onto and which is so important onto the eyeball, right? Right. We can reach the retina. We could potentially even reach behind the eye. We can do basically so many more things that the human hands because of tremors, because of a lot of other inconsistencies that humans have. Absolutely. We're imperfect, right? We're humans. And also like the classic tool is for manual eye surgery is straight. Yeah. While we have the possibility to actually make them curved. I've been touching your computer. Sorry. I hope I'm not. Oh, no, no, that's fine. Don't worry. So I removed the tool. I can show you the tool. But the tools are curved and according to how we control them, we can achieve different positions which allows us the flexibility that the human with the manual tools don't have. That is incredible. Oh, Colin, we are going to have a lot of fun here. Roma, I have definitely got my hands full. I'm going to get to work. But for the meantime, it's back to you. Okay. So let's have a go. Yeah. Thank you Fran. Now here to tell us more about this continuum micro robot. We have Ross Henry. Hi, Ross. Hey, how are you doing? I am good. I hear you've been busy with lots of students downstairs. Yeah, they've been great. So they are very interested in this. That's brilliant. Tell me a little bit about your research and the work you're doing. So what we're doing is it's a collaboration between Kings Moorfields Eye Hospital and UCL and we're trying to treat a number of different blind diseases causing blindness. So one of them is macular degeneration. Basically what this would do if I'm looking at you, I'd be able to see the periphery around me but I wouldn't be able to see you. It's like the second largest cause of blindness in the world. Maybe coming up on first soon. But so there's this innovative treatment. So we small patch that we can just put behind the retina. So the back of your eye. However, the issue is we're looking to go somewhere that's about half the size of human hair. So that's really hard for surgeons to work on. This is inside the eyeball, isn't it? The retina is kind of the back surface of the eyeball, isn't it? Yeah. So it'll be the very backside. Right. So it's super safe. We end up, surgeons do, it's called vitoretinal surgery. Stunned, there's probably like 40 cases a day of different types of it that's happening of this group of surgery that's happening at Moorfields every single day. Probably a lot more. But we're trying to innovate and make it better. And the way we'll do that is so with this wee robot here. And what this is, as you said, it's continuum. So it's essentially these pre-bent tubes which nest inside each other. We can either rotate them or translate them back and forth. Okay. And with that, we can create like this snake-like pattern. So the differences in surgery these days, they just use a straight tool. But with this, it means we can access so many more areas of the eye. Okay. And then depending on like the device we use, we can increase the accuracy or like remove tremors and stuff like that. Right. So basically we're talking about being operated on by a robot. Yeah.  Yeah. But then the idea of a robot doing it. So is it safe? Like what are the things that you're investigating at the moment? So yeah, well like the thing is, as I said, this type of surgery as an inside the eye, super common already. Like it's completely normal. But with this here, we can make it safer than normal surgery. Because what we can do is say if they're, because of course the back of your eye is super sensitive, what we can do is we can remove hand tremors from like, if a surgeon's hand, if they're trying to get to a very specific point. Or even with that we can map it so with like values like a stylus or a pen to control the robot. And what we can do with that is if they move in their space like a centimetre, it only moves a millimetre in the actual eye. So we can amplify their movement. Yeah. So talk to me a little bit about that interaction of the surgeon and the robot. What does that look like? So there's two, maybe three, main ways. The first is like as probably as we saw in the video is a haptic device. So this is... So tell me what haptic means for those who don't know. So haptics for that. This is like the system gives some kind of feedback. So like my phone, you know whenever you get a text or something and it vibrates, that's haptics. So there's like a touch response. Exactly. That's exactly what it is. And with our system what we're looking at is actually there's motors in this device. And firstly it can pick up where we actually are in the eye. It can tell the robot where to move. But if the robot starts moving somewhere which isn't safe and the surgeon's going that direction, we can actually apply a force. And so it kind of stops the surgeon from maybe going to an area that might touch the side of the eye or something like that. It just means that we can minimize the system from straying off to somewhere it's not meant to. Ross, is it using this kind of technique a little bit like almost shrinking down a surgeon and then sending them inside your body to do a bit of surgery on a scale that you couldn't really imagine? That's a cool way of thinking about it. Yeah, I guess it is. So the tool that we end up using, the main one, it's called a forcep. It's basically like a claw. But what we're doing on this here is we're essentially or like a hand almost. We're putting this here and it goes in and we're able to actually like use that really dexterously to like interact with different parts of the eye like at the back of the retina. So say like if someone's got a detached retina, you can, it's like a surgeon going in and holding it and like almost like sewing the retina back on to the eye. That's pretty much what it is. So yeah, a tiny surgeon inside. It's definitely a good way of describing it. Yeah, I mean it's definitely taking us down to a scale I guess that we hadn't really been able to do. Well like if you think about it, the tools we'll work with is about 300 microns. It's a 0.3 millimeters. The area we're looking to go down to is 50 microns. So that's a 20th of a millimeter. It's so small. Like it's really hard to even fathom something that small. And it's the reason why we use these here like the scaling of the haptic device and things. So we are able to actually get there and work with it properly. How did you come into this field and tell us a little bit about like, I don't know your interest as a child and what was your path to getting into this field of science? I had quite a wavy path getting here. I started off, I saw off back home as a florist in Ireland. So it was great. But I came over to King's to study medicine. And when I was a child I either wanted to be an engineer or a doctor. And I didn't realize that I could do both. So I came here for medicine and at GKT I really enjoyed it, like it was amazing teaching. However the study style just didn't suit me. One of my lecturers was a person called Keval Rhodes. He was teaching imaging. And so I got told, chat to him, he does biomedical engineering. My flatmate was one of his students. So I went there. I talked to him and I transferred course over to the Bachelors of Biomed Eng. And with that, yeah, so I was working through my bachelors and my final year project was with Dr. Christos Burglis. And I absolutely loved the work that I was doing with him. I went to him like a couple of months and I was like, look, I love working with you. I love the team and I love the research. And I'm like, I want to stay on, do a PhD or extend my studies. And he was kind enough. He thought my work was good enough. He offered me a PhD. And so since then I've started my PhD. It's currently part-time because the other half of my time I'm working at Moorfields and we're trying to get the robot into a through-the-quality management process, which is a lot. So you're saying about safety. Yes. We have 150 pages just for one part of the risk assessment. Wow. So every single step that we do is like lined up and everything. So we can make it as safe as we can. I mean, I really love the fact that you were able to bring engineering and medicine together. And I think sometimes we forget that we can actually kind of almost practice medicine as an engineer or a scientist. So you're a great role model for that example. Thank you very much. Thank you so much for joining me, Ross.