All right, thanks for coming to this session. My name is Raghu Yiluri, and I work at Intel Corporation. And I'm part of the data center and cloud products group. And I work on cloud security. I've been doing virtualization and cloud security for some time. And today I'm going to talk about infrastructure security. Specifically, there are many applications and workloads that need regulation and compliance. And they need to be controlled on where they run and where they migrate. So that's the focus of today's session. And I'm going to walk through what we are doing at Intel and what we are trying to do through the OpenStack community and into OpenStack is set of security controls that help you monitor and meet your policy and compliance requirements. The traditional security controls that are there today in data center, they are definitely necessary when you move to virtualization and cloud, but they are not sufficient. So we are trying to enable a set of new controls so that you have the same visibility, the same control that you have in a traditional data center setting, even in this abstracted world of virtualization and cloud. Just to frame the problem, I'm going to set up the problem, what we are trying to address really, but we'll transition to solution quite quickly and show you what we are doing in OpenStack. And I'm going to close with a couple of here where we are trying to go, taking this location and boundary control into the future. And I've walked through a couple of use cases, a couple of examples, and give you a sense for what versions of OpenStack we are trying to target for those. See, this is the big picture of security challenges in the cloud. It boils down to three things, visibility, control, and compliance. Beyond that headline, if you start looking at specific questions, how do I protect my VM work, my payloads when I'm in the cloud? How do I have visibility to the integrity of the infrastructure at a cloud provider so that I have the same confidence that I have running applications in a well-controlled environment like my own internal data center? Each is a huge topic. So today, the focus is on the one in red. How do you do segregation and location control for your workloads? So what's the challenge really? Policy requirements. There are a lot of policy regulations where sensitive data and apps cannot read the organization in which they are being run. There are data privacy, data governance requirements that constrain the movement of workloads. And there are cases where extremely sensitive data and apps have to run in certain quality hardware and security zones. In a typical enterprise well-controlled data center, it's relatively easy to do this. But as you get into more cloud kind of a model where there's multi-tenancy and all that, it's extremely difficult. And then to add to the policy problems, the agility of technology has added more challenges to it. I mean, at the end of the day, anything that is virtualized, it's set of virtual servers are essentially a set of files. You can copy them, you can move them, you can run them wherever you want. And with the notion of hybrid clouds and overlays and all, it becomes even more easier to move workloads from one to the other so the lines are getting pretty blurred here. This is the challenge. And this drives into every set of requirements, OK? You need to run applications in the internal data centers. You need to run apps to do governance and data sovereignty issues. You have to run in the correct geography or the right data center in the right geography. And in some cases, you have to have a specific set of hardware on which your applications have to work. I translate these higher level requirements into a bottom line technical requirement. How do you ensure asset location or geolocation in a multi-tenant cloud environment? That is the fundamental technical requirement we at Intel sought out to at least address through our technology. How many heard of Intel TXT? Wow, that's pretty good. TXT is a set of technologies in x86 architecture which provide you a certain level of integrity assurance that is rooted in hardware. It's rooted in our CPUs. It's rooted in our chipsets. And it can provide you a level of assurance of the boot process, including the software stack that runs on the hardware. You can make very specific security claims about the integrity of the hardware on which your workloads are going to run. The good thing is, as a service provider, you can make that integrity transparent to the customer. You can say, customer x, your workloads are running on this set of clusters. And here is the integrity of that one. You can actually provide that as a report. There is a concept called measure boot where everything from the time you power on the server, every step in the boot process is measured. And those measurements are stored in a secure location in a TPM typically. The measured boot process plus the attestation of it provides you that assurance. I'm not going to get into a lot of detail of TXT, but at a higher level, that's what it is. And the chain of trust we like to assure you is starting from hardware through the firmware bias into the OS and the hypervisor. We are using the same set of controls that are available in hardware to write an asset descriptor into the TPM and leverage the same measured boot and attestation process to attest that asset descriptor. That's what we call geotagging or asset tagging. So asset tagging is a way to write an asset descriptor into the TPM of the server. And through a trusted launch process, make that visible to higher level entities that are running. So an open stack scheduler, for example, when it is trying to schedule a VM, a scheduler workload, can know which servers are trusted servers or trust verified servers to be better. And then it can deploy workloads on that. So what's a tag? An asset tag is a one or more name value pairs that are bound to the unique ID of the platform, typically like a motherboard ID or, in some cases, the endorsement certificate of the TPM. It is digitally signed. We take a hash of that one and we write that into a non-volatile index in the TPM. And the index is a write once only index. And the asset descriptor could be anything. It could be GPS coordinates. It could be functional description. This is my PCI cluster. This is my web front end cluster. You can name it whatever you want. It could be geographical information, not as GPS, but you can say, hey, this is my US location. This is my California location. So it can be textual description of geographies as well. So anything that makes sense for your business, you can use that as a way to write this tag and make that visible to higher levels of the stack. It's protected in the TPM. It is made visible through the measured boot and the attestation process, so I have integrity of it. And then I can do an attestation of it so that I can verify and assert that when that server says that is the geotag of it, I know that it is the right one that I expect that server to have. So this is the geotag process. And the way it would work in OpenStack is as following. Step zero is where you have some out of band mechanism to provision the tags onto the servers. So you see three clusters here. And all the clusters are provisioned with the right tags. So I have UK, US, and France as the example here. So step one is I have a workload that I'm trying to deploy. So I take the image, I put it up in Glance. In addition to putting the workload in Glance, I do one other thing. I set a set of launch policies for that workload. Today, we use Glance image registry to set those properties. So in this example, I set the policy as it has to be trust verified wherever the server on which it's running. And it has to have a geo of France. So now I set, I upload my workload to Glance. I set the launch policies for that workload. However, I figure I go instantiate this workload now. That's step two through the API servers. And we have created a new filter to OpenStack scheduler. It's called the trust and launch filter. So as you are running all the filters, there would be one filter called the trust and launch filter that's running. So essentially, it takes the subset of servers that the scheduler got from all the other filters. And then it's going to run a set of attestations, which are step five that you see here. So essentially, there is an attestation authority. I don't know how many of you are familiar. It is called Open Attestation today, OAT. And the filters call OAT with that subset of servers and say, hey, tell me which one of these things are trusted. And then the Open Attestation server essentially challenges all the servers in the various pools. And then it's going to come back with a set of results. And based on the results, the best server is picked by the scheduler. And it deploys the workload. The same exact process happens when you are migrating workloads as well, when you're doing a live migration. There are very few manuals. There's hardly any manual steps here, by the way. And I kind of made it sound like it's manual. The only secure, the only step that a system admin would go through is step zero, really, which is when you're racking and stacking servers, when they come in, you essentially, based on whatever your business requirements, you tag the servers with the appropriate set of tags. When you need to repurpose, essentially, you take the servers, and you run the provisioning tools, and you can repurpose them for a different set of asset tags. Same index, but different set of asset tags. At the high level, this is how boundary control works. And here are the extensions we did into Open Stack. We have a new location filter that you see on Nova Scheduler. We have set of horizon changes as plugins so that you have the ability to select what are called the launch policies for your VMs. And you have some extensions to the registry so that you can actually assign a set of launch policies to that specific image. And then the one in blue are the attestation and the provisioning tools that we provide. Either they come from Intel, or they come from a set of ISVs. All these, in the ones in yellow and the red, there will be Open Stack, and there will be open source components of all this so you can actually have the whole end-to-end system in open source.  I just want to call out a couple of them. There is a trusted asset tag part of Nova that's there. There's one for horizon. And then there is a wiki which kind of walks through how the process actually works. OK. We are targeting Kilo to upstream the code. The code's done. The code's available. It's vetted. As you can tell, the big focus of the Open Stack Foundation is to make sure that stability is there so new features will take some time to get into upstream. So we have tried it for Juno, but it didn't happen. So we are hoping that it'll happen into Kilo. But we will provide downloadable scripts that will be backport-portable to Ice House and Juno. So as you are ramping with Ice House and Juno, you would be able to at least get these scripts until we upstream that into the mainstream. I was going to actually show a demo, but I'm having some issues with my wireless connector, so I'm going to revert back to a set of screens here. So this is how you set tags. I wanted to show you that the tag doesn't have to be one thing or the other. In this example, you see state, you see country, and you actually have latitude and longitude from where I live. So this is how you create a set of tags. And there is no constraint on how many. I could even add a couple of ones, saying functional PCI server and something else. So I can have a set of heterogeneous tags that I can set. In this screen, what I'm trying to show you is, hey, I have my list of servers. I have the ability to pick one at a time if I want to have a separate tag. Or I can say, hey, here are my tags. Just go provision all of the servers with these tags. And then, essentially, a process on the back end, a pixie process, essentially will go securely write those tags into the TPMs and all the servers that you give. This is the only step that you, as a system admin, would have to do. One time, when the racking and stacking happen, are if you are trying to repurpose the server for something else. Here, I'm showing you how you set policies for VMs. You see the little extensions to Horizon that we made where, I don't know if you can see it very well from back there, but on the bottom, you see trust and location. And you have a set of policies that you can pick. Like I said a little while ago, there are no restrictions on how many policies. But in the reference implementation we have, we let you select up to five tags as policy. And then the magic number came after quite a lot of discussions with folks from NIST and a couple of ISVs were said, where we agreed that this is how many tags somebody can typically want to manage for a given set of servers. So five was that magic number. Again, there's no hard rule that it can be more or less, but the reference implementation gives you about five tags that you can set. It's country, state, region, function, and then one which was like other so that you can use it for any purpose. Those are the five attributes that you can set values for. And the column that shows trust policies in the middle, the lock sign shows that it is trust verified, meaning that the TXT measured boot has happened and the attestation has happened as well. And the second one kind of shows you that it has a location tag as well. Here, this is the actual instantiation of that image. So the scheduler ran the filter, found the right set of servers to launch, launch the virtual, the workloads. So that's where you see an instance name and you have the base image that's used and then you see the trust policies. I don't know if you can see the little highlight there, but it shows the state and the region for where the VM has launched. So this is it, that's pretty much it. Once you set that, once you set the policies, the scheduler filters will take care of controlling the placement of your workloads, controlling the migration of your workloads. If some policy doesn't match and it can't find a server, you won't get the launch of the instance and we write a set of logs for you in syslog and format. And if you have a mechanism to call into some other log things, we can easily plug that into the code base. So that kind of gets you to controlling VMs, okay? And even though a lot of people use share nothing kind of a model, meaning that all the VMs, the data, everything goes with it. You launch it on the server and that's where they run. But there are cases where storage volumes are important as well. So one of the use cases we are looking at is extending this geo mechanism for storage volumes. Okay, I'm gonna kind of talk about that a little bit where we are with it. And the second use case is when you put your VMs, when you put your data at a service provider, you would like some kind of data, some kind of protection. The typical model is, of course, is encryption. That's an easy answer, but who controls the keys? That's the harder answer, okay? Either you have two choices, no encryption or you have encryption that is controlled by the service provider. Okay, we heard enough from customers that they want to have control of the keys. So we are exploring a new option, what we call tenant-controlled VM encryption and decryption where the decryption keys are provided to the service provider only when the service provider can assert that there is some level of trustability of the infrastructure. Okay, I'm gonna walk through that one as well. So the geotag location control for volumes, right? So scenario one, I have two VMs, VM one, VM two, no attached storage. Everything is local storage. So when VM two launches, it's gonna have data, a database using the local storage on whatever machine it's launched. The model that we have today, the boundary control model, works perfectly fine. You know, the cloud controller talks to the attestation system, finds out that, hey, I have to have a geo constraint of France. It found the trusted pool there, launch VM and VM one, VM two, all policies are honored on that one. But if I go to scenario number two, I have VM one and VM two, but VM two has a storage volume that is mounted later. So my current implementation goes to the same process we did before. It launches it on the trusted pool on the left of this part of the picture. But once VM two got launched, it did an attach of a volume that may not meet the same policy. It could be somewhere else, or it could be maybe a different constraint than the one you had before. The current implementation of boundary control through the NOVA scheduler filter process does not address this scenario. So what we are trying to do is do exactly the same thing that we did for NOVA for Cinder as well. You know, Cinder has a Cinder scheduler, has the same plugin architecture that the NOVA scheduler has. So we are writing a new location filter that plugs into Cinder scheduler. Okay? And we are leveraging, assuming that the storage is on x86-based infrastructure, either DAS or scale out storage, we can do the same geo-tagging, the trusted geo-tagging process that I articulated a little while ago. And then I can use the same attestation system, the same provisioning, same attestation, the same filtering process, and I can find the right set of storage volumes that meet my policy. Okay? It does not work, I'm being very clear, it does not work for SAN and NAS systems yet because of, you know, they have different hyper, different operating systems, and you know, even though some of them have x86, they are not TXT-enabled and all that stuff. But as long as it is not NAS and SAN, you have scale out storage, you have direct attach storage with JBARDS, this would work. So there is a new location filter that you use, so when you're creating a volume, you can enforce the policy. So right at the time when a volume is getting created, you can say, I need this policy and the volume creation will be, and the scheduler goes through and creates the volume, you get it. The second case is the volume is already there and I'm trying to attach it. So we have a, you know, this is probably a little bit of an intrusive code. It's not the same plugin model, but we have to go into the check attach function in the NOVA API which does a few checks before it mounts any volumes. We have to go there and add a couple of lines of code which verifies that the VM location policy is the same as the volume location policy. With those two changes, we are able to enforce boundary control for storage volumes for create and attach. And you know, for folks who are familiar with Cinder, there are two other functions, migrate and backup. Okay, we think the same model could work for migrate as well because the location field, the scheduler does a very similar function when it's trying to migrate volumes, okay? The challenge is backup. Backup can go into any number of places, but ideally, you know, if you want to continue the chain of trust and boundary control, you need to get to backup as well. One option we are considering is assuming the backup goes to Swift, we can leverage the things called storage policies in Swift. You know, starting with Juno, there is this ability to set storage policies at the Cinder node or Cinder container level, and you can enforce policy there. So again, very early thinking on our part, but we can leverage the same storage policies that Swift has to continue this boundary and location protection down to backups as well. Here are a couple of screenshots, okay? So nothing different than what you have seen in the previous ones. On the left, you see trust and location for create volumes, and then here you see volumes created with the right geotags, and here is the attach. So you can see that volume, NC volume one attached to instance one, essentially showing that both the trust and the location policies for the attach have succeeded. In the other two cases you see on the top, we couldn't find the appropriate policy match, so even though those two volumes were trying to attach to a VM instance, they didn't get attached. So I'm gonna switch to the second use case, the idea of tenant control VM protection, right? The idea is simple, when the VMs and data are at rest or in transit or during up until execution, you want them to be encrypted. You want to only release the keys when there is sufficient assertion that number one, the servers on which these VMs are being launched are trusted, and then they meet the location policy. Only then the decryption keys are released, okay? This works well across all the hypervisors. I kind of probably failed to mention that early on. This is not, even though it's implemented into OpenStack, at the hyperlizer level, we support all hypervisors, ESX, Zen, KVM, Zen server, Citrix Zen server across all kinds of operating system, Red Hat, Suze, any of the Ubuntu, any of them. This one is actually being demonstrated, actually both of them are being demonstrated at the Intel booth today. So if you have time later today, I urge you to go down, take a look at boundary control for VMs, as well as tenant controlled encryption decryption. The architecture, I know I'm sorry, it's a kind of busy slide here, but the way the process works is as follows. The one in the red items are the new components here, okay? When you have images you're trying to upload into a cloud, you have the ability to encrypt them, you create your keys, you encrypt them, and the keys are stored in a key management server that's built on top of Barbican. How many of you are familiar with Barbican? Awesome. So we extended Barbican a little bit so that we can actually have a policy module in there. That can control when the keys get released and how they get released, okay? Step three, the encrypted blob goes into Glance. Step four, whatever is the initiation, a launch of a VM has been triggered. Step five, cloud controller downloads that encrypted blob from Glance onto a node, a compute node, okay? Actually that is step seven. And there is a plugin that we built called a policy plugin that plugs into Nova compute, and it does three things. Number one, as it is processing the blob, the VM image, it knows that it is encrypted, then it's gonna talk to the KMS, the key management system that is sitting at the enterprise. Okay, it says, hey, here I need this key and by the way, this is my TPM key, the TPM ID on which I'm running. And the key management system will use the TPM ID, get the assertion that the server is a trusted server. It's gonna take the decryption key and then wrap it with the TPM key. Okay, so the only entity that can unwrap this thing is the TPM because that's where the private key is. So even if somebody tries to man in the middle or sniff it, they can't get the private key because it's in the TPM. So I got the decryption key that's wrapped with the TPM key. I get it into the Nova compute. I use the TPM, decrypt that envelope, get the decryption key, decrypt the VM image, and launch it. So the only time the VM image and the data are in clear is when it is running on a specific server. Until then, everything is encrypted and nobody owns the keys other than the enterprise, okay? This is working end-to-end. The extensions to OpenStack are there. The extensions to Barbican are there. The extensions to the trust authority, the open attestations server are there and we are demonstrating that down at the Intel booth. We, the blueprints are getting done. We're gonna upload the blueprints relatively soon here. And I would like to see this in Kilo but it's not gonna happen, we know. So we're trying to see if we can at least target the L release for this, okay? We hear a lot of customers telling us that this is a desired feature. So hopefully we will get this pushed through the process, okay? I think I'm at the end. I want to kind of summarize a little bit, not sure how much time we have here. Maybe five more minutes. So boundary control is critical. It's not required for all workloads but a good chunk of business critical, mission critical workloads need some kind of compliance requirements, whether it is trust or location, boundary control that need to be met. You know, Intel TXT and the whole measured boot and the attestation process provides you the root of trust on which you can build this assurance of integrity of the launch process. Extensions to geotagging are there. I would urge you to go take a look and support the blueprints and get it through the process so that it can get upstream. So you don't need to deal with downloaded scripts and all that, you know, it's part of OpenStack upstream so you can get it by default when you get the distributions, okay? The two forward-looking ones that I shared, if you think those are interesting extensions, interesting use cases, let us know, you know, Intel guys, you know, either here or at the booth, be happy to get your input so that we can use that as a means to drive these use cases forward as fast as we can. Okay, with that, I'm done, open for questions. Anything that I can address for anybody? Yes, yes, I can actually walk you through that a little. So the way we do it is one or more tags which are named value pairs. We tie a user ID, UUID to it, create a X509 certificate. We take a SHA one or a SHA two depending on TPM one versus TPM two and we write either 20 bytes or 32 bytes into one of the index in the TPM, okay? You can see the index that, at least for TPM one dot two, the index is 4 million or 40 million 10. That's the index. Okay, for TPM two, we will do 32 bytes, assuming it's SHA 256 or if somebody really wants SHA 512, we can do the 64 bytes as well. Okay, but the initial release since TPM one twos are the more dumb prevalent ones, we would do 20 bytes. Any other questions? Yeah, yes. For the image, there is one set of encryption, one set of, there's one decryption key per image in the current prototype, okay? But that is just the way we did it. You can have, if you think every image, every instant needs a different one, you can do that as well. But in the current prototype, we have one decryption key per image. Yeah, absolutely agreed, yes. Okay, you know, sorry, was that a question there? Okay, any other questions? With the, one of the things I looked at is that Congress is something that they're looking at putting policy in. Is that something that you're looking at? Absolutely, yes. You know, all the policy that IT guys can't leave me. Policy is something that we are looking very carefully because we do a lot of policy definition, policy management, so Congress is a very promising thing for us so that there is a unified way of model for defining policy and a unified model for executing and orchestrating policy in the cloud. So we are looking at it. You know, one thing I want to mention, I forgot in all this is we are actively working closely with NIST and there is a interagency report called 7904 that talks about trusted geolocation in the cloud, okay? We actually have, I think, Mike on the back there from NIST. Mike, do you want to add one sentence, two sentences on what you guys are doing? I'm from NIST, it's the National Institute of Standards and Technology, part of the U.S. Department of Commerce and we write standards and guidelines for the U.S. government. So we've been collaborating with Intel for the past couple years, working on this geotag and trusted hardware booting process. We originally started out with just a VMware stack that are now moving to doing this with OpenStack and are in the process of building the OpenStack integration with their attestation service. So we are currently implementing the trusted boot process and the geotagging and then gonna work with Ragu and his team down the line to also build on the encryption and decryption of the VMs. Thanks, Mike. Any other questions? I got a couple of more minutes here, so. Yes, in a federated model. You know, to me, Congress is probably the most appropriate way to have a loosely coupled definition of what tags are and what policy is so that you can use that for federating across clouds. So I have a lot of hope for Congress, actually. All right, hey, I think that's it. We are running out of time. Oh, was there one more question? Yeah, go ahead. VM getting the asset tag from the host. VM can get an attestation of the tag. So it can get, it can VM can talk to an attestation system and it can get the attestation of the tag and when we attest, the assertion also has what the tag was. That the server presented. So conceptually, yes, the VM can get the tag through that assertion. Okay, all right, thanks for your time. Okay.


