So good afternoon guys, it's interesting you have now back-to-back Indian speakers and it's that time of the afternoon where you start dosing off a little bit, if the coffee hasn't kicked in yet. Trust me, you don't want to be dreaming with an Indian accent, right? So get your coffee, make sure you wake up, networking is exciting, yeah? I see a few smiles, that's good. So my name is Karthik Prabhakar. I work for a company called Tigera. Tigera is fairly active in the networking community within Kubernetes Networking and specifically we work on plugins like CaliCo. We also are the co-maintenors of Flannel. We are also one of the co-maintenors of CNI which is the networking abstraction in Kubernetes. So today, what I wanted to kind of walk through with you is a little bit of Kubernetes Networking and give you some of the concepts in Kubernetes Networking. But before I do that, I want to give you some of the fundamental design thinking that went into building the foundations of Kubernetes Networking and want to contrast that a little bit with some of the design thinking that went into Neutron back in the early days. Obviously Neutron has obviously evolved over the last three, four years but I want to give you some of that contrast between Kubernetes and Neutron because there are some fundamental differences and that will put into context for you why Kubernetes Networking is the way that it is. And like every Kubernetes presentation, if you don't do a live demo, you're not worth the assault, right? So you've got to do a live demo. Assuming I can get to the network, I'd like to deploy a Kubernetes cluster, multiple nodes with networking, launching applications. I've set myself a target of five minutes to do that. I'm hoping I can do it in two, right? And what that means is I want, for those of you who haven't deployed Kubernetes before, I want you to walk out of the room and maybe you can even do it with me.  Super easy. Lots of deployment tool options. Many of them are extremely easy to use and this is something that everyone can do, literally everyone in this room should be able to do it. Oh, and a little bit of a plug for tomorrow. Today we're just talking about concepts of Kubernetes Networking. Tomorrow we'll actually have a little bit more of an advanced talk talking about how you connect Kubernetes and OpenStack together, whether it's Kubernetes side by side with OpenStack or one in the other. And in fact, I'm joined in that presentation by Canonical and AT&T and AT&T is going to be doing a live demo of how they deploy OpenStack as a containerized application on top of Kubernetes. They actually use Calico for the networking fabric there. So a little bit of how we got here. So going back to the early days of VM networking, when people started thinking about how they connect different virtual machines to each other, especially in multi-ten started deployment scenarios, the easy way to do that back in the day was, hey, if A needs to talk to B, let's this connect A and B into an overlay network. And in the early days of OpenStack with things like Neutron, you try and provide this virtual networking concepts to users and allow users to create their own overlay networks. And then if now B needs to talk to C, guess what you put in a different overlay network. And very soon you have to worry about what happens if these A needs to talk to C, you actually back call it through a virtual router, and then pretty soon the users have to deal with some of the more advanced networking concepts, which very often they don't really care. They just want applications to talk to each other. So eventually it got to a point where you get this complex mess of overlays, and then you have to deal with SDN controllers to kind of force overlays into physical network infrastructure. You have very often with Neutron, the way many people have implemented it today, a mess of bridges, reswitches, policy enforcement points, security enforcement points, virtual routers, back calls. And case in point, this is a picture from OpenStack documentation of what Neutron with OpenVswitch looks like, standard OpenVswitch. For those of you who have this in production, my heart goes out to you. I've spent numerous nights and weekends the last three years, and I think a number of my former colleagues can attest to this year in the audience. When things break, and the things that break could be in servers right next to each other, troubleshooting this complex mess of overlays can be a real pain. The worst, when you add on things like Layer 3, DVR, VRRP, the complexity just goes on. And that said, you don't need to like Calico and other approaches where you can actually simplify the network, but this is not really a product pitch, this is going to be a technology pitch, and I want to get to the Kubernetes side of things. So here we are, we're here to talk about microservices. Microservices in a cloud-native world, right?  It's obviously gotten more complex than this. And when you have these, this large number of micro-instances, microservices collaborating with each other, this traditional model of creating overlays between pairs of instances or groups of instances that need to collaborate with each other does not scale. And interestingly, because microservices are very dynamic, the flows tend to vary, things tend to come up and down fairly dynamically, we really have to look at a new approach because interestingly where the world we're moving to is sort of a serverless function as a service world with things, running functions individually in different parts of the infrastructure. And this concept of building overlays for everything is fundamentally a approach that has its roots in the early days of EM networking, and we have to move past that, right? So that said, Kubernetes, which is focused on how do you run containers at scale, how do you provide an infrastructure for running microservices at scale, took a different set of assumptions. First of all, the world is IP, right? How many of you have an application that does not use IP? So Kubernetes started with the assumption that it's going to assume that every node in the cluster has an IP address. It also made the assumption that POD has an IP address that's unique within the cluster, right? And so when PODs communicate IP addresses, other PODs that they communicate with know that IP address and it's the fact that it's unique. So that's a fundamental assumption and by the way, that is a little bit more evolved from sort of some of the early design thinking that went into Neutron. Kubernetes then adopted CNI, the container network interface as a networking abstraction to allow different vendors to plug in different networking plugins to provide that connectivity between PODs, okay? And today there is numerous plugins each with their own characteristics and different market segments that they go after. So we work with, my company works with Calico and Flannel, which are fairly popular plugins, but there's plenty of other plugins. The big difference that Kubernetes introduces, and in fact other container orchestrators have also adopted a new abstraction, is that it now decouples this concept of using network topology for isolation. What Kubernetes says is I'm using an IP address, it's up to the network plugin to decide how to connect the instances to each other. But I'm now going to give users a new abstraction, a declarative model by which they can declare what PODs need to talk to what other PODs. So users can declare in a YAML syntax using advanced concepts like labels and selectors how they want PODs to communicate with each other, which PODs they want isolated from each other. So that's declared as opposed to enforced in the network using network topology. And what that allows you to do is you can now build networking plugins that keep the network simple. Absolutely, you can build networking plugins that keep the network complex. You can do it, but you don't have to. And this is a fundamental design choice that Kubernetes made. In a Kubernetes environment because an application or microservice is served by dozens of PODs or hundreds of PODs, if you have a web server it could be running as tens of web server instances. You need a concept to abstract away this fleeting dynamic environment and that concept is services. So Kubernetes has the concept of services and we'll talk about how that's implemented in the network. And a service refers to a collection of PODs at the back end. We also have sort of a way of discovering services using a variety of options. You can use DNS, but there's other options you can use and Kubernetes basically presents all of these to you. And in addition to doing services, very often users and microservices want to do higher level sorts of traffic redirection based on layer 5 to 7 decisions, like HTTP headers, like application specific headers and for that purpose Kubernetes introduces the concept of Indress, which is something that confuses it. So let's start with a little bit of a dive into what the networking landscape looks like. We'll start with first simple east-west traffic, POD to POD traffic between PODs and Kubernetes and then we'll go on to the more abstract concepts like services, Indress and so on, right? So to begin with, in Kubernetes Kubernetes cluster as a collection of nodes. Nodes could be bare metal nodes. It could be virtual machines running on OpenStack. It could be instances running on your favorite public cloud. Doesn't matter.  Some nodes are designated as master nodes where you're running the Kubernetes control services. And some nodes are designated worker nodes where you're actually running the PODs or the applications. The main services running on the master nodes are things like the API server, which is how you interact with Kubernetes. You have a scheduler which helps schedule pods. You have things like the controller manager, which runs a number of controllers, things like add-on managers and other controllers that are part of Kubernetes. But when the master needs to actually schedule pods to run on nodes, it talks to an agent called Kubelet, which is running on the individual nodes and the Kubelet is responsible for launching those pods and running them. And so you have this Kubelet agent that's running on every worker node. Within that worker node I've just called out this concept of the host network namespace. That's typically the Linux networking stack as you and I know it. As you all know, it's possible to create multiple namespaces in Linux. And so we'll get to that concept next. So when Kubernetes launches a pod, a pod in Kubernetes is essentially a collection of containers with a shared network namespace. Typically what that means is that collection of containers shares an IP address, it shares a routing table, it shares some basic network concepts. So it has a separate namespace. And when a Kubelet launches a pod which is a collection of containers what it does is it now says I need to network this pod and get it connected to the network. So it can talk to other pods and talk to the rest of the world. The way it does that in Kubernetes is using CNI. And CNI is really simple. What happens is the Kubelet calls out to a CNI configuration file at a very high level. It calls out to a CNI configuration file which is stored under slash XE. And in this case I've used the Calico example, the system example Flannel which I'll talk to, there's other plugins. Each plugin has its own config file for CNI. And the Kubelet basically says hey I'm calling you and I have this pod. I want you to connect this pod to the network. And in effect what happens and I'm using the Calico example here Calico in this case the Calico CNI plugin says okay I need to give this pod IP address and I'm creating a virtual Ethernet that connects the pod namespace to the host namespace. And so that's sort of the first step and then it's really up to the plugin as to how it connects that virtual Ethernet to the rest of the network. Some plugins use bridges, reswitches, create overlays. Some plugins like Calico use simple IP routing.  You can actually use both. And just walking through this one example of what Calico does, Calico basically writes this new workload into the shared XCD namespace that's available for Kubernetes. That CD namespace calls out to another Calico agent called Felix running on the node and what Felix does is inserts routes for that pod's IP addresses into the host routing table. Saying if you need to reach that pod send traffic into this virtual Ethernet. Calico does not use virtual switches. It does not use bridges. It simply sends it to that virtual Ethernet. There's another agent running on the node called bird which is a BGP agent. And so all the Calico nodes within the cluster appeared together using standard BGP. And so what that means is when bird detects these new routes it advertises that route to other nodes in the cluster as an aggregated route. And so within a matter of milliseconds every node in the cluster knows that it's available from through this node. So any traffic just into that pod is sent to that node without any encapsulation, without any overlays. For those of you coming from a neutron obvious world this might be a little bit of a foreign concept but networking is really simple. It really is. I see a few people laughing. Networking should be simple. If you're looking at scale. So that's basically what Calico does. It has a pod so it's fairly non-intrusive in the host stack. And your actual data traffic simply flows with normal Linux routing. In this case Calico is not in the data part. It's simple IP forwarding. No raw magic to it. Flannel is another example. This is one of the early plugins available for Kubernetes. And Flannel has a variety of ways that it can provide the actual networking to give you an example of this. Again, Flannel is called using CNI. So Kubelet calls CNI. In this case it says it gives Flannel some configuration parameters like use minet as a bridge. In this case Flannel actually creates a bridge connecting the virtual Linux. And it tells you how to assign IP addresses. It says use host local. And the way Flannel works is that it assigns a slash 24 for every node in the cluster. And each node assigns IP addresses from that slash 24 to individual pods. From that point on Flannel has a variety of back ends to actually connect the different nodes to each other and to exchange routes. The most commonly used back ends for Flannel are either host gateway or VXLAN. What happens in host gateway is host gateway assumes there's layer 2 adjacency between nodes and in effect it does simple IP routing by sharing a slash 24 routes among all nodes in the cluster through HED. And so it does simple unencapsulated packet forwarding assuming there's layer 2 adjacency but in this case it's not running a dynamic routing protocol. Another common mode of operation for Flannel is VXLAN and this is a standard overlay that many of you are used to. So if you want to use an overlay for whatever reason you can absolutely do so with something like Flannel. And when you use VXLAN obviously you're paying a little bit of performance penalty for doing VXLAN encapsulation depending on your NIC card, depending on how it's implemented that might be raised to offset some of that performance overhead. But again this is a standard VXLAN overlays. So that's a couple of examples of how Calico and Flannel work. There are the network plugins in the market today there's interesting numbers of network plugins but generally what tends to happen is a lot of the plugins that are coming in tend to bring either specific market inputs or they tend to have specific features they tend to claim. I don't want to be in the business of comparing for you which is the best plugin I think you should really make that call for yourself based on individual plugins merits and if you're interested I would certainly encourage you to talk to more folks who are built Kubernetes deployment at scale and I'm sure you in terms of some of the plugin choices. But that's one part of the Kubernetes networking story which is how do you connect pods to each other. Again keep in mind pods are just dynamic instances that can be spun up and down and these are typically fleeting instances in Kubernetes right. And typically the way you would have multiple pods for an application is you would either configure a replica set or replication controller which is the older concept to say I'm running an Nginx application and I want 10 replicas and Kubernetes spins up 10 instances of Nginx each as a pod. The next concept which is the one I referred to as a very powerful concept in Kubernetes is this concept of having namespaces, labels, selectors and network policy which are all instruments to help you declare in YAML syntax typically how you want to isolate different objects from each other. Typically objects refer to pods that could refer to other instances too. And so first of all the concept of namespaces is the capability where you can take a Kubernetes cluster and sort of logically partition it into virtual clusters so that you can isolate different projects from each other. It is not true sort of multi-tenancy there's other elements of RBAC and other features coming into Kubernetes which do not come into Kubernetes but namespace is loosely that concept where you can sort of partition your cluster into virtual namespaces. In addition and Kubernetes you can assign an arbitrary label to any object. You can have as many labels as you want. So you can label a pod as a LDAP server. You can label the same pod as something in production. You can label this pod as a team project A. The other thing you can do is now you can now select using a label selector what you want to match on. So you can say all objects in all pods that have the label LDAP server and all pods that belong to project A. And using this concept of labels and selector is now you can declare in a YAML syntax or the deployer can say I want to allow all LDAP servers labeled project A to talk to all LDAP servers or LDAP clients in project A over port 636. And you can have multiple sort of policies. And what that means is now it's up to the implementation of network policy in Kubernetes to enforce that policy dynamically. So I've given this example here with Calico. The way Calico does that is by taking those policies and on each node independently instantiating whether objects with that pod exist. And if they do then it creates IP tables actually IP sets rules dynamically which is enforced at the virtual ethernet connecting into the pod. So it's enforced at the very endpoint. And similarly at the other end if there's an LDAP client it will similarly create IP sets independently on that end. So it's sort of a decentralized architecture and there are different implementations on network policy. They all behave differently and you should take a look at what your preferred implementation does. But fundamentally that's what they do. And so this concept of network policy is a really powerful concept which allows you to now enforce isolation with policy rather than using a network topology to enforce isolation. And this is something that the OpenStack community, specifically the Neutron community understand as Neutron looks to integrate closer with Kubernetes because this gives you the opportunity to fundamentally simplify networking as you look at combining Neutron with Kubernetes networking. Let's move on to the concept of services which is like I said a service is the ability to now have an abstraction to provide a front end for a collection of pods. And so in this case I've got a couple of pods which I've got this little pink circle here which are supposed to indicate, let's say they're running two instances of an Nginx application. They're both doing the same application they've got the same labels, they're basically two instances of the service. And in Kubernetes you can expose that service either with the YAMU syntax with kubectl or you can run something like kubectl expose and give it this command and that's how you expose the service. And when you do that this is typically what happens in Kubernetes. First of all it launches a little demon called kubeproxy and this kubeproxy demon runs on every node in the cluster. And kubeproxy essentially operates by setting up IP cables rules in the node that map the service into the back end pods. To give you an example of different ways you can implement the service abstraction one of the common ways is what's called the cluster IP. So if you were to say I now want a service for Nginx that's served by 10 different pods in the back end essentially this Nginx service will receive a cluster IP which is a well-known IP within the Kubernetes cluster and kubeproxy's IP tables rules take care of translating doing a dNAT on any traffic that's cluster IP and translating it to the actual pods IP address. So basically it's dNAT that helps you translate from the services cluster IP to the actual pod IP address. And the kubeproxy and the IP tables rules run on every node in the cluster. This takes care of when you have services within the cluster that need to use services so if you have a Redis application that needs to talk to Nginx Redis can say here's my Nginx well-known cluster IP and so that traffic can flow east-west but sometimes you need traffic from outside the cluster to come into the cluster and a way to do that is something called node ports. And what node ports is that Kubernetes in addition to having a cluster IP now assigns a port from a well-known port range typically by default 30,000 to 37,000 and gives a well-known load balancer like service. And now traffic coming to any node in the cluster destined to that port essentially gets translated using dNAT rules and sent to the actual pod IP address. Another way you can do services is using a service of type load balancer. In this case what Kubernetes does is that for certain well-known load balancers like Google's load balancer, Amazon's ELB a handful of other well-known load balancers Kubernetes basically creates the load balancer rules to translate services to pod IPs dynamically. So it's a way to do service mappings from services to that back-end pods. So far so good. So now you've sort of done this mapping of services to pods. The next step is how do you actually find what the services IP addresses are? Sometimes you may want to find the actual pods IP addresses because you might think, okay, I can do better load balancing than have TubeProxy do it for me so sometimes that might be preferred. And there's a variety of ways you can do that. You can use any of the classic service discovery mechanisms in Kubernetes that's perfectly fine. One of the default ones that Kubernetes provides, which you're welcome to use, is called CubeDNS. And today there are different DNS servers that score DNS, the number of implementations that can be plugged in as well. But the way CubeDNS works is that first of all it creates a DNS client resolver mapping within every pod. That says when the pod does a DNS lookup, it gets sent to CubeDNS. So CubeDNS essentially becomes a DNS server resolving client queries. And when a new service is created within a namespace CubeDNS essentially creates a DNS name that maps from the name of the service that creates a domain. So if you have a service named WebServer and in a namespace called ProjectRED it creates a domain called WebServer.ProjectRED. at service.cluster.local within the Kubernetes domain. And so when the client does a lookup for say WebServer, it'll get pointed to the default WebServer in that same namespace. But if the client wants to pick a different namespace, it's absolutely free to do so. Simple DNS and DNS works in the form of pods where the actual DNS implementation runs as a pod within the cluster. Fairly simple. Interest resources, again, it runs as an add-on in Kubernetes, just like DNS. Again, the interest resource essentially allows you to define an arbitrary set of layer 5 through 7 mappings that define what needs to happen when application mapping matching that pattern shows up. So in this case you can define interest controllers that can process that incoming data. And these interest controllers run as pods within your Kubernetes cluster. So I'm showing an nginx example here. You can use nginx as an interest controller. And what happens is when traffic comes into the nginx controller you provide a sort of mapping that says if the HTTP host header says the hostname is foo.bar.com send traffic this way to this pod. If the HTTP header is bar.foo.com send traffic this other way to the other pod. And so you can use this concept of interest controllers to sort of redirect your traffic based on application semantics and you can have sort of arbitrary L7 controllers for depending on what sort of applications you want. Again, a fairly powerful concept but it's sort of a new concept of many folks in the OpenStack community. And this is again an area where there's a lot of innovation happening as well. So I wanted to give you a demo so that's let's get to that. If anyone wants to time me in terms of how long this is going to take I might first need to combine my screens here. Okay, so what I have here is essentially a master node which I've gotten here in this terminal. Just to be safe I will open up a second window on that same master node. I also have a couple of worker nodes and these are instances running in the cloud. Pick your favorite cloud you can so that's node 2. By the way, are you guys in the back able to see this? Okay, someone give me a show of hands. Okay, good. All right, so let's start by working on the master node and actually make sure I have my cube config there as well when I run cube. So let's start here. So I'm using cube admin which is one of the simpler ways to deploy Kubernetes. There's dozens of deployment tools in Kubernetes today. Many of them come with networking by default, something like Flannel or Calico or other plugins. But if you don't, cube admin is a fairly simple way to get started. There's lots of other tools. So I'm using cube admin here because it's simple. So what you would do to start with on the master you would run something called cube idiom init. Let's hope the demo gods are kind to us. And essentially what cube admin init is doing is it's launching all of the key Kubernetes demons on the master and configures them. So if things go well, pretty soon it should come up and say, all right, things are looking good so far. Voila. So it says I'm now ready to have clients or worker nodes join the cluster. Before we get to that, let's do one thing. Let's start cube cuddle, which is how you sort of look at what's happening in the cluster. In fact, let's do a watch. Can't seem to type today. I am not able to type today. All right, there we go. All right, and so let me make the smaller. All right, so it's telling you what's currently running and basically you've got a bunch of processes running. These all running in the cube system namespace which is sort of the master namespace for all of the Kubernetes specific stuff run. Now, before we do anything else, we'll also have to do this. We'll have to connect some sort of networking because without networking, Kubernetes doesn't start really worth very much as it. And I'm installing Calico. Calico is encapsulated so you actually launch Calico by running it as a pod, a daemon set on top of Kubernetes. So that means this Calico daemon, this Calico pod gets launched on every node in the cluster. And so when I do this, you'll see the Calico node pods get launched. And if you look at the watch, you see the Calico XED, you can see the Calico node launch. And pretty soon, I think pretty much most of the pods that are pending will go into a running state. There are no schedulable nodes. So now that that is done, you have networking going. What we'll do is we'll run this command on the worker nodes. And let's start by doing it on worker 1. And when I do that, you'll see additional Calico node processes launch in here. And in fact, we can also do it from here. So we can launch both workers at the same time. And hopefully, if things go well, and pretty soon you'll see a third one as well, it tells you that these are running in the host namespace. And so, guess what? Suddenly you have Calico nodes being created, and now everything in the cluster is running. Was anyone timing me? Was that two minutes, five minutes? You have your Kubernetes cluster up with networking. So next step, let's launch some applications on it. And to give you an idea how you do that, let's go back to the master. And let's do everyone's favorite application, nginx. Actually, before we do that, let's create a namespace. Let's call it policy. And let's try and I cannot type today for some reason. How many replicas do we want? Let's say 10. And so now you see this nginx pods being spun up in the IP address through Calico. And voila, we are up and running. So now if you want to look at what the actual network infrastructure looks like, let's go to the worker node. And let's do an IP address show. And you see all of these interfaces, Cali, whatever, those essentially are interfaces virtually the net's connecting to the individual pods. Each of them have an IP address. And each of them connect to the nginx pods. If you do an IP show, there are your routes. So for all the pods running on that particular node, here are the slash 32 routes pointing to the virtual Ethernet. For the route, for the nginx pods running on a different node, here is the routes that have been advertised by BGP with an aggregated slash 26 route. So for any reason your connectivity fails, guess what? You just look at your routing table as if not go trouble should start at BGP. If the route exists but you don't have connectivity, you would do things like look at the IP tables to see if there's any policy that's preventing traffic from being stopped. But networking in Kubernetes, that's all it is. You have really powerful networking. This networking scales to, the current scale targets for Kubernetes are up to 5,000 nodes. It used to be 1,000 nodes, 100,000 containers. Now it's 5,000 nodes. I believe 5 million containers. I forget what the number of containers was. But it works. It's simple. Right? And that's sort of an illustration of why Kubernetes networking is, the way it was designed is designed to keep things simple and yet scalable. And I want to sort of leave you with a little bit more on what's coming tomorrow, which is a bit more of the advanced concepts. Right? And so tomorrow at the session where I'm joined by Canonical and AT&T, we'll talk to you through a little bit more of the use cases around how you want to combine Kubernetes and OpenStack together. And there are sort of three scenarios for that. Scenario one is where you're running Kubernetes on bare metal and you have clusters of Kubernetes and you have OpenStack also running on bare metal. But you have applications that need to talk to each other. You might have an LDAP server on one and LDAP clients on the other. Right? And there's a lot to do that. There's different approaches. The Calico approach is to do simple networking, BGP peering essentially, and using labels and policy to define what can talk to what. The second sort of scenario is when you're running OpenStack on bare metal and you have individual virtual machines running Kubernetes nodes. So Kubernetes is in effect running inside of OpenStack. And again, in the case of Calico, which we'll talk about more, it's simple BGP peering, simple networking, and you use policy. And the third scenario is actually a really interesting scenario, which you're seeing more and more in the industry now, which is Kubernetes is running on bare metal, takes care of things like the auto scaling, the provisioning, the upgrades, the life cycle management, and OpenStack is running as a containerized application on top of Kubernetes. In this case, what the benefit is that the OpenStack control plane is containerized, and so as you need more capacity in auto scale, also Kubernetes can take care of things like upgrades, rolling upgrades, as you need to move from OpenStack version to version. And this is sort of the use, this is the demonstration that AT&T's been showing, which is using OpenStack help as the OpenStack project to do this, and they actually use Calico for the networking fabric. But what they do, what they're actually showing is being able to do a deployment of OpenStack as a containerized application of Kubernetes, and then upgrade it, and being able to do that within the matter of a few minutes, which is a really powerful concept. And the inner CalicoBGP peers without a CalicoBGP and a simple IP routing. And you use policy to isolate between applications. So that's something we'll talk about tomorrow. So sort of to wrap up the session here and to take any questions, the things I want to sort of emphasize is that when you start looking at Neutron and Kubernetes, these are different abstractions, but they do have sort of different targets that they did have different targets in mind when they were designed. Neutron was sort of designed for virtual machine scale. And so it can handle 5, 10 VMs a second, depending on how complex your Neutron environment is. Kubernetes is designed for container scale. It's designed about launching hundreds, potentially thousands of pods a second. And so it's a different sort of scale target. So when you start connecting Neutron and Kubernetes, you have to give a little bit of thought to what you're connecting. Are you sort of overloading the complexity of one into the other when you're connecting them? And you really want to give some design thought into that before you do anything. So that's one sort of key highlight I want to point out. The second thing is that Kubernetes abstractions are different from Neutron's networking abstractions. And that's intentionally so because Kubernetes is focused in this world of microservices that we live in, which is a much more rapidly changing world than the world that OpenStack and Neutron were originally designed for, which was virtual machine networking. So the abstractions are quite different. Certainly Neutron is slowly evolved, but I think as it's evolved it's also a little bit of complexity. And there needs to be some focus, especially for people deploying and operating networking at scale to focus on the operations part of it. Because there's key elements from an operational scale perspective. And finally this is a key concept in Kubernetes networking, which is it gives you the option of keeping networking simple and using policy isolation. And I follow that principle, it gives you the option. Now, absolutely you can implement your networking in any fashion that works for you. But it also gives you the ability to keep your networking configuration simple and actually use a declarative model like network policy to provide the isolation, which is a really powerful concept. And this is a concept that's sort of been embraced by all of the other major content orchestrators. They're all moving in this direction that you haven't already. And so this is really an opportunity, it's an inflection point for us to all think about how we've deployed networking in the past in the early days of cloud networking. And to sort of rethink what we can do moving forward. How we can fundamentally simplify and focus on scaling networking to much bigger infrastructures. So that said, if there are any questions, I'm happy to take some questions now. I'm not sure how much time I have. Looks like I have about five minutes here. Yeah. Question. Do all the containers in the pod share the same network name space? No. So a pod is a collection of containers and essentially the containers within a pod share a network name space. Only the network name space, but processes file name spaces are separated. Again, generally that's a name space that's created by a tubelet. I couldn't speak to all of the different name spaces, but at least as far as network name space, which I'm pretty familiar with, that's what happens. And the way into how it's created, there's something called the pause container that gets launched. And the only job of a pause container is to keep that name space alive. So it's a very simple way to get a name space going. If you look at what's running on a node, there's something called a PAUSE pause. And all that's doing is creating a network name space. Thank you. You're welcome. At the time you're doing the kubectl apply calico.yml, is there some baseline network already running or is it just the management plane that is used for all operations? Just the management plane, obviously all the nodes are also connected, but at this point the master doesn't know about any of the nodes. All you're doing when you do a kubectl apply calico.yml is you're creating a demon set that says any time a new node comes up, launch the calico pod on that node. So it essentially preps your Kubernetes cluster for networking. And so the first time a worker node joins the cluster, the calico node launches on that cluster node and you have networking automatically. Okay. I saw that you mentioned something about solutions with Kubernetes like calico, flannel, etc. There's numerous, I mean there's Contrail, there's Contif, there's dozens of plugins out there. So I have a similar question regarding the network policies. Say for example in an enterprise data center people are moving from IP tables to more advanced or modern policy engines like Illumio. So does Kubernetes have plugins for policy engines as well as of right now? Yeah, good question. So today policy is enforced at typically the inverse point or the egress point of the which we are looking at into the pods. And it's really a function of the network plugin to implement policy. So calico has sort of a policy engine that was the team behind calico helped develop network policy of Kubernetes. So it's sort of Kubernetes policies are subset of calico. That said, there are different policy implementations. Some of them are closed source, some of them are sort of learning approaches. So for example, you look at things like Illumio, they tend to be learning approaches, some of them are closed source, some of them are open source. It's really a function of the network plugin. The thing I will point out is in the world of microservices, especially towards things like functions as a service and server less. The model where you try and learn something in the network doesn't necessarily scale because things are too transient. And so most of the container orchestrators tend to have this model of declarative syntax where you actually declare what you want the application to do and then enforce that policy. So things like calico sort of follow that model. Thank you. Hello. My question is about the ingress filtering. You showed an example where we're filtering on host, which is a source host, which is a really common case. How flexible is this part of the stack? Can it filter on some other aspect of the packet? So let me distinguish between policy and interest. So interest, when I show you the engine X example there, engine X is the interest controller and you have the interest resource defined that calls out, hey, for this mapping you need to do this. That function, so that's sort of the concept of interest. Now, network policy is sort of a distinct concept from interest and in network policy today Kubernetes supports just interest filtering. So what that means is that there is no interest filtering to the world. You cannot express in Kubernetes today how to protect the rest of the world from the pod. So there is no ingress filtering yet in Kubernetes. If you look at specific network policy implementations like calico, for example calico does have ingress filtering. It also has more operational focused policy. But Kubernetes itself is sort of a developer focused platform. And so the community decided that ingress filtering first. So ingress filtering has been deferred for later. It's possible it might come. There's been discussions within the Kubernetes sign network community, but potentially looking at ingress filtering as well. Good question, by the way. Great. Thank you so much for your questions. I know the next discussion is going to be interesting as well, which is going to be talking about kind of combining Kubernetes and OpenStack and four and a half dozen ways you can do that. Some simple, but also many of them tend to be very complex. And I'd also give a plug for joining the session tomorrow that I'll be doing jointly with Canonical and AT&T, which is sort of talking about the same concept, but purely from a networking perspective. Thank you so much. Cheers.


Hi everyone, I'm Joe for JaspysCaseBrace.com doing a quick little R&B Random Number Block Randomizer for the following teams here. For Flawless, pick your team 22. The break itself will be in a separate video, this is just the randomizer for this. So if you're not familiar with it, the instructions are right there. You get a block of numbers, a random block of numbers. If you get three, then you'll get anything that's three out of whatever, thirteen out of whatever, twenty three, thirty three, forty three, fifty three, sixty three, seventy three, eighty three, ninety three, two ninety three, out of whatever. There won't be a cards number to two ninety nine in Flawless, but you get the idea. Big thanks to this group right here for getting in. Paul, Robert and Matthew, they're familiar with the number of blocks, they get it. And they're the numbers right there. Thank you. Let's do it. Let's roll it. Let's randomize names and numbers four and a two, six times each. One, two, three, four, five and six. After six times we got Matthew down to Matthew. And after six times the numbers, one, two, three, four, five and six in final time. Now remember, in other breaks, zero gets any and all redemptions, but there are no redemptions in Flawless, no traditional redemptions in Flawless. There are blockchain redemptions though. So for the purpose of this break, zero, Robert, will get any of those blockchain redemption cards for those, for that group of teams, that group of teams right there on the bottom tab. Matthew with six and three, Robert again with zero, Paul with four, Matthew with seven, Robert with two, Matthew with nine, Paul with one, Robert with five and Matthew with eight. Let's sort by column B. In a separate video will be the break itself, Jasper'scasebreaks.com. Bye-bye.