population for those of us in midlife are a lot of damaged human beings, myself included. I have suffered a lot of emotional trauma in the last decade and a half, since I've gone through a divorce. And this is the significant population. We have a population of emotionally wounded people. Now, let's identify something first. The number one emotional health issue that's facing almost everybody is, I'm not good enough, I'm not lovable, and I'm not likable. And dating the wrong people can trigger this over and over and over again, so there's no wonder many of you feel a sense of frustration, many of you feel like it isn't going to happen. Now, for a significant percentage of people that are over 45, 50, or 60 years old, it's not gonna happen for them. They're not going to meet a life partner, a good life partner, a healthy life partner.


Bravo 411 to VKR Urgent. Go ahead Bravo 411. Require urgent assistance at a domestic disturbance, priority code 2. Copy Bravo 411, VKR to any unit who can assist. You're highly motivated and looking for a rewarding career.  Become part of the Queensland Police Service to stop crime and make the community safer. See if you can make the difference. Visit policerecruit.com.au now.


So based on Boltzmann, we're now going to change the way we talk about things, at least we're on the microscopic and the physical thing. We will no longer say whether things will happen or they won't happen, but we're primarily going to talk about probabilities. How likely is it for something to happen? Is it more likely to be at low energy and what is the likelihood of population of high energy? But doing things on an absolute scale is a bit complicated, right? I didn't even tell what the zero value here was. The Boltzmann distribution, and many of the other things we do, they're going to become really powerful first when we start to compare different states. So let's do that. Let's assume that I have a state A and a state B. What they are doesn't matter for now because we know that the Boltzmann distribution should be valid for both of them, right? So the probability of being a state A, let's say that P A, and here I'm going to use the constant. There is some constant, I just don't know what it is. That is equal to a constant, raised, multiplied by the exponential, raised to minus the energy in state A divided by kT. And similarly, we know that the probability in state B equals the same constant, multiplied by the exponential, raised to minus eB divided by kT. Now we don't know what those constants are, but a cool thing here now, what if I simply take the quotient of this? So what is the probability of being in state A relative to be in state B? That is, that will tell me if that quotient is larger than one, it's going to be more likely to be in A, and otherwise it's going to be more likely to be in B. If I now divide these expressions, those two C's, they will disappear. So that will be e raised to minus eA divided by kT divided by the exponential of minus eB divided by kT. Yeah, that doesn't exactly look simpler, but if you know your exponential and logarithm laws, if I have a quotient of two exponentials, that turns into the difference of the exponent, right? You all knew that by heart. So this I can write as e, and now I have to be careful with the minus sign. So the minus sign, I'm going to say minus eA minus minus. You know what? It's much easier to write this way. I will raise that the e minus eA minus eB divided by kT. That still has this eA's, but now I'll take the final step here. I can write that that's simply the exponential raised to minus delta eAB divided by kT. And the cool thing, if I now have an energy difference, it does not matter whether zero scale on my axis is right. I can put that 500 meters below the ground here. The difference is still the same difference. So the relative probability of being in two states, A and B, only matters on the absolute difference in energy between those two states. I was running a little bit ahead of myself here. And in particular, that means that if an energy difference between two states is very small, then this is going to be roughly zero, and then that quotient is roughly one. If there is a very large energy gap between them, what this tells is that the state here that has the lower energy is going to have almost all the population, while the one with higher energy is hardly going to have any population. So this always works. It doesn't matter if A or B is more likely. And we completely got rid of this constant in front of the exponential. This is pretty darn cool. And this will work in general. There is just one small problem here. This will definitely work for the simple column I showed. But what if I compare this? The column here is simple. I will have high density down here. I will have lower density far up. And any two levels I pick here, this will be valid for. But what if I want to compare that column with, say, that column? So now my approximation of unit volume as a function of height doesn't really hold anymore. I couldn't instantly guess which one of those is more likely, but maybe we should take two more obvious examples, triangles. Here I have hardly any volume at all down on the good level. Well, we have tons of volume up here where the energy is higher and the particle density is likely to be lower. Here on the other hand, I have plenty of volume down here where particles really want to be and very low volume up here. We don't know this yet and we don't know what it's going to look like. But I hope that your gut feeling also says that this is going to be better. Because in this case, we will have many more particles here because there is simply more room here. While here we hardly have any room, so there are going to be very few particles that can fit down here. The reason why we can't handle that is that my simple approximation assumed unit volume. Or rather, unit volume, a simpler way of saying this, at each height in that simple column, I kind of assumed that there is just one state. The state just depended on the height. So this only works if I'm comparing two specific states. But in many cases, there's going to be more than one place that I can put something in one state. At a very wide column, two particles can be on the same height. We're going to need to account for that difference. And it turns out that it's not going to be quite as hard as we think.