Hello everyone, my name is Mena Rimbakis. I'm an STM32 product marketing engineer, and I'm here to talk to you about our one of our latest devices, the STM32 MP135. We have one of our Discovery kits here, and it's running AWS's IoT fleet-wise software package. And what we're doing here is using a laptop to collect canned data that we're pumping into a gateway that is then going up into a dashboard. On our device, we're running Linux and we're doing the modeling, connecting, selecting and collecting of information through the fleet-wise software package, and then we authenticate up into the cloud, and we're running up on a dashboard connected globally. So that's available anywhere. The laptop truly is just a vehicle simulator to get us the canned information online. And you can imagine this being any sort of industrial gateway, a fleet gateway, any kind of data aggregator, and that'll connect to the cloud and give you your intelligent dashboards to make your business decisions. And we enable that with our low-cost STM32 MP135. So hopefully we can help you fulfill all your low-cost MPU needs. Thanks.


Welcome to Stan Energyman here on Think Tech Hawaii and Stan Osterman from Tiger Shark LLC. Yeah, I got a new company, Tiger Shark LLC. So I haven't got a website yet, but we're working. I'm not also planning to take a whole lot of money, so it may take a while. Anyways, we get started on today's show. What I'd like to do first of all is talk about some interesting things that have happened over the last couple of weeks that I think would be of interest to folks that, especially folks that track hydrogen. The first is that if you remember back to around 2008 hydrogen was actually a really big deal in California. Governor Schwarzenegger was doing the hydrogen highway and the Bush administration was pushing hydrogen as an alternative fuel and things were going great guns and all of a sudden at the at the Obama administration change, they put a PhD named Dr. Chiu in charge of the Department of Energy. And for whatever reason, he decided that hydrogen wasn't ready for prime time and he pretty much he funded the hydrogen programs that were going on in the Department of Energy. And it put the skids to a lot of states moving into hydrogen. Well, California kept it going in spite of the lack of federal funding. The state government put in a bunch of funding and of course right now California has about six or seven thousand hydrogen fuel cell cars on the road. And it's still pushing forward to make new stations, but it's all basically being subsidized by the state. Well, believe it or not, the federal government is kind of leaning back into hydrogen a little bit with the Trump administration, even though everybody thinks he's not very environmentally savvy and he keeps talking coal and stuff. But he's actually putting money where it belongs and they're starting to look at more hydrogen and things are happening. In fact, Dr. Chiu came back and said, gee, now that you can get curtailed power for two to four cents a kilowatt hour, maybe hydrogen makes sense. So all the people who slammed the brakes on in 2008 are starting to accelerate out now and really start thinking about hydrogen. Especially the people who were studying it heavily and actually were really sold on it back in 2008. They've just, they never stopped and now they're accelerating out. So to that point, there's a company in Germany, I just found out from a friend Keith Malone in California, from the California fuel cell partnership, that there's a company in Germany that's building a steel plant that will run on wind turbines that make hydrogen to power the steel plant, including firing their furnaces. Because they're finding that hydrogen is the cleanest gas they can get to fire these furnaces and they can do it economically with renewable wind power and hydrogen. And it's amazing. It's happening all over the world. There's a lot going on in Asia, there's a lot going on in Europe, especially Germany, where hydrogen is taking center stage and the price of hydrogen is dropping as they find that the more renewables you put online, the more curtailed power you have because of the need for a lot of renewable energy that's intermittent and all of a sudden there's cheap power available to make hydrogen, store the energy in hydrogen, bring it back later at night when the sun's not shining and use it in stationary fuel cells. A lot's been going on and if you haven't kept your finger on the pulse of hydrogen, it's time to start looking at it, especially you engineers. I have this discussion time after time that most of our engineers are wedded to batteries and they're wedded to diesel generators. Diesel generators are just going to be way too expensive with the gear for generators that you have to use to be clean. They're not going to get any more efficient. In fact, cleaning them up is all aftermarket stuff and it takes away from the power that you're putting in, you're getting out of the generator. So engineers wake up, start smelling the hydrogen roses and start thinking hydrogen and fuel cells for your work. Today's guest is Chris McQuinney, not a stranger to stand the energy man. He's on often and I asked him to come back on because he's working on a project we'll talk about in the second half of the show, but in the first part of the show he was at a conference with myself, Paul Pontiou and a bunch of other smart folks that were talking ocean thermal and renewable energy in Kona as part of the Okinawa, Hawaii Clean Energy Symposium. Chris, welcome to the show. I'm glad you could be on and why don't you tell the audience just a little, a quick synopsis if they haven't seen you before about what you do and and your company. Thanks Dan for having me, yes. My name is Chris McQuinney, I'm in Dayton, Ohio. I'm CEO of a company called Millennium Marine Energy and we build hydrogen fueling infrastructure and deploy it across the country and we have 16 models that are have what's called a certificate of attestation from CSA group, meaning that they meet all the codes and standards necessary in order to put those products out and do it safely and within the codes and standards and we've been in business for about since 2003. I actually started it at our garage at my house and then 2013 we bought a 40,000 square foot building and we've been working out of there ever since and so we have quite a few projects going on and one of them is the Transcontinental Hydrogen Highway. Right, we're at that symposium last week. Is there anything that stood out in your mind that you think is in the category of game changer that came up during that conference? Well, I think it was interesting to hear people talking about how they really needed to store large-scale energy and that you know it's not just batteries and it's not just hydrogen, it really has to be both working together in order to accomplish that and the batteries give you a quick on and off and the ability to follow loads and ramp up and down and then the hydrogen gives you the long-term storage that you need and so it was good to hear people talking about those kind of things and I think that was really probably the biggest thing. Yeah, I agree and you know Paul made the comment to your point that if you start looking at lithium cobalt technology which is basically your tesla wall and that kind of battery, the cost is around 600 dollars per kilowatt hour of storage but when you look at hydrogen scaling the large scale it's closer to 100 dollars or less per kilowatt hour so six times cheaper than batteries and as you mentioned the right thing to do is to put the right mix in. In fact, I would even add flywheels or ultra capacitors to the equation for batteries and say you could probably use ultra capacitors and or flywheels to do that quick if there's a big inrush power requirement to take up that load instantly within milliseconds and get the power up and then let your other generation catch up including fuel cells and and I think that's the way to do it and you know your company I put out there on the introduction to the show that your company has a little different philosophy on how to attack the infrastructure issue with hydrogen generation and of course you need a lot of the hydrogen made in california for the vehicles is steam reform methane and and if you did that from renewable biogas or something like that that's that's probably a good way to negate the methane greenhouse gas but to really make a clean hydrogen it's electrolysis and that's where our equipment comes in but your philosophy is to start small and grow it as the market grows and the other companies and most of the big electrolyzer companies they want to go in big and make these big hydrogen stations that cost millions of dollars and the market's not there yet and then that's a challenge for investors that's a challenge for permitting so explain to everyone how important your technology is number one to scale and number two the fact that it's an appliance not a it's not like you have to build a facility for it it's on a pallet you just drop it in place soak up water and electricity and you're often running kind of like a refrigerator more than a big big building yeah right well it's uh first it's really important to um to to make anything spread across the nation or across the world uh you have to have your finances in order and um if you don't have a product that doesn't always need to have some type of government subsidy to make it fly um you know it's difficult to continue to grow um you know a business that way and depend on the government so we we we think that when you take a product like a hydrogen generator and you combine it with the the five things that you need in infrastructure development are hydrogen production hydrogen purification hydrogen um uh compression storing the hydrogen and dispensing it and we package all that together in one product and by doing it on a smaller scale you can better match the demand for the hydrogen um with the supply and and instead of the way things are going in california often they have um they have to put out a big station because that's the way the government rules work as far as who gets the the grants and um so they have to put out a large station to qualify for that and then you've just put out a new station and there may not be enough cars around to to to consume all the hydrogen that they can dispense so then they can't sell enough hydrogen to make money so if you can match the supply and the demand more closely you can sell all the hydrogen you can make and then with the right um cost for energy input for kilowatt hour electricity you can actually make a financial case that you can put out infrastructure that will make it profitable and so then people want to buy stations because they can make money selling hydrogen and then with the right cost per kilowatt hour you can actually get the hydrogen in certain states like california and hawaii and in certain countries like europe where the price of the hydrogen is actually less than the um cost of gasoline so now instead of just saying hey it's green and it's sustainable and it's renewable and you know selling to that market you can sell to be able to affect somebody economically um by saving money on fuel costs and and then ultimately those two things have to be done within where they can make money and now you can grow an organization organically rather than having to always raise capital or borrow money or get grants and those kind of things so that's the primary reason to start small and grow it big and and then we've taken the extra step to we're the first company in the world to have the csa groups attestation where we have a certificate that you know says that we meet all the codes and standards and that we can fill the car safely um and in doing that process we got it classified as an appliance and because um just in the united states alone on the mainland there's like 3,800 counties and could you imagine what it would be like to go to every authority with jurisdiction and try to explain to them how hydrogen works you know this kind of helps skip over that process when they see you hand them a certificate that says this has already been checked by an internationally recognized third party testing laboratory and uh it's qualified as an appliance so it can just be dropped off and plugged in and used um so um that will I think help in um uh the deployment of hydrogen fueling infrastructure in this manner so then and after that you start small we already we have four products that are already certified that one's bigger than the next and bigger to the next and bigger the next so you can actually move these things around very easily because they're an appliance um and you can take the one that got you started and found a hot location and move it to find another hot location while you put in a bigger system in its place so all together collectively that's our philosophy we've went out and done this this is not something we're talking about doing we're done with it you can look at our website at mreh2.com and see see all the different products that we've got done yeah and and I'd like to let the audience know that um that uh I when I worked at HK we were one of your first customers I think we have serial number two of your of your was a 200 um series electrolyzers and stations and you know we're going to take a quick break here but when we come back I want to talk a little bit about price because I know our station when we when we got it was just over a hundred thousand dollars it was around a hundred twenty thousand dollars for the basic station and I ordered extra storage so that we'd have a little more flexibility on the storage so let's uh we're going to take a quick break and we'll be back after the break and we'll we'll talk about how affordable this is compared to the station the other stations that are out there now. Hi I'm Rusty Komori host of Beyond the Lines on Think Tech Hawaii my show is based on my book also titled Beyond the Lines and it's about creating a superior culture of excellence leadership and finding greatness I interview guests who are successful in business sports and life which is sure to inspire you in finding your greatness join me every Monday as we go Beyond the Lines at 11 a.m. Aloha. Aloha I'm Dave Stevens host of the Cyber Underground this is where we discuss everything that relates to computers that's just kind of scare you out of your mind so come join us every week here on thinktech Hawaii dot com 1 p.m. on Friday afternoons and then you can go see all our episodes on YouTube just look up the cyber underground on YouTube all our shows will show up and please follow us we're always giving you current relevant information to protect you keeping you safe. Aloha. Hey welcome back to stand the energy man here on Think Tech Hawaii Stan Osserman and Chris McWinnie talking about Chris's millennium reign um electrolyzer systems that uh not only make hydrogen cleanly by taking power electric power and water and splitting the water they also scrub the hydrogen and make sure it's all the oxygen and any moisture is separated out of it compresses the hydrogen which is five nine's pure by the time it gets to the storage stores the hydrogen and then use a standard dispensing equipment that'll that'll fit any um any uh Toyota or Honda or Hyundai hydrogen vehicle that are currently in production and you can dispense right into the vehicle from this station so uh Chris you know we talked about how important it is to uh to have the hydrogen scalable so to meet the market but the price on yours is also a big deal and if we can use that curtailed power from renewable energy where it's being made out in the community um we have a real a real chance to make a huge difference because if we can get that electricity here in Hawaii down under 10 cents a kilowatt hour we're starting to be competitive with gasoline and certainly if we can get it down in the four or five cents a kilowatt hour like uh you count on the mainland in many places you're actually beating the current price of gasoline so you know let's talk a little bit about that and maybe what your plan is for the continental us yeah so um the price of the product uh we range we have a model 100 a model 200 and a model 300 and then we have what we call a mega four ta 70 and the prices range from between um 120 thousand dollars up to uh 500 thousand dollars depending on the amount of volume that they produce so the lowest one does four kilograms a day and has eight kilograms of storage and the biggest one has 60 kilograms of storage and produces 64 kilograms a day and um uh so uh we've got quite a range there and and because of the the the the capital cost being reduced that greatly affects the um the the cost to the hydrogen at the nozzle that then can be marked up for profit and sold onto the customer at a discount to what they're buying gasoline so um those those are some big uh competitive advantages that we have when it comes to how this all lays out is making it cost effective so and some of the models that you showed us last week you showed paul and i um even at the small scale in there's actually a return on investment around the two percent range not really big and you're selling hydrogen probably a little bit more than gasoline price but that again that's that's when you have a really small demand signal for the hydrogen but as you get up a little higher to maybe four or five cars a day you know we move up to your second or third tier of uh generation now you're you're getting into four percent nine percent return on investment and you're selling your hydrogen cheaper than is in california and you're still making you know good good profit so it's it's your model me looks like it makes a whole huge amount of sense because as soon as you can get you know a reasonable number of customers you're already in a at a place where you're competitive with the current prices of uh of gasoline and you know right now with fracking and uh you know to get most of our domestic oil um those wells don't produce as long as our traditional wells and i think people are just going to start noticing the price of oil creeping up slowly um as we basically lose our supply and what we don't want to do is cut our supply down to where oil is really expensive domestically and then become dependent on foreign oil again and we're back in the same energy security debacle that we've been in for years where we're fighting wars and we're doing all kind of stuff to keep our oil supply going right right so one of the things that dawned on me there when you were talking is is that um one of the reasons that we're able to do what we do and others are not is because we're taking also a different approach in strategy as far as delivering the gas to the vehicle um the stations in around the world that are being deployed right now are all at 10 000 psi and they want to fill the cars in five minutes and in order to do that you have to pre-chill the hydrogen uh down to minus 20 minus 30 or minus 40 Celsius and that takes a lot of extra energy it makes the cost of hydrogen more because the equipment costs more and um it's three times more to put a 10 000 psi station together than it is a 5000 psi station because all the parts for compression and the fittings and the tubing and the tanks storage tanks all those components are not widely available at 10 000 psi so you pay a premium for them and so we we our approach is at 5000 psi so your car is only going to get a half a fill and you're going to go half as far you're going to have to fill up twice as much um but we think the consumer will do that because some is better than none and the way they're currently doing it it will not self propagate it we want to be able to grow organically um uh and and have the growth occur naturally because the demand is there and and it's affordable um if the government decides they're funded out of money um the current the current uh way that is being done is not going to last so um so there is a sacrifice for doing it our way and it's important that people understand that and we think it's worth it i wouldn't call it a sacrifice so much as you know i think as a habit um i can tell you for certain that as a national guardsman uh i never let my tank go below a half on my truck or my car um because here in hawaii we could have an earthquake on the big island that could cause a tsunami that would impact our island and we'd have 20 minutes to react to it you don't have time to go fill up uh you know 800 000 cars at gas stations in 20 minutes because after that you you'll have a shortage of electricity and gasoline on the island so i always keep my tank half full uh or more and you know that's that's where i fill up but you know you you you could do the same thing here and say look i'm gonna i'm gonna fill up and always have a have a half a tank in there and and stop more often you know i i live on the windward side of the island and it takes me i never buy gas in my neighborhood the closest gas station that i get gas from is uh the Costco here in Honolulu but i do it because it saves me money and it's 30 miles away for 15 miles away from my house so 30 miles round trip and um it's not a problem when i'm in town i fill up the day i filled up with some hydro or some gasoline and uh i could do the same thing with hydrogen and you know and you get 150 mile range on an island here in Hawaii that's that's plenty of range and it's equal to even the smaller uh battery plug-in vehicles that they're uh you know accused of having range anxiety it's it's more than they they get no batteries and um uh with the exception of the tesla um you're you're you're you're getting an eight minute fill and you're going 150 to 170 miles so um it's still much better than any of that i just wanted to be clear that there is a reason that we're that much cheaper um and and people have to buy into that argument but i think they are you mentioned the transcontinental hydrogen highway um we're going to be deploying 27 stations from los angeles california to new york city and um we're going to be the first company um uh that we know of that will be able to claim that they have crossed a continent and allowed you to drive on from one ocean to another ocean and i think that's going to be a really important feature or you know accomplishment to wake up the world to see that it doesn't have to cost as much as what it's being you know touted and so in preparation for that we have just completed the very first um triangular highway we call it the ohio hydrogen triangle um from columbus ohio to date in ohio and down to portsmouth ohio one leg is 122 miles another one's 90 miles and another one is 75 miles and we have stations in all three locations and we have five vehicles that we're able to drive in between them and so i've been driving a hydrogen car now for about uh about three or four weeks and um it's pretty cool to be able to see that you know this thing that we're going to do across the country is working here locally in the state of ohio and and and it really is giving me a lot of confidence that we're on the right track so we're going to take advantage of this uh of this small group together and really collect a lot of data and and really understand um what's the best way to fill the cars do we need to spend just a little bit of extra money and put a cascade system in them it only gives you about a 10 more but you know 10 of 150 you know the 15 miles so that might be important to somebody and so you know those kind of questions we're going to be able to answer and we're really excited about how do you do that yeah and and just so everybody knows too you you are you do have the technology built already to go to the full fill um when you get to like the megawatt scale electrolyzers and you know and at that point though you'll be able to um to do the 10 000 psi pressure and be able to afford the stations because you're already at that market where you have the customers to support that biggest station and make it cost effective so that's important important for everybody to understand it is we're not saying we don't want to do 10 000 we're just saying there's a right time and right place for it in a way we look at it is you get enough customers coming in and all sudden you change your station to do 10 000 you're selling twice as much gas to the same people so that's a totally different value proposition because you already know the market exists and you know there's so you automatically know what your numbers are going to be it's not a question of if but it's a question of when so when do you actually deploy the 10 000 puzzle and we already have that built so we'll see what happens when you get a financial advisor and a financial planner that starts doing innovative innovative hydrogen infrastructure it starts to make business sense well chris i want to thank you for being on the show today believe it or not we blasted through 30 minutes and want to thank you for bringing us up to speed on on your vision and i think it's a valid thing and i hope that you can get your your business plan out there for other investors to look at so they can understand how much sense it makes because we've we've shown it to other people and they shake their head up and down and go hey this makes a lot of sense so thanks for being with us and i'll have you back on in a few months and get caught up a little bit more on how millennium reigns doing yeah as you know we're looking for investors right now to help support this and so uh i appreciate you saying something about that all right okay well until next tuesday stand there there's your man signing off aloha


Hi, I'm Aaron Parecki from Octet and I would like to invite you to Dev Day 23, a free two-day virtual first event happening on May 16th and 17th. We have a lot of great talks lined up from identity and security experts. Day two will be broadcast live from our San Francisco office and it's all about helping you get your apps ready to sell to enterprise customers. You will learn how enterprise companies expect to be able to use and integrate with your apps and my talk Enterprise Readiness Beyond MVP will show you the features you can add to your apps to make them loved by enterprise companies and stand out from your competitors. You can register right now at developerday.com and I hope to see you there.


Welcome everyone to this CUBE Conversation featuring Momento. I'm your host, Lisa Martin, and today I'm very excited to be joined by Daniela Miao, the CTO and co-founder of Momento. Daniela, it's great to have you. Thanks for joining me today. Hi, Lisa. Thank you so much for having me. Super excited for our conversation today. Yeah, me too. It's our pleasure. Tell the audience a little bit about Momento products, services, mission, give us that context. Well, at Momento, we have built the very first truly serverless cache. We are here to help developer work much faster and not have to worry about the painful infrastructure management of traditional caching. Awesome. Then we're going to break that down during this conversation. One of the things that is hot, hot, hot right now is generative AI. Everyone's talking about it. I think even my mom was talking about it the other day. I'm not even kidding. What it's going to do for the world, pros, cons, but in your opinion, what's the broader theme here? Well, I think generative AI is exciting as new as that term is. What it represents has really been around for a long time, and it just represents innovation and the pace of innovation, and how it's faster than it's ever been before. Customers and end-users, folks like my mom and your mom, they're expecting things to happen faster and faster. They're expecting applications to be even more interactive and give them instant gratification, a moment that they have a need for information or for something. As a result, the platforms around us is expected to innovate faster than ever before, and with that theme coupled with a number of startups that's popping up in the space, just means that daily lives, our lives are going to be transformed, and this creates a virtuous circle of customers expecting more, and as a result, developers have to innovate faster and come up with even more productive ways to get their work done. Absolutely. The one thing I think nobody's going to be resetting is their expectations on how quickly we can conduct any transaction in our personal life and our business life. We just want things to work and we want them to know enough about us without being creepy to really deliver that personalized experience. Daniela, one of the things I noticed on the website, the gomomento.com website was believe in serverless. As I was joking with you before we went live, it reminds me a little bit of Ted Lasso, the believe sign which I love, but talk to me about why you believe in serverless and what was the catalyst to launch the company in 2021? Well, the initial idea really came from my co-founder, Kwaja, who's the CEO and my own experiences working in the world of databases for over a decade. Serverless does not mean you're not working with servers. Serverless just means that we, as the database and infrastructure experts, we take on the painful infrastructure management on behalf of our end users and our customers, and we abstract away the complexity so that they have more time and energy to focus on what really differentiates their product and it allows them to innovate faster than their competitors perhaps. So to us, serverless really is just a way to accelerate development, reduce cost, reduce complexity, and simplify our end users architecture. So the believe in serverless, I really love Ted Lasso as well. It's really about a state of mind, which is the same as in the show, is that we believe that we should be able to take on the painful and the really, a lot of the time, very time consuming, and there's different tuning and benchmarking that you have to do very, very low down at the database and caching level. And we believe that we can do all of that on behalf of our customers, so really they're just focused on their business, their product and their features, and something like incorporating generative AI into their product, which everybody is doing nowadays apparently. Yes they are. One of the things I heard you say in our very beginning, Daniela was true serverless. You talked about serverless, what's true serverless and how does Momento deliver that? So we at Momento actually follow a very strict litmus test for what true serverless means. There's a few things, like it's instant start, there's no waiting for servers to come up because of course in the world of true serverless there are no servers. But we handle that really behind the scenes, like I said, it scales to zero, when you're not using it you should not be paying for it. A lot of the painful aspects of traditional infrastructure management comes down to the fact that you often over provision for your highest traffic peak or this big event that's happening on your website and you sort of have to have enough servers to serve that big peak and then you're too afraid to take it away for the next time that that happens. So it has to be able to scale to zero when you're not using it or when the traffic on a particular application is not very high. There's other things like there are no maintenance windows. Yes, software and hardware has to be upgraded and maintained all the time but that should be completely invisible and not felt by the end user. So that's something that we also manage on behalf of our customers. Now of course this concept of simplicity, low cost and increased productivity is very, very attractive for a lot of businesses. So serverless has become a bit of a term that gets attached to a lot of marketing. So in cases where services are not naturally serverless they do get slapped on with that label of serverless as well and this is sort of not specific to any company, specific companies but it's broadly applicable to a lot of startups and even big cloud vendors are doing this as well. So that's why at Momento we put a lot of effort into evaluating and also sort of helping to promote the idea of true serverless with the limits test that we have. Got it, thanks for clarifying that. You mentioned scale I saw on the Momento website that the mission of the company is to remove the need to manage caching by providing a service that works at any scale. But talk about caching, why it's traditionally been so difficult and how does Momento ease those difficulties? Yeah, so there is something that I actually used to say all the time and I still say it is it's always too early or too late to add caching. So let me break that down a little bit. Caching is traditionally very attached to databases.  So that's why it's too early to add cash. What do I mean by too late? Well, because you never focus on it when you're little and when you're just starting out with a business when you quickly hit that point of growth where you just sort of exploding in popularity all of a sudden all these problems are happening all over your architecture. No one really has time to go and add a cash. And by the way, at that point your database is also scaled to something that is of a crazy size and it becomes very risky to change anything around it. So that's why it's too late to add caching at that point is oftentimes not worth the risk. And what ends up happening is people just deal with painful database scaling issues or they throw a ton of money at the problem which a lot of fast growth companies do decide to do. So that is why caching is too difficult. To time it right is very difficult and to configure it right. And you have to take time to make it secure and make it highly available. And time is a precious resource when you're growing out of them as a fast growth company. So the difficulty of managing your cluster is growth exponentially with the size. Every business wishes to hit that exponential growth. Once you do some of the largest companies when they get there what they end up doing is they hire and they grow in-house their own caching teams. So on momentum really we just we wanna be able to handle that for other companies instead of having every company go and have to build it from scratch. So it sounds like caching is a chicken and egg scenario. Talk to me a little bit about some of your customer conversations where they typically are too early too late and how you come in there and help them understand and really kind of find that goldilocks moment. Yeah, totally. So to us I think the ultimate goal is to make it so seamless and so frictionless that it's not like this big thing that you have to tackle even when you're small. It's always easier to integrate it more seamlessly when your architecture is at a simpler stage and then we scale with you, we grow with you. A lot of the time we find that folks shy away from caching it is a difficult problem. They shy away from caching because they see the barrier to entry is too large. So really we wanna reduce that barrier to entry to basically essentially zero. When it's so low effort then you're not really gonna think about how much effort you're gonna have to put in in order to integrate it into your stack. We work with companies of all sizes. So as I mentioned, we work with a lot of small startups that's just getting started and they just can't be bothered to manage caching infrastructure on their own. And they can get started with momentum with just a couple lines of code with a few clicks. It's really easy for those folks. We also work with large enterprises that have existed for decades and decades. And there are lots of case studies, IoT companies, media entertainment companies, gaming companies has been around for a while. We've helped them do an entire migration of sorts to move on to momentum. And there we're able to deploy our in-house caching experts, our engineers on site with them and really work hand in hand and provide a bunch of developer tools to really ease that transition. Some of it is really seamless and really just plug and play. Sometimes we joke about how it takes much, much longer to actually push through the paper contract than it does to actually do the coding and the technical exercise to move to momentum. And we've done that a few times now with a few enterprises as well. So can you talk just about some of the momentum caching use cases that you guys are helping customers to solve? Yeah, of course. So one of the most common use cases is caching for traditional databases. So caching for RDS or Aurora. So for instance, for one of our customer Saturn, they have this Postgres managed database on AWS. And the way traditionally to scale something like that is you go in and you change the server type to the next biggest server instance type. Oftentimes you're doubling the capacity even when you may only wanna grow it by 10 to 20%. So a lot of the additional capacity, you're just over provision and you're leaving it there or hopefully one day the customer workload grows to that size. So with something like caching on top of it, you are able to really utilize and offload a lot of the traffic to your cache thereby saving a lot of your money on the databases. And so something like Amazon RDS, Aurora, Amazon RDS, MySQL, Amazon RDS, Postgres, those are all popular databases that we provide caching on top of. Others use us with even services like DynamoDB, a very beloved developer product as well. But with any database, there are certain limitations and for caches, we're able to handle a lot more load than the traditional databases allow. So that's sort of one of the most common use cases that we serve. Got it. And thanks for mentioning that customer story. That was gonna be my next question. I know how important customers are to memento. It's on your website, you guys talk about, we work backwards from the customer. What are some of the business outcomes that customers are achieving? I imagine faster time to market, improved developer productivity, but give me some of those like really substantive business outcomes that companies can expect to achieve when they work with you. Yeah, I think the most, maybe boring in a sense, but most substantive is money, is cost. In this day and age, a lot of companies are focused on their infrastructure spend. I will bet you that for a lot of companies, databases or any kind of storage, data storage is one of the top three line items when you look at your cloud spend. So for one of our customers, Wise Labs, they make security cameras and they're an IOT company. We essentially went in with a very friendly intro. We went in where it's Amazonias. So we went in and we try to just look at their architecture overall. We try to look for areas where they can be optimized. And we work together on a lot of different optimizations over the years. They're one of our first partners and customers. We've been able to help them save hundreds of thousands of dollars, not just by sort of providing services as a part of Momento, but really by just collaborating on some of the architecture inefficiencies and looking for areas where we can be helpful in general. Like I said, we have in-house experts of infrastructure. So that's really ultimately where the bond between Momento and its customers gets solidified is by providing real impact to the business. And those savings have not stopped. We're still in the middle of collaborating and finding more opportunities. And you got to think about the total cost of ownership as well. Of course, there is the hard dollars that show up on your cloud bill. But apart from that, there's a lot of additional engineering cycles that we were able to save them so that they're able to deploy these engineers to newer projects and bigger features for their customers and their consumers. So big outcomes that the technology is delivering for customers. Talk about availability work and folks get their hands on it. I saw on the website, the AWS Marketplace, but give us an idea of where customers and prospects can go and test this out. You know, on our website, we recently launched a brand new console, the Momento console. I time myself now. I know I'm very familiar with our product, but even as a newcomer, I've seen a lot of other customers do this. In under a minute, you can get started with your own cache. It's instant. It becomes available instantly to you. And then you can start writing items and putting data inside and retrieving data all within under 60 seconds for myself. You know, I think I've said on Twitter that anybody taking more than 60 seconds, I'll buy them a coffee or send them a free Momento sticker. It sounds like it's all about speed. It also sounds like, and this is gonna be a silly pun, that there's a lot of momentum at Momento. So talk to me, wrap us up here with, what's some of the things next that your customers and your prospects can expect from Momento? Yeah, I think bigger, faster, cheaper cache. We're always looking for ways to innovate. We're big fans of Amazon. That's where we came from. And somebody said that customers will never want more expensive products. They always want cheaper and cheaper. But more exciting is, we also have Momental Topics that we're working on. And it's already launched and it's in sync preview right now. It's a messaging system pops up. So a lot of gaming customers are really excited because they're able to build chats and leaderboards and a lot of exciting real-time interactions, applications on top of Momental Topics. And of course, we are working on sort of transformative technologies as well in the general VAI field, looking at ways that we can stay relevant and help sort of catapult some of our fellow startups into success as well by backing their databases and their general VAI infrastructure. Awesome, lots of good stuff coming. Danielle and Mia, thank you so much for joining me on theCUBE as part of this CUBE conversation. You were awesome.  Thank you so much, Lisa. It was such fun to talk about Momental and Serverless with you. Yeah, you got great, great energy. We wanna thank you for watching. I'm Lisa Martin. Keep it right here for more action on theCUBE as you know, your leader in hybrid tech event coverage.