So, if you remember in your demand analysis when we are discussing about it, we have identified there are number of factors which affects the level of demand like what is the price of it, what is the price of substitute good, what is the income of the consumer, what is the future anticipation of price and what is the number of consumer in the market. Apart from this also, these are the information that helps us to know or helps us to decide the firms to know what is the level of demand whether demand goes in an increasing way or demand goes on a decreasing way. So, in today's class we will focus on the forecasting of the demand, how generally the firms they does the demand forecasting keeping all the information used or may be using all this information whatever available to them for knowing what will be the demand for their product in the future. So, today we will talk about demand forecasting, what is basically demand forecasting, what is the need, what are the different types of demand forecasting and what are the different methods to do this demand forecasting. So, today we will focus more on the subjective method of the demand forecasting. So, initially we will know what is demand forecasting, what are the different types of demand forecasting and then we will talk about the subjective method of the demand forecasting. Now, why to forecast demand? What is the need or why generally the firms, they do a market survey, they do a market research to know what is the demand. The, if you look at the economic condition is always depends on the economic activities of the firm. And business environment whatever the business environment that is dependent on the economic activity and since there is always a cyclical nature of the economic activity sometimes it is expand sometimes it is contract. That way it also affect the business environment and that is why there is a uncertainty, there is a volatility and there is some amount of risk if there is a plan and actual is not matching. And also the dynamic because every it is not a static condition business environment every time it gets changes with the change in the related variable. So, demand forecasting is required to know because the environment is uncertain, it is volatile, it is dynamic and it is risky. And better business decision can be taken if the uncertainty can be eliminated or the reduced. So, if I know that it is going to be uncertain whatever the decision I am taken it may not be optimal in the future time period. So, one has to reduce the or the eliminate the uncertainty associated with it and then only that can be a better business decision or that can be profitable or the successful business decision. So, demand forecasting basically predicts the future demand of the firm products and this is one way to reduce the uncertainty because now predicting the future demand will reduce the uncertainty that what will be the demand. And on that basis now the supply can be planned now the price can be planned or there are other activities also can be planned. So, demand forecasting is basically to predict the future demand of the firm's product and this is one way to reduce the uncertainty and this way we can reduce the uncertainty maybe the business decision can be also profitable and viable. So, some of the business decision making that is added by the good demand forecast if there is a good demand forecasting it helps in some of the business decision making. And what is the business what are the what are those business decision which gets gets good positive outcome by demand forecasting. Determining the optimal level of output what is the optimal level of output that can be decided through the demand forecast because on the basis of the demand the output plan can be decided and whether at that output level this is the optimal level of the firm whether the firm needs to expand whether the firm needs to contract whether the firm needs to whether they can expand at the increasing cost whether they can expand at the decreasing cost. And on the final how they can determine the output level through the demand forecast then planning and scheduling the production distribution and the transportation. So, this demand forecast helps them in scheduling the production like the future demand forecast says that in the month of Jan 20 units require month of Feb 40 units require month of March 50 units require month of April 20 units require on that basis the production scheduling can be done in a way so that it delivers 20 units in Jan 30 units in Feb 40 units in March and 50 unit in April matching the demand it can just deliver that. So, the production scheduling can be done if the demand forecast the forecasted demand is known for the specific time period also the distribution scheduling the distribution and scheduling the transportation because it is not that every time the producer is the supplier of the product. If it is if producer is not the supplier of the product once they produce they have to also plan the distribution and the transportation means how the end product reaches to the market to the retailer and on that basis they know that if Jan 20 units is required how they have to plan that the transportation of the 20 units to reach the retailer before Jan. So, this planning scheduling of production distribution and transportation can be done if the demand forecast is known for the specific time period. Acquiring inputs typically the raw materials labor and capital if you know that what is the requirement of output in a next couple of month next couple of week. Accordingly the input plan can be also done that what is the raw material required for that typical output, typical quantity of output what is the required labor what is the required capital and that way the acquisition of the inputs can be done on the basis of the demand forecast. Demand forecast helps in determining constant pricing strategy.  If the demand is more then the scale of operation is more the possibility is that at least the firm is getting some economies of scale. Similarly, the determining the cost like whether it should be going to be increasing cost in the scale of operation whether it is going to be decreasing cost in the scale of operation this can be decided on the basis of the demand forecast. Demand forecast helps in decision on expansion and exit strategy of the product. How it helps in expansion and exit strategy of the product? If the demand forecast says that by the end of this quarter the demand has to be 100 units. Taking specific example if it is 100 units and if a specific firm has a capability of producing only 80 units through the demand forecast it helps them that they have to expand the output in order to fulfill the market demand for their product. And they can do the expansion activity on the basis that even if now at the present time period the demand is not 100 units because in next quarter it is going to be 100 unit they have to expand and produce 100 unit in order to meet the demand for the product. Similarly, it also helps in exit strategy of the product because if the forecasted demand says that the market for this product is going to down there is no demand for this product it is going to decrease or maybe there is no proper demand for this product. Generally that helps the firms to identify with that level of demand whether at least they are covering whatever the price they are going to charge and with that price whether at least they are covering their variable cost of production or not. If the variable cost of production is also they are not covering up they will prefer to go out of this market. So, forecasted demand also helps in the exit strategy of the firm that if the what is the level of demand with that level of demand whether the firm can survive in the market or not if and if they can survive in the market if they cannot survive in the market where they should exit or where they should shut down their operation it can be help through the demand forecasting. Finally, the demand forecasting also helps in the meeting the customer order dates and customer satisfaction. How this customer order date and customer satisfaction is related to the demand forecast because it will give us that what is the demand from the customer in the different time period and on that basis the firm can work on the production scheduling the firm can work on the distribution the firm can work on the transportation and finally, that will that will help in fulfilling that customer order dates on that specific day and also the customer satisfaction because whatever the demand they are doing in that time period that is getting fulfilled with the specific time period. So, forecasted demand helps in determining the optimal level of output planning and scheduling production distribution and transportation. It helps in acquiring inputs raw material labor and capital. It helps in determining the cost and pricing strategy. It helps in taking decision on expansion and exit strategy for the product and it also helps in meeting the customer order dates and the customer satisfaction. So, demand forecasting taking all this taking all this usefulness of the demand forecasting we can say that demand forecasting is the starting point of fulfilling a customer order its accuracy is paramount that accuracy of the demand forecasting is the paramount and based on forecasted demand a firm commits its resources capability for a period of time and also the capacity to create the goods and services that its customer value and willing to pay for it. So, forecasted demand helps the firms to do the commitment on the basis of the resources, on the basis of the capacity, on the basis of the capability for a time period to create goods and services for that customer and particularly customer what they generally value for it. Generally, if the forecast is low it will result in loss as opportunity and customer dissatisfaction. If the forecast is not proper, if whatever the forecast that is not appearing it is considered as the low forecast and what is the outcome over here the outcome is the result in the low loss sales opportunity and the customer dissatisfaction. Whereas, the high forecast will lead to accumulation of inventory resulting in higher cost and less profit for the firm. So, if the forecast is not proper either it can be low or it can be high. If it is low generally it leads to the loss sales opportunity because firm is not ready to fulfill the demand and because the demand forecast is showing or in a lower note and that is why if it is not ready to fulfill the demand from the consumer they lost the sales opportunity and the consumer get dissatisfied that whenever the demand for the product that is not getting supplied by the firm and there is a waiting time to get their product. Whereas, if the demand forecast is not proper and if it is forecasting very high it will lead to accumulation of inventory because whatever if it is a high forecast the firm has already produced a higher amount of the product and if the higher amount of the product is produced and if it is not getting sold in the market because of low consumer demand that leads to accumulation of inventory which incurs a cost for maintaining or the managing the inventory which results in the higher cost because you are producing at a higher level and that is not getting immediately sold and also that is why it gives less profit because supply is more demand is less and on the basis of the basic market forces the firm has to have the firm has to charge a lower price in order to also dispose of some amount of the inventory if they cannot keep it for a longer period of time. So, high forecast is not good low forecast is not good low forecast is also leading to negative outcome and high forecast is also leading to negative outcome for the firm. Thus, forecast accuracy plays an crucial role in determining the effectiveness and the efficiency of the firm. So, when it comes to a proper forecast or a good forecast it helps in the effectiveness of the firm or the efficiency of the firm. Now, this demand forecasting is categorized on the basis of level of forecasting on the basis of the time period and on the basis of the nature of goods. So, that in demand forecasting is can be on the basis of level forecasting on the basis of the time period and on the basis of the nature of the goods. So, if the categorization is on the basis of the level of forecasting, what are the different level? One is firm level and second is the industry level. So, in case of firm level, it refers to the forecasting of demand by an individual firm for its product. So, level of forecasting the first level comes in the firms level. And in firms level, this is the forecasting of the demand of the individual firms for its product. So, typically when the individual firm does the forecasting for their demand for their product, this is firm level. And here the most important category for a manager for taking important decision related to the marketing and production. So, this firm level forecasting, demand forecasting helps the manager for taking important decision related to marketing and the production. The second level of, second categorization is on the basis of the industry level forecasting. And what is industry level forecasting? It refers to the demand forecasting of a product in an industry as a whole. So, it is not about a specific firms product, rather the products which comes from the industry as a whole. So, there may be multi-products like if you consider, suppose PNG, if you look at their product in all the segment of the, all the segment, whether it is food, whether it is non-food, whether it is whether it is non-food and also in the FMCG. So, FMCG also they have variety of product. So, when the demand forecasting is done for all this product for the, what is the demand forecasting for PNG as a whole, that becomes the industry level. And what is the firms level for typically for a toothpaste, for a soap, if the demand forecasting is done, may be with it is for the doves or for the granular shampoo, in this case generally this is the firm level. So, industry level forecasting is done as the demand forecasting of the entire products of all the industry. It provides insight into the growth pattern of the industry, because as a whole if the demand forecasting is good and through the demand forecasting they are coming to know that the products are they are going to do well in the market in the long run, because of their increased demand. This provide a insight into the growth pattern of the industry and this is also helps in finding out what is the relative contribution of the industry in national income. Because through demand forecasting they will know that what is the going to be the revenue, what is the going to be the their contribution, what is the going to be the growth in the income and through that also they can find out what is the contribution of the specific industry in the national income. Same way when it is done in a sectoral level also it helps in finding out what is the growth of the sector in the long run and also the growth of the contribution of the sectoral income in case of the national income. Then if it is in the economy level or the macro level, so when the when the categorization by the level of forecasting it is it is from the micro level to macro level. Micro level we talk about the farm level forecasting and then we talk about the industry level forecasting and finally we reach to the larger scale of forecasting that is the economy or the macro level of forecasting. Here the forecasting refers to the what is the forecasting of aggregate demand in the economy. So, this is combining together all the sector, all the industry, all the farms at a specific time. What should be the aggregate demand for all the products coming out from various sector in the economy in a specific time period that is done through the economy level forecasting or the macro level forecasting. And generally this forecasting helps in policy formulation for at the government level that what should be the different policy whether it is sales distribution policy whether it is the production policy whether it is the regulatory policy or the planning. This generally helps the government in formulating different policy and also for planning in for the next time period and this in the macro sense and the farm level is generally in the micro sense. Then the categorization comes in the form of the time period. So, categorization here there are two type of two type of categorization one short term and second one is the long term. Short term is generally the forecasting usually for a period of time that is less than 1 year and long term this is the time horizon of 5 to 7 year and it can be also extended to 10 to 20 years. Now, what is the forecasting what we do in the short term one with this is for a time period which is less than 1 year it never crosses more than 1 year and long term we can do it do the forecasting for a time horizon of 5 to 7 years and also it can be extended from 10 to 12 years. Now, what kind of forecasting we do in the short term in the short term this is to avoid generally the short term forecasting is done to avoid the under production and the over production and also to take a decision that what should be the inventory level what should be the cost on the variable factor what should be the sales target and what should be the appropriate pricing strategy to take a decision on all these things generally the short term forecasting is done. And long term forecasting is for the manpower planning, long term capital requirement, investment decision what should be the interdependence of the industry. So, generally it is avoid generally this long term is mainly for the manpower planning long term capital requirement because if you look at if you are doing a forecasting from 5 to 7 years that generally helps in planning for next 5 years that what should be the demand on that basis what should be the output and how this output should be produced and how the demand to be satisfied. So, long term forecasting is mainly for the manpower planning long term capital requirement investment decision and what should be the interdependence at the industry level to take a decision on that generally the forecasting helps. Then the categorization is on the basis of the nature of the goods and here we will take two categorization one on the basis of the consumer goods and second on the basis of the capital goods. So, in case of consumer goods generally the categorization we do the forecasting is needed if it is a case of the durable goods either it is the new product altogether new demand or the replacement demand and in the non durable generally the demand differs on the basis of the income level, on the basis of the social status, on the basis of the age, on the basis of the education, on the basis of the occupation of consumer. So, non durable the demand it depends on all this also on the basis of the gender. So, this durable and non durable consumer goods the forecasting is different because for this durable the forecasting is mainly on the basis of that what is the new demand is going to come and what is the replacement demand whereas, in case of non durable the demand changes due to all these factors and the forecasting has to be done when there is a change in the income the forecasting has to be done what happens if the social status changes the forecasting when the age changes the forecasting when the education level changes and also the occupation of the consumer. The second categorization is on the basis of the capital goods here typically the nature is derived demand because the capital goods is get capital goods is used to get produce the consumer goods. So, if there is a demand for capital goods that comes from the derived demand from the consumer goods and that is why this forecasting of the capital goods demand for the capital goods generally helps in the long term growth rather than the short term whatever the short term assessment rather than it helps in the long term growth. Now, these are the steps for the demand forecasting because demand forecasting is it is a if you look at it very exhaustive process and these are the following are the step typical steps for a systematic demand forecasting. Now, what is the first step? First step is to understand the objective. Now, what is the objective for what this forecasting is being done whether to know the inventory whether to know the demand whether to understand the time whether to understand the about the product whether to understand the whatever the dimension they want to know which for the first thing is to understand the objective why the forecasting is being done. The second is determining the time perspective means whatever the goal within what time period this goal has to be achieved.  Then understanding and identifying the customer segment like if the product is about the younger generation the customer segment has to come from the younger generation. If the customer segment is from the working people if the product is for the working people the customer segment should be the working people. If the product is for the kid then basically if we have to identify the parents who is having the small kid. So, the first is to understand the objective. Second is to determine the time perspective and third is to understand and identify the customer segments. Then after identifying the customer segment the next task come as the identify the major factors that influence the demand forecast. Because whatever the factors which influence the demand forecast we need to moderate we need to ration that and that is how we need to identify the major factors that influence the demand forecast. After doing this determine the appropriate forecasting technique what is the appropriate forecasting technique to forecast specific about the specific product in a specific time period and with a specific customer group. And finally after determining and the appropriate forecasting technique we need to do the estimation and interpretation of the result. So, these are the tips generally being followed when it comes to the level of when it comes to do the forecasting. Understanding the objective determining the time perspective understand and identify the customer segment. Identify the major factor that influence the demand forecast. Determining the appropriate forecasting technique and finally the estimation and interpretation of the


Live from San Francisco, California. Extracting the signal from the noise. It's theCUBE, covering DockerCon 2015. Brought to you by SiliconANGLE Media. With special thanks to Docker. Now your hosts, Stu Miniman and Jeff Frick. Welcome back to SiliconANGLE TVs. Live, wall-to-wall coverage from DockerCon 2015. Here in San Francisco, I'm Stu Miniman with wikibon.com. My guest host for this segment is Brian Gracey from the Cloudcast. Brian, thanks for joining us. Thanks for having me. All right, and we've got on our segment and what I wanted to bring Brian is we've got Adrian Cockruff, who's a technology fellow at Battery Ventures. You know, so many of these new technologies over the last couple of years. They talk about what's happening in cloud, containers, and microservices. You know, Adrian's sessions are some of the ones that help educate me, help educate the community. So Adrian, I know you're swamped at this show. Appreciate you taking time to join us again on theCUBE. You know, welcome back here at Cubelon. All right, so tell us Adrian. You know, what excites you about this show? You know, you've been watching this space since, you know, the early days.  So what's your take of the show so far? Well, what I think is particularly interesting with the Docker ecosystem is the speed it's moving at. And that's really unprecedented. It's moved, typically these kinds of technologies take years to get from an idea to be something that enterprises have gone for. And, you know, one of the interesting things that I saw this morning in Ben's keynote was, I think 97% of enterprises are adopting or want to adopt Docker at this point and wave way earlier and much higher penetration than anything else in the history of kind of new technologies coming along. So that's what's particularly interesting. Means that the whole ecosystem is changing week by week. There are new announcements every week. There's a lot of announcements this week, but really every week there is something large that changes the ecosystem. And it's fun for me to just keep surfing this wave that keeps changing and you have to be very agile if you're going to operate in this space. So that makes it fun, right? As a VC, it means that everything you know is wrong once a week means that you have lots of opportunities to try and find, okay, who is actually going to break through and be the next interesting piece of this ecosystem. And that's my new job. Sorry, Adrian, last year at the DockerCon show in San Francisco, Docker 1.0 released. We're up to Docker Engine 1.7 and we've got all these other pieces from machines, warm compose and all the others. So where are we with the technology? How robust is the stack? Where are the big gaps and where are some of those major opportunities that you see today? Well, I just gave my talk and the summary of my talk was that in 2014, there were people running Docker in production and it was really DIY frameworks. In fact, there were people in 2013 running Docker in production. I think it was Gilt and Drama Fever and a few people very early on went, okay, that solves the problem. I was trying to build something to put, to build a framework anyway. I can use Docker as a piece of that framework to go and put something up. 2014, a lot more people copied them and what you're seeing this year is that the systems are starting to mature. So the best practices, the security white paper, we're getting standardization, really big announcements today, things like having pluggable ability so you can now run cluster HQ and we've at the same time on Docker instead of having one or the other. So those kinds of things are really, it's starting to mature to the point where you can build standard practices and tooling around everything. And I think during this second half of this year, you'll start to see many more big enterprises start to adopt and really roll things out. And in 2016, it's going to be pretty mature, very well standardized, the good practices are in there, people know what they shouldn't be doing and it's getting there. And that's pretty rapid move for software and the enterprise space. Yeah, so you've got a slide that you use in some of your talks that said 2014, nobody had it in their roadmap, 2015 everybody's got it on their roadmap. They're releasing stuff every two months. If you put that in perspective, VMware is once every 12 months, OpenStacks every six months, they're every two months. How do you, and we've got all these sort of kind of overlapping projects. You've got multiple network ways, multiple service discoveries. Do you think as this becomes more mainstream, people will just sort of standardize on a stack or do you think we'll keep having the developer mindset of lots of tools or how do you start to see that ecosystem shake out? I think it becomes all things to all people. It's not going to be one stack. It's not going to be one architecture. There are people that are going to write their coding go, do a static build, build a scratch container that contains just one binary and have that be their container. And it's tiny and it's fast and it's secure and you can't, it doesn't have a shell. You can't SH, there's nothing there to log into. So that's at one extreme. At the other extreme, somebody's going to look at this big pile of crud in their data center and says, you know what, I could run all of that in one container. And I got this, you know, I maybe got an enterprise service bus lurking in the middle of a container or something insane like that. But you could wrap everything in it. But I get value from the fact I've now wrapped this complicated configuration into a container. I can now move it around. I need this thing. Maybe it's my point of sale thing I have in a shop and it contains pile of old junk, right? But I have 600 retail stores. I could now deliver that in a containerized way. There's people that are going to be putting all kinds of stuff in there. And then you've got the VMware world really starting to adopt containers and VMware making it easy to have containers be first class citizens. You've got all of the sort of past vendors adopting it. And so I think it's going to be everything. It's not going to be one specific place. But the thing it enables that's going to allow new architectures is these extremely rapid response systems. Because you can fire up containers in seconds, you can start auto-scaling in seconds. And I think if you look at AWS Lambda, which is not a Docker-based thing, but it's a container that gets fired up to run one request and then shuts down again, that's sort of the other extreme, right? You now have containers that are completely ephemeral. So there will be possibly systems getting closer to sort of the Lambda-like environment starting to come up and those patterns that look like that. Yeah, yeah, makes sense, makes sense. Adrian, can you tie in, where do microservices fit into this whole discussion? You said I can put kind of everything in a container or I might have an application that's spanning between multiple containers, which boy, if I think about how my infrastructure works, that spawns a whole separate set of discussions, not the security, but if I have any data that I need to maintain, how does all that play out? Yeah, so microservices is really, it's a tactic for achieving a goal. And the goal is speeding up development with large teams. If you have a small team, you build a service. They can talk to each other, they can figure out who broke what.  And you need more and more time to test because you're trying to integrate all these things together. That's the point at which you break things into microservices. And microservices, they're less efficient. They use more memory, they use more CPU, you've got more things going on, they use more network, they're a little bit slower, but you're paying in the efficiency, you're trading off efficiency and cost for the ability to move faster. And the problem that most big companies have right now is they're moving too slowly. The problem isn't that they're spending a little bit more money on a particular service. The problem is that they are releasing a thing once a quarter and their competitors doing it 10 times a day. So in order to get to continuous delivery, you have to break it into chunks that are manageable. And microservices comes in as a way of separating the concerns so you can do that.  As people talk to you, they come up to you after a talk or you're out talking to clients and so forth, you guys went through a process of kind of matching the Netflix culture with a business need. When people come up to you and they say, look, you've got some experience doing this, like where should I start? Do you ever have a starting point that you point people to? Is it one service? Is it does certain company cultures fit away of starting a service? What's a, how do people get started down that path? Yeah, there's normally the best thing to do is there's a couple of good books, right? So if the whole discussion sounds like there's a bunch of aliens from another planet wandering around, then you really just start with a Phoenix project, right? Start with a novel about a company that is just can't figure out how to build software and it's going to go out of business or it's going to just lay off its entire IT department and it's a horror story, contains all the bad things that anyone has ever seen in production. So that book really sets out, okay, if this looks like your company, then here's some patterns and ideas and at least some hope that there's a way out. If you're a bit further down the road and you've got, you're just trying to look at how do these parts all fit together, then I think the Lean Enterprise book is the key one and I've been pushing that book for a long time. That's a hypothesis driven development, how to organize things. There's a lot of detail in that book on how enterprises are really going and moving into this new world, DevOps, Agile, and continuous delivery as ways that they work. And if you're already into that and you're trying to figure out, okay, so how does the microservices piece work, then Sam Newman's work on microservices is really detailed stuff, like how do you break a database into lots of little pieces? How do you think about building those bounded contexts to separate stuff? How do you reorganize teams? So that's much more hands-on. So those are kind of the three books that lead you, I think, through the onboarding process. Makes sense.  One of the big questions a lot of us have is, how's anybody going to make money on this stuff? If you're the center of an ecosystem that's growing at a ridiculous rate, you can kind of leave the making money to a little bit later.  So the interesting thing now is, how do the little companies around the edge of that ecosystem play with Docker? And it's tricky, right? So you've got to find a gap. You've got to figure out how to monetize it or maybe you're going to get, you know, as the ecosystem shifts, you could be flavor of the month, one month and be nothing the next month, right? Or, you know, Docker adds a feature. So it's a difficult and interesting area to navigate right now in its very formative stages. But, you know, the growth rates that Ben put up on his slides were just, you know, I tweeted that it went beyond ludicrous as plaid, I think. 18,000% growth in Docker, yeah. Okay, yeah, that's not a usual percentage to put on a graph, right? It's a ridiculously high growth rate. Once you've got those kind of growth rates, you know, it's more about trying to make sure you don't mess up the ecosystem. And I think the RunC getting the CoroS guys back on board, making sure that they don't split the ecosystem. They have everybody bought into it. I think they're making the right moves to keep this as a single ecosystem rather than having it fracture, which was kind of the worry six months ago around DockerCon Europe. So that's, I think that's a great sign of kind of the maturing that little ecosystem into something where everyone's bought into it and people's concerns are all being heard. They've got the foundation. So that is, I think, a really fundamental announcement. Monetizing it once you've got all this stuff set up is something that's going to come to them later. I mean, it took VMware a long time, I guess, to become a real money making machine, right? Absolutely, and VMware got acquired before they were making tons of money. So one of the questions I have, you're working with all these startups, the big companies are already here. If you look in the cloud space, I mean, IBM with BlueMix, AWS and Azure are here. Big storage companies here. The networking guys are all partnering with there. So is there room for kind of a small growth of startups to actually monetize and make some money? I mean, the open source, they can obviously contribute and add value. And we see lots of projects out there, but you know. Yeah, I think there's two sides to this. One is that the ecosystem is evolving so fast that once a big company gets involved, they can't move that fast, right?  If you get it right, and then there's just so many companies swarming it that some of them will get it right. So that's one side. The other thing is that we're seeing rapid adoption by enterprises, right? You have Capital One listed up there as a bank, right? There's a bank listed as a primary adopter of Docker technology. And I've spent some time with the Capital One folks and they are being very aggressive, right? So banks, there's a lot of money in banking, right? They have, when they start doing something, it's a big scale, it's big budget, they get support and they go and buy real technology to solve real problems. So I think that once you see those, what are traditionally the later adopter, high spending businesses moving to this kind of technology, yeah, there is money to be had if you have, if you solve a real problem. But there's going to be, the ecosystem's going to spread out. There's going to be more and more things around that ecosystem. So there's like security companies. How do you build security tooling and auditing and things like that around the Docker ecosystem? Just starting to see some pieces in that space. And there are some vendors here or some startups here that are trying to understand what's happening. I mean, you were talking about security today with microservices, Docker published best practices this week and VMware was making it kind of a big deal about security. I mean, is that the last big frontier technical hurdle for Docker to have mass adoption or are they already there and this is just the enterprise last hurdle? I don't know what the last, whether you'd say it's the last hurdle. It's evolving and each step, it gets bigger. So the adoption gets larger. People get more comfortable with it. People go, okay, I trust VM security. Five, 10 years ago, people didn't trust VM security. So okay, so they got to the point now where VMs are, they understand that it's secure. And then Docker's container security, they're not sure yet, right? After the talk, Brian Cantrell came up and he from Joints said, no, we have secure containers running on Joints. Okay, but most people don't trust container security at this point, but it's probably better than they think and it's going to evolve until it really is good enough and people will be happy with it. So I think that that's something where part of it is just, this is moving so fast that you got to socialize the ideas to a point where people kind of have good, enough good experiences and the patterns look good that people go, okay, I believe this now, right? So the technology is what the pieces have to be in place and then people have to get used to it and then it becomes receive wisdom and everyone gets comfortable and you move on to worrying about the next blocker. What's the next thing that you can't do? Yeah, I mean, one of the customers that they highlighted was the GSA. I mean, if the federal government and the GSA are going to take 10 massive applications and dockerize them, they're not going to do that if there's no security. So the discussion I had with Docker is they said there's the Docker trust model and it's really layers. So does that resonate with your thinking? Yeah, sure, and people weren't trusting public cloud and people weren't trusting and people that won't trust public cloud have like half their data in Salesforce are going, yeah, it's really, and nowadays they've got over that. So people are finally realizing that you can build secure applications in public cloud. And I think there was an interview I did recently where they said, what's the thing in the future that other people don't believe yet that might happen or one of those questions? But what I came up with was at some point in the future, the most secure way to build an application will be containerized on public cloud using very fine grain. You've got identity access management, you've got roles, you've got everything locked down. The only thing this piece of code can do is make this API call to here. That's all it's allowed. This is the way AWS Lambda works like this. So you've got an incredibly locked down application with an incredibly tightly integrated audit capability. That sounds like an amazingly secure way to build an app and if at some point that becomes the only way you can get certified to hold really secure data is to do that. All of that data that's currently sitting in data centers becomes the insecure because it's so easy to breach and get in there and rummage around and it's not really under any kind of detailed control and the auditing isn't really that detailed. It's not audited by design, it's audited by somebody filing a ticket. So once you get to the point where every API call that modifies your infrastructure is fully logged and audited and there is no other way to modify the infrastructure than making an API call. This is potential future world where the most secure way architectures are cloud containerized systems and audit and compliance people would be pushing people to do that because your data center has been breached another 10 times this month, right? To get out of that data center. But that's, I'd say that's controversial in some places but other people are going, yep, it's happening but it's, yeah, that's going to be a while before people get comfortable with that. Yeah, it's interesting, in our survey work talking about people about cloud if I haven't done a major initiative in the public cloud security is the reason I don't want to go there but once I've done it I realize that, you know it might be different than what I've done but it's probably better than what I was doing in house. There's two sides to that. One is security, the most jurisdiction, right? There's the ability to build something secure. I think it's undoubtedly you can do that in cloud. It's very clear. Jurisdictions are doing it. What laws apply to this thing I've built? And if you live, you know, the Germans for a long time are going, oh, we don't trust this public cloud thing. We'd have to put our machines in Dublin, but not sure. And then, you know, AWS opened Frankfurt and I actually visited Germany before and after that. Yeah, we're running in Frankfurt now. They turned up on our doorstep. Okay, this is a thing now, right? And the French are going, and the UK are going where's our clouds? Well, okay, there are some clouds there but you know, the big public clouds are gradually spreading their foot print out. And as your credit have done a very strong thing. I think that's driven largely by need to run things like Office 365 where they want those emails to stay in a certain country. So they're driven by their application portfolio. But I think that is the end game that you're going to see public clouds, small public clouds in every major market because of those jurisdiction issues. There are laws that say, you know, I know there's UK laws that says if you're spending government money you have to spend it in the UK. You couldn't spend it on something that happened somewhere else because that's a misuse of public funds, right? It's not to do with security as such but I think that though as this is all maturing this these things are starting to happen. So we all sit around sometimes as media watch how fast this changes and head spin. Vendors are trying to set strategy. As a VC, when you've got companies that are spinning up as quick as they are like how does your world change when these things go so quickly? Like how much are they leaning on you to help them with strategy? Or, you know, like what's a VC world change when everything gets faster? The fun part for me, I always wanted to know what was going to happen next, right? I originally, one of my first jobs I was a software engineer and we were buying sun machines and I wonder what sun machine was coming next and they wouldn't tell me. So I joined Sun partly so I could figure out what they were building next because you get about two or three years into the future of they were building this hardware that I got to find out about in advance. And one of the things I like about the VC world is I get people that haven't even left to start, you know, they're at some big company and they're thinking about forming a company and they've got ideas. Some of the most fun things we get is to get together with a group of people that haven't even got a name for their company that got a vague idea they want to build something. And, you know, every week or two we get together with that kind of thing and we're brainstorming a possible future company that, you know, if we do it right and we get the right connections in there then, you know, we get to fund this thing and it turns into an actual thing and, you know, helping them through that whole process is very rewarding.  I'm working, we have a new general partner I'm working with, Darmesh Thacker who came from Intel Capital and has done a lot of seed stage startups and early investor in Mirantis and places like that. So he is bringing a lot of real deep experience to the team that I'm working in now. We've only had him since February but we're working through some early stage deals and that's kind of my side of it. So Adrian, we're running out of time. Last question I have for you. If we've gone to plaid with how fast we're moving and you've got this huge ecosystem that's building, you know, can this ecosystem keep running so fast?  So a year from now, are we, you know, just an order of magnitude more or there's some kinks in the road? We're going to hit a road bump. You know, what do you think happens in the next year? I think that the, I think we kind of hit the road bump six months ago with the whole, you know, CoroS rocket, APSI, split off where when it, when Docker first happened it was from a non-threatening source. This tiny company I would heard from built this cool thing. Everyone went, oh great, that solves a problem. Let's adopt it.  How can we kind of get back a little bit of control here? And that's over the last six months, that's now worked out. So now there's a Linux foundation based entity. They've given the code into it. They're everyone signed into it. So they have to execute on that. I mean, they had, I think it's set up right. They've got the rough consensus working code. They figured out the right level of what should be in the foundation, what should be on top. So I think that they've kind of passed that road bump. They've now have just execute against what they've got set out. So this is really happening way faster than most similar kind of environment. Yeah, I'm tired of trying to talk. All right, well, Brian, I really appreciate you helping me out on this segment. Adrian, thanks so much for taking time out of your busy time at the show. We'll be right back with lots more coverage here from DockerCon right after that, this quick break. Thanks very much.