The next item of business is consideration of business motion 473, in the name of George Adam, on behalf of the parliamentary bureau, setting out a business programme. I call on George Adam to move the motion. The question is that motion 473 be agreed. Are we all agreed? The motion is therefore agreed. The next item of business is consideration of parliamentary bureau motion 474, on a temporary amendment to standing orders. I ask George Adam, on behalf of the parliamentary bureau, to speak to and move the motion. Thank you, Presiding Officer. This motion amends the temporary standing order rule 3 to extend the period for which access to the public gallery is suspended until 9 October 2021. The motion is brought forward to reflect the SPCB's decision on the matter. Members will wish to note that, should public health circumstances allow it, it would be possible to reinstate access to the gallery before this date. The question on this motion will be put at decision time. The next item of business is consideration of motions 476, 477 and 478 on approval of SSIs. I ask George Adam, on behalf of the Scottish Government, to speak to and move the motions. Thank you, Presiding Officer. I rise, hopefully, for the last time, to move three SSIs. The first being the health protection coronavirus restriction requirements, local level Scotland amendment 25, regulations 2021. Those regulations amend the health protection coronavirus restrictions and requirements local level Scotland regulations 2020 and are amended to allow the temporary removal of face coverings by a person receiving treatments around the mouth and nose. The individual providing the treatment must take appropriate mitigation measures to minimise exposure to coronavirus. Guidance will recommend the type 2, a fluid-resistant surgical mask, plus face shield goggles should be in place for the individual providing the treatment as a mitigating measure. To permit indoor organised activity in level 2 areas, the adjustment allows non-sporting organised activities to take place in level 2 areas for individuals of all ages. The changes recognise the social well-being benefit that can be felt for attending such clubs and groups. Those regulations came into force on 31 May. We have the health and protection coronavirus restrictions requirement local level Scotland amendment 26, regulations 2021. Those regulations amend the health protection coronavirus restrictions requirement local levels Scotland regulations 2020 and are amended to adjust the allocation of levels throughout Scotland. Moving to level 2, the city of Glasgow, moving to level 1, Highland, Argyll and Bute, Aberdeen City, Aberdeenshire, Murray, Angus, Perthinkan Ross, Fife, Falkirk, West Lothian, East Lothian, Inverclyde, Western Bartonshire, Dumfries and Galloway and Borders. Moving to level 0, the islands in the Highland area except Isle of Skye, Orkney Islands, Shetland Isles, Nye Island and Shire—I asked Dr Allan how to pronounce that. Disasterously. The Isle of Collinsay, the Isle of Iona, the Isle of Islay, the Isle of Dura, the Isle of Mull, the Isle of Orensay, the Isle of Tyree and the Isle of Alva to permit no physical distancing when a person is married or entering a civil partnership is being accompanied from one part of a premise to part of those premises where a marriage or civil partnership registration is taken place. That ensures that a party to the marriage or civil partnership can be accompanied down the Isle or similar by a family member or a friend from another household, as is in line with many traditions. To adjust the existing exemptions to face covering requirements, applying in respect of parties to be married or entering into a civil partnership to effect that the exemption also applies while there are being accompanied by other persons down the Isle or similar. To permit funfares to be open and public in level 2 areas, those regulations came into force on June 5. The final one is the health protection coronavirus international travel Scotland amendment 12, regulations 2021. That instrument makes further amendments to the health protection coronavirus international travel regulation 2020 and are amended to remove Portugal from the list of exempt countries, territories, parts of countries or territories in part 1 or schedule A1 on principle regulations. The regulations also add Afghanistan, Bahrain, Costa Rica, Egypt, Sri Lanka, Sudan and Trinidad and Tobago to the list of acute risk countries, territories and parts of countries or territories in schedule A2 of the principle regulations. Those regulations came into force on 8 June. Thank you Minister. The question on these motions will be put at decision time. There are two questions to be put as a result of today's business. The first is that motion 474, in the name of George Adam, on temporary amendment to standing orders, be agreed. Are we all agreed? The motion is therefore agreed. I propose to put a single question on the three SSI motions. Does any member object? The final question is that motions 476, 477 and 478 on approval of SSIs be agreed. Are we all agreed? The motion is therefore agreed. That concludes decision time and will now move on to members' business. I would ask members who are leaving the chamber to do so quietly.