All right, looks like we're ready to go here. So you guys passed the first test and actually made it to ballroom B. That's a hike from the expo area for sure. Shed some of those barbecue pounds. So before I say who's who, I bet you guys can figure out who the dev ops and IT ops guy is on the stage here. So I'm Al Sadowski on the research director for our service provider channel. And Donnie here is from the obviously the development dev ops and IT group at 451. And we've got about 40 minutes, and we're going to take you through what we call the open stack pulse. So it's kind of our analysis of what we see around open stack. So he'll be back up in a little bit. So we have 15 different channels. And when we first started covering open stack a little over three years ago, it was really in the two channels that Donnie and I now represent. Because that was where all the business was, service providers and in the dev ops space. And then as the cloud marketplace guy started plugging in open stack, we started to see more in our cloud transformation space. And now pretty much every channel we represent has some sort of impact to open stack. And probably you can argue that all of these touch open stack in some way. So we publish an annual report called the open stack pulse. We've been doing it for three years now. We covered how the platform has evolved. We talk about timely topics. We've covered is containers a friend or a foe of open stack? And we'll go into that a little bit more. We talk about the different distros and the distro wars. A lot of enterprises are trying to figure out, OK, I'm going to distro route. Which one? We've been tracking the community growth and the overall market size. We keep tabs on the business models. We'll get into that a little bit. And we obviously speak to a lot of enterprises and get their insights on where they are with open stack and talk about their deployment stories. We have a big panel of enterprise end users. And we do surveys. And we have been increasingly asking a lot more questions about open stack as it's more interest. So I got two parts to the agenda here. We're going to start at kind of a high level. This is a bird's eye view here of Austin. So I'm going to talk about some of the trends that we're seeing in cloud in general. Talk about the market size of public cloud and private cloud. And then we'll swoop down a little more granular specific to open stack. And we're going to talk about open stack adoption. We'll get into details about the market size that we're tracking. Some of the pros and cons that we hear from enterprise are opinions. We have something called the cloud price index. And I'll share some insights that we've consolidated around that. And then Donny's going to come up and finish off talking about containers and paths and how they are related to open stack as well. So I'm going to start at the top. So I kind of like to start a lot of conversations that I have here because as much as most of the folks here are interested in cloud native apps and private cloud, the reality is that the majority of enterprises, over 50%, still have their internal infrastructure either doing virtualization, some automation. So as much as there's a lot of hype and discussion about private cloud and public cloud, the reality is the majority of enterprises are still trying to figure out these interim steps. And the reasons why they can't get to the next phase is typically not IT related. Whether it's open stack or a proprietary platform, it's typically not IT. I think one of the keynote folks earlier, Boris, kind of touched on this a little bit. And we are seeing that 58% of the reasons why an enterprise can't get to the next phase. So if they were doing virtualization, why they can't get to automation, or skip all the way to private cloud, is things like fear, uncertainty, and doubt, budget, prioritization, lack of skill set, or design is actually a big issue for a lot of enterprises. They just aren't equipped to support a cloud initiative. So non-IT, so for the service providers in the room, helping that enterprise on that journey also includes some of that org structure, skill set development, building processes that allow somebody to operate a cloud are probably more important than the mouse trap that you're gonna come and deploy there. When we talk about what the IT pain points are, there should be no surprises here. The stuff that's in green and light blue are moderate and significant impacts. Security, compliance, data sovereignty, these are the top of mind issues for enterprises as far as why they're not able to get to the next phase. So again, if you're an enterprise and the vendor or service provider is coming to pitch to you and they are not mentioning security and compliance and data sovereignty as part of their value prop, then look to others. Budget and cost is obviously a concern and I'll talk a little bit later about when a distro actually can be cheaper than doing something on your own. So one of the other things we collected in talking with enterprises is they're getting an idea of their overall IT budget. Now 29% is staffing, but you can see there that roughly 7% of the typical enterprise spend on cloud is 7%. But it's good news for folks here and probably not a surprise is that cloud services budget is actually growing. So this is 54% of enterprises saying year over year their budget is going to increase for cloud services. And when you talk about that cloud services budget, this is actually from a different study, not our own internal voice at the enterprise. This is something we did for a client, but 70% of that cloud budget, it's not just for servers and storage anymore. There's an entire suite of spend across managed services and application hosting and security services that they're increasingly looking to get from service providers, especially in that hosting and service provider space. Again, something to be aware of as we build up this story a little bit. The last bit of overall market sizing data in this high level view. So we track the overall size of the cloud and hosting market. This is through 2019. We get bottoms up estimates from a number of providers. And again, when I said earlier about the hype of public cloud, it's only about, or it's one sixth of the overall hosting market. I think again, the keynote this morning kind of showed the overall size. Infrastructure as service is growing a lot faster than the overall hosting market, but still in comparison, it's a lot smaller. And this is not meant to be a knock on OpenStack, but that red represents the overall size of the OpenStack market. Now, this is not apples to apples comparison. We're not including hardware like you would in hosting, but it just to give you a relative size that this is a small market overall, but clearly growing. In fact, the OpenStack service providers are growing faster than the overall service provider market. So this slide is gonna take a while to build, but as I go, I have a couple different things I like to point out. So I think everybody here knows that rack space and NASA started this thing as an alternative to AWS, but in our opinion, that OpenStack's future is not going to be in the public cloud. It's going to be in the private cloud. There are plenty of examples of private cloud providers out there. Some of them are regional, some of them are focused on specific verticals and they're finding success, but the days are over where somebody's gonna build a public cloud and say, we're competing with AWS. You know, when I've been an analyst for a little over three years now, I came from the telco space, and when I started and I talked to many, many service providers, they all said, we're like AWS. And then a year and a half later, it was like, we're not like AWS. And now they're all saying, we embrace AWS. So OpenStack's success going forward is going to be more on the private side. So that's the point, that was year one. So year two, what I like to do when I stop here is this is where, you can see that very faint blue over Diablo, that's the start of the tracking of a community for OpenStack. What I like to point out here about CERN is we talk to a lot of people in the investment community, a lot of enterprise, and they have concerns and questions about OpenStack, and they talk about scalability. And what I point out is, look at an organization like CERN, I saw Tim Bell on the hallway today, 165,000 cores now running on OpenStack, and they're not even the biggest. eBay and PayPal and Walmart are at least or bigger than them, you heard from AT&T talk about NFV today. The next year, and I think this was a very pivotal year for OpenStack, they created Rackspace and others decided to create the foundation, the OpenStack foundation. And my opinion is that if Citrix would have created something similar around CloudStack, we'd be at the CloudStack Summit, not the OpenStack Summit. It gave OpenStack an opportunity for other companies to help invest in OpenStack, build the community up, and have a lot more investment and marketing background. Around that cactus Diablo time was my first exposure to OpenStack. I was at Global Crossing, had CloudStrategy, we were looking for a partner, we went down to San Antonio. At the time, it was not ready for a service provider to build a multi-tenant public cloud with, so we went, looked elsewhere. 2013 was when they first went international, they had a Hong Kong Summit, and people should not be, there's a t-shirt over here, people should not be, should think about some of these organizations in China. Some of the biggest companies in the world are all based there, and there's a lot of momentum with OpenStack in China. I think two of the top 10 cities now for developers are Shanghai and Beijing. And then this is the rest through Liberty as far as the size of the community. I heard today that it might now be over 50,000 members in the community, and I say a good test of success is when you have logos that your kids can recognize, and there's a lot of them here. These were the, this is not necessarily an exhaustive list, but these were the ones I've seen be highlighted at the OpenStack summits, so for the Mataka release, for example, the first logo that I'm gonna be adding is a Volkswagen. But you can see there's plenty of momentum here. All right, so this is a picture of Texas Motor Speedway, and the reason that I put this here is that one of the best things that NASCAR has going for it is these cars racing around the track with these advertising logos all over it and people watching for hours as their favorite ones go around, and some of the most loyal brand folks are people who are attached to NASCAR. I think everybody who likes Jimmy Johnson is gonna go buy their home improvement stuff from Lowe's. And what I did was here was kinda show the number of supporting organizations over time from Austin to Liberty now over 500 orgs, and this is not the number one, but it is consistently referenced by every single enterprise as one of the reasons for interest in OpenStack is because of the major IT vendors that are backing the company. And major IT vendors, competitors, see their competitors doing it, so they wanna be involved. So it's got a snowball effect to it. But again, what I said before, if CloudStack had done something similar, we might not have seen this. So this is one of the best things for OpenStack is this marketing capability based on having these financial supporters. And you name the major IT vendor with over a billion in revenue, they're pretty much represented here at OpenStack nowadays. Except for Microsoft, but maybe within the next year or so. So we have this voice of the enterprise panel and we have a number of enterprises across the globe that answer our surveys. And this was our software defined infrastructure survey that we just finished in the fourth quarter. And we asked organizations where they were with their implementation of OpenStack. Now these figures are not exactly what was shared this morning by the foundation as far as their survey, but we see that 18% are in use and another 12 and 11, whatever that equals, 25% are either doing pilots or planning to, 58% no plans. So I think the survey takes a different path to how they come up with their numbers and that's fine. But from our enterprise perspective, their 18% are doing stuff in something other than a pilot. And just to put this into perspective and that OpenStack number across the bottom is the same numbers as the previous page, but just to give you a perspective of overall server virtualization. Very different story where 88% in use, only 5% not planning to do it. So again, the majority of people are still trying to figure out virtualization and are not ready to adopt OpenStack to do something like private cloud, for example. So again, I just wanted to provide that balance. We're not an OpenStack fanboy. We're not saying it has no pulse. We're just trying to keep a balanced view of what OpenStack is. So further good news for OpenStack. So this is the overall spend discussion. So we saw that picture of the overall spend and it showed that 6.9% of enterprise were planning to increase their cloud spend. They are either going to, 60% are gonna keep the same budget for OpenStack and 40% are actually going to increase their spend with OpenStack. So this is a good news story for the folks that are deploying. One, they're either happy with what they got. Maybe they found it a little complex so they're staying there and another 40% figure, you know what? What we're doing is pretty good and we're gonna add to it. So where are they buying from? So that you got options. You can go get a distro. You can talk to a service provider and get managed services. You can do it yourself. Things that might fall into other are a converged hardware platform. It could be a SaaS-based management platform that now exists, so when we ask them where are you going to consume OpenStack from, the distros is typically what we are hearing, 38%. I know in the past there were some discussions about is the distro dead and according to the enterprise that we're talking to, that is the favorable thing. Initially they were going the DIY route. They were kicking the tires. They figured this thing is worth investing in but they want indemnity. They want support. So now they're looking for the distros to provide that. So if you're in Austin and you're shopping for cowboy boots, there's a ton of different options, colors, textures, manufacturers, et cetera that you can choose from and when enterprises are looking at OpenStack as far as their decision criteria for who they're gonna pick, price obviously. Long-term support. Enterprises wanna deal with companies that are gonna be around for a while. There's a couple of, my first summit was the Portland Summit for Grizzly and there were some vendors that were well known at that point that are not here anymore. They've either went out of business or were acquired. So it's an important decision criteria for an enterprise. They wanna make sure that the choice they make is going to be there for a long period of time. Existing relationships is a big deal. If you're already dealing with a major SI and they're your partner, chances are you're going to go build a private cloud using an SI. If you are using one of the major Linux distros and they happen to also be doing OpenStack, chances are you're going to be talking to them about OpenStack. If you're using a proprietary virtualization software, they also have an option for you to make the journey to OpenStack with them as well. Reputation to community is a big deal as well. They like to know that those vendors are involved so that's why a lot of these vendors like to say they're the third, fourth, fifth ranked code contributor and things like that, it's something that a lot of enterprises look at when they're making a purchase decision. So the next area I'm gonna focus, I'm gonna move over to our market sizing data. It's something we've been doing for a while. So we have this OpenStack market monitor. We get bottoms up estimates from a number of vendors. We have over 60 now that we include in our estimate. So I'm gonna talk about what's in scope as important as what's not. So service providers that are using OpenStack for the core of the service. All the consulting, the development services, the distros, training services, all of that is included. And if they have a product, even if it's hardware-based that was purpose-built for OpenStack, that is included. What's not, if you're a generic hardware provider, so you're building servers or storage or networking hardware, we don't include that in our numbers. That's why that number looks small in comparison to the overall hosting market, because we don't include the hardware. And PayPal and eBay, they're using OpenStack to run their businesses, but we're not including their revenue in this as well. So in that market sizing, there's really three major buckets. There's the service providers, there's the cloud management platforms, and then there's the products, distros, and management, and you can see the further breakdown of there. For the first time this year, we actually split out public versus private based on feedback from some of the folks that are involved with OpenStack. And then the distros is probably the fastest growing area. So this is our market sizing. So 2015 was the first time that it exceeded a billion, and we expect by 2018 that it's 3.3 billion growing at a 31% cager. So again, in comparison, it looks small, but it's still a healthy growth rate in comparison to the overall market. Nearly 80% of that number is service providers, and there's one major service provider that is the majority of that, but that share goes down by 2019 to 75%. And that's a good story. It's the fact that there's more contributions to the overall market. The most growth, as I mentioned, is coming from the distro area. And right now the mix of service providers between public and private, 56% public cloud, 44% private cloud, and over time that mix is actually going to tilt more towards the private cloud. Our research shows that the majority of enterprise spend is more on the private side than the public side. So now I'm gonna pivot over to pricing. We put together an RFP. Now you can shoot holes in the requirements that we came up with, but what we came up with was an RFP. We sent it out to over 40 different service providers, distro providers, and asked them to basically give us a price. So it was the space, the power, all the hardware to build the private cloud. They could pick the hypervisor. It needed all these orchestration requirements to run 500 virtual machines. We said they're running all the time and you pick the premium operating system that you wanted, we wanted everybody to respond. So based on that, we got a range of responses. And what I'm gonna go through is a specific comparison about DIY versus distro. Now you would expect that if you had the same number of engineers and you had the same software and infrastructure, that a distro obviously is gonna be more expensive. Makes sense because you're paying for a license fee. However, what our research shows is that if you can save 45% of your engineering costs, the distro actually turns out to be a better total cost of ownership for you. And the issue is open stack developers are very expensive. In some cases, double the cost of something comparable. So distro can be cheaper than DIY. The other thing I'm gonna compare is when managed services can be cheaper than self-managed. Now you would expect that managed services is typically going to be more expensive than if you were running open stack and had the software and infrastructure on your own. Okay, but what we found out is that if you have a tipping point somewhere where 100 virtual machines are managed by an engineer, it's actually a better value at that point to do managed services. Now when we collected managed services responses, the smallest to the highest, there was a 14x difference between those. The most expensive came from a couple of SIs. We don't give out specific vendor information, but the SIs were higher. But in general, that if you needed more than one engineer for every 100 virtual machines, managed services was actually a cheaper route to go. Donnie is up next. And Donnie's gonna go through a couple slides here and talk about containers, paths, as it's related to open stack, and I'll be back. All right, thanks, Al. So for those of you who arrived late, I'm Donnie Burkhold, so I lead the Development DevOps and ITOps channel. And yes, hence my camouflage helps me fit in at the bars. So I'm gonna talk through a bunch of stuff around container adoption, both in general, but also specifically within the open stack community, and then talk a little bit about what people are doing with those containers, right? In terms of workloads and things a little bit more complex than a single container, because we can't build an application with one container anymore. So to kick this off, Al talked a little bit about our private cloud index and about the ratio of VMs to engineers and the comparable price points for private cloud, for proprietary clouds versus for open stack. And some of the numbers he talked about make a lot of sense for enterprises. The difference, I think, comes in when we start talking about the ratio of VM to engineer that we're seeing in some of the huge clouds, whether private or public cloud providers. And some of the numbers that I hear range up to things like 10,000 VMs per SRE out there. So when you start thinking about the cost point, you can imagine, once you get to that kind of number, the salary per VM becomes incredibly small and other things become much more important factors. And as we move toward more and more distributed applications, more and more containerization for these apps, we'll start to see more people, I think, moving toward ratios along those lines because you have to have a lot more automation. You can't be doing the sort of manual maintenance anymore once you get to container scale, microservices scale, or things along the lines of serverless scale. So first I just wanted to show you a little bit of info that's not from our service. One of the things I really like to do is go out there and look at developer traction for things on all these different forums. One of them that you're probably familiar with is called Stack Overflow. And if you go out there and you look at the number of tagged questions per month for a lot of different container technologies, you can get a really good sense of how important Docker has been to container adoption as a whole. That blue line there is Docker. The green one happens to be Kubernetes. And so we're talking here about containers at the Docker level. But then container orchestration and management is where we start getting into things like Kubernetes. And once you start scaling containers, once you start automating containers, it becomes really important to have some kind of layer on top that helps you deal with all of that. And we've seen Kubernetes start to become the standard there, at least in terms of developer interest. In terms of corporate interest, it's a lot harder to get a good sense on that right now. But that's one of the things that we're going out and doing in our service is asking enterprises, what are they using? Are they using Kubernetes? Are they using Meso? Are they using Swarm? Are they using something else? And all of the other lines on there, frankly, don't matter, because they're all basically zero compared to the two I mentioned. But one of the questions that I was very curious about is, it's great to have developer interest. And the question is, are containers really getting out there in the enterprise? And so we went out there, asked about 1,000 people in one of our cloud surveys, got some very interesting responses in terms of where things were. We've run this survey twice now. In the first one, we saw some pretty interesting levels of interest. And I'm showing you the darker colors there are quarter three last year. The lighter colors are quarter one of last year. And over the course of two quarters, we saw production deployments double from, if you look at the initial plus the broad numbers there, from a little over 6% to over 14%. So it's not just developers who are interested in this stuff. It's enterprises who are picking it up and picking it up very quickly. And if you couple that in with people using containers in some kind of dev test point right now, you see surprisingly in our large numbers of enterprises who have picked this stuff up already. Considering Docker is just over, I think, three years since it was open source at this point. Did I make you miss your picture? Should we go back? We can go back later. And so I want to dig in a little bit deeper, get closer to OpenStack, closer to how these things are being used in a cloud environment. And the numbers are a little bit smaller on this, because if you have 1,000 people taking the survey and you start slicing by container use and you start slicing by OpenStack, only you're down around a couple hundred. But they are still big enough that I think they produce some interesting data points, especially when you're talking about large differences. If you start talking about small differences with small numbers, I don't really believe that. But once you have large differences with smaller numbers, that can work. And so what we're seeing is that container use today is primarily used in private cloud, which I found very surprising. But when you think about who we're surveying, it's enterprises. It's not just a bunch of Bay Area startups picking up this stuff and throwing it in their public cloud of choice. It's people who need to use this for business workloads. And today, they're putting it mostly on-prem. But as more and more people expect to pick up containers over the next couple of years, that's going to change. They're going to be putting it at all kinds of different venues, depending on the workload, depending on the application, and depending on the portability requirements they have. A lot of people are going to want something on private cloud. They'll also want it in a hosted private. They may also want it in public. And they're going to be picking up containers in all of these places. Now, in terms of what they're doing with the containers, I think this is probably the most important question. And I tied back to thinking about OpenStack a number of years ago, where people would go out there and they'd install an OpenStack cloud, and they'd say, now what? I've got compute. That's cool. But somebody sold it to me, and I'm not really sure what to actually do with this thing out of the habit. And so containers have been at that point. And we wanted to learn a little bit more about what people are doing with them. And you can see that the top five workloads I showed here, they're mostly infrastructure workloads, apt of technical computing, which would be things like genomic sequencing, for example, is a really good use case for containers because it's small things quickly piecing together, chunks of DNA, scaling up and down as required. And web servers, right? Nothing really surprising there. Now, containers in the OpenStack universe is something that I really want to spend some time talking about because I think, presumably, this is why you're interested in containers, right? Because how are they relevant to OpenStack? And so when we go out there, I want to compare this to containers in the wild as a whole, if you will. And so if you take a look at containers as a whole out there, we surveyed about 500 people for this one, you can see pretty similar numbers, right? Production workloads around 15%, right? The last one was 14%. This one is 16 and 1 half. It's a slightly different audience we asked. But so you can see productions about 15%. If you start adding in pilots and DevTest use cases, you end up around 35% total of the enterprises that have at least started playing with containers at this point. Now, if we slice that down to just the OpenStack people, we see something very interesting. Take a look at that light orange graph on the very top there. There are tons of OpenStack using enterprises who are using containers in production today. In fact, over half of them, which I found shocking. It doesn't mean they're using them in their OpenStack cloud, but it does mean they're using them somewhere. In fact, chances are they're not using them in OpenStack right now. They're probably using a container service or something else because what we see in general is that companies, unsurprisingly, they have a technology adoption stance. And they tend to be early adopters or late adopters or somewhere in the middle. And people who have installed their own OpenStack clouds are pretty likely to be fairly early adopters at this point. And so they also pick up other new technologies like containers as soon as they see a business use case for them. Now, like I said, the number of people we're able to slice down to for OpenStack was pretty small. We only had about 80 people on that one. But the size of that difference is so dramatic that I tend to put more faith in it than I might otherwise. Now, one of the things that I've always wondered about is how are people using these relative to VMs? I had always kind of assumed that everybody just stuck a container inside of a VM because they wanted more security, more isolation. And so we wanted to get out there and ask, what are you doing with them? And it came down to three main alternatives, right? Are you running them inside the VM? Are you replacing VMs with them? Or are you creating new workloads that run in containers rather than VMs? And I saw this really interesting split where it's not at all the majority of people who are running them in the VMs. It's the most common style, the most common approach. But the majority of them are actually using them either instead of a VM or separately from a VM in some other way. Now, if we break that down to OpenStack, we again see the numbers are larger, but this is just because there's more people using containers. The pattern is exactly the same, right? If you take a look at the pattern, you see the biggest one running it on top of a VM and then a little bit lower as separately or replacing VMs with them. Now, the last thing I wanna talk about is, again, what are people doing with containers, right? You have to, if you're building applications that are sort of cloud native or what have you, you have to be able to do something with these containers to have a good way to manage them. And I'm seeing two different approaches starting to emerge. One of them is a very unopinionated approach built on top of things like Kubernetes and Mesos. And the other one is a very opinionated approach, right, what we used to call and still occasionally call Paz, right? Whether it's a platform as a service or some other kind of more opinionated framework that doesn't give you quite as much flexibility. And I showed you earlier that we're seeing about 15% of these enterprises who are using containers in prod. And the question is, so are you using orchestration? Cause if you're not using container orchestration, I contend that you're not really using containers properly, right, cause you're still doing the manual management stuff that you were doing with VMs and logging in by hand and running top as you're monitoring the solution. And what we saw surprisingly was only about two thirds of the people who are running containers in prod are using container orchestration, all right? The other people are still thinking about it in sort of the pet side of that pets versus cattle metaphor, which I found, again, really surprising. I thought that basically everybody who had managed to put this stuff in prod would have to have some way to deal with it. But it turns out that's not the case. And so that's kind of the unopinionated platform side of things, right, people who are building up these platforms themselves from scratch. Now on the opinionated side, we've also gone out and asked this question, what are you using in terms of your on-prem Paz? Where are you in terms of your adoption cycle of it? And then broke it down OpenStack and everybody. And you can see that as a whole, so this is everybody, not just OpenStack users, the private Paz is surprisingly popular. There's a lot of people who have rolled out some kind of a platform as a service on-prem. But there's even more who have done it among OpenStack users, all right? It's a really significant 20% difference there. Like I said, the audience is small, but I tend to believe a difference that large. Whereas some of those other numbers I'm not really sure about, like planning to implement in the next 12 months, the next 24 months, whatever. Somehow those plans all seem to fall apart when they encounter reality. And so that's what I wanted to talk about today in terms of container adoption as a whole increasing very quickly. And we see unopinionated frameworks, right? Like Mizzos and Kubernetes starting to grow more and more in popularity and expect to see a lot of that over the next couple of years. With that, I'll pass it back to Al. All right, so we're gonna wrap this up. So if you're late, you still are able to get some benefit here, because what I'm gonna cover is just kind of summarizing some of the things we talked about. So we're now just gonna really just focus in on the reasons why enterprises are drawn to OpenStack. Vendor lock-in is something that they consistently reference. People do not want to continuously talk about these proprietary platforms. They like technology. You guys all know about how it works. There's no central piece to it. It's all modular. They like that part. Open source. Again, enterprises are increasingly having this mandate about open source. We had an event in London a couple of weeks ago and two agencies of the British government were there and both of them talked about a mandate for open source and that they're evaluating OpenStack and pilots right now for an internal private cloud. I showed before the pricing analysis that indicated that there is some savings when you consider a distribution versus DIY. People seem to think open source is going to be cheaper. There's examples where it's actually not, but the cost of an OpenStack developer is one of the key expenses there. We talked about that NASCAR slide, but the fact that there's these major IT vendors back in the community is consistently referenced as a reason why enterprises are drawn to this community. The fact that you're not locked into just one specific hypervisor is a big deal. You have a lot of choices out there. And as far as the telcos are concerned, they're very drawn to this NFV capability based on OpenStack. You heard it today. You heard it from a lot of other telcos in the past as well, but for all the excitement there is around OpenStack, there is also some cautions as well. Our research shows that the SMB community is really not as interested in OpenStack as mid-size and large enterprise. And a lot of the reason is they just don't have the resources internally to do it. And oftentimes at SMB, they're likely going to deploy a SaaS solution because they just don't have the IT staff to go and build something, maintain it. If you're comparing it to the biggest proprietary platform out there for doing support for production workloads, it doesn't compare as far as the reliability resiliency again, this is something that is evolving over time. When we first started talking to a lot of folks about OpenStack, they thought you can go to Staples or Home Depot and buy it off the shelf. It's a shrink wrap box that says OpenStack on it. They thought it was a product. It's really a toolkit. People have taken some of those tools and built products. But again, that's the mindset for some enterprises still. And fragmentation is still a concern. I've said in the past that, hey, we might still be in the Unix stage. And one of these vendors out there is gonna take the Linux version of OpenStack and run. The governance of OpenStack may prevent something like that happens, but it's still a possibility. And everybody's aware of the complexity of OpenStack. There are thousands of configurable items across all the different projects to build a private cloud. It's complex to deploy. And then the limited supply of developers. I talked to a college class one time and I told them, go learn OpenStack and move to the Bay Area. You can make a lot of money. And that's probably still the case. And so I'll just leave you with some summary thoughts. Again, if you're late, this kind of just summarizes that enterprises, they prefer private to public cloud. Regardless of what they're gonna deploy, security is a key thing. So again, if you're a service provider, your first or second slide of your pitch deck, better talk about security because it's the number one reason why an enterprise has not moved to the next phase. While OpenStack has a lot of mindshare, the wallet share hasn't caught up, but we showed before that it is growing faster than the overall market. There's plenty of issues with the toolkit, but a lot of those issues are being addressed in overtime.  So it's developing. I showed you before how distro, total cost of ownership is actually a better value prop if you can save on headcount. And existing relationships is going to be key for how you decide on a vendor.  As Donnie just talked about, containers has a higher adoption in the OpenStack area and these unopinionated container orchestration ideas is increasing as well. So that was a lot of information we threw at you. That was our balanced and fair review of OpenStack. Thank you for making it all the way from the other side of building over here today. We appreciate your time. Thank you.


In the context of community forestry, there is a lot of attention for good governance and equitable beneficiary. But who actually decides what is fair and what is the role of civil society in supporting community governance processes? My name is Margie de Graaf. I work at Tropenbos International and I would hereby like to invite you to join us at the Landau conference where we are organizing a session together with RECOFT and Forest Foundation Philippines. In the session, we will answer these questions based on experiences from the Philippines and Nepal. I hope to see you there.


In 662, Bishop Sauris Seibacht, living in Kineshra on the Euphrates River, now in Syria, chided his colleagues for being too enamored of the accomplishments of the Greeks. He pointed to the discoveries made by Indian astronomers using their nine signs for numerals. This is one of the earliest references to what we now call the Hindu-Arabic numerals. So here's a quick review. In additive notation, the value of a symbol is fixed and the value of a number is the sum of the symbols present. Egyptian hieroglyphic, Greek numerals, and Roman numerals are additive. In a positional notation, the value of a symbol depends on where it is written. Mesopotamian notation is positional. A symbol might represent 1 or 60. One problem with positional numeration occurs when an order of magnitude is absent. The Mesopotamian symbol for 1 could mean 1 or 60. The problem was solved in various ways. The Mesopotamians didn't bother. The value of a number should always be read in context. The Chinese rod numerals altered the orientation. So 333 will be written with the 3s oriented differently to indicate they were indifferent but adjacent orders of magnitude. And the Chinese written numerals explicitly indicated the orders of magnitude 300, 310s, and 3. And these all represented one solution to the problem of magnitude. But sometime in the 8th century, maybe, someone in India, probably, invented a symbol representing the absence of an order of magnitude, the zero symbol. The symbols underwent a long evolution. The earliest forms of 1, 2, and 3, which we see in India, in China, and many other places, were 1, 2, and 3 marks, which could also be written vertically. However, if you're not careful to separate the lines or if your pen drips ink, you form ligatures that adjoin adjacent symbols. And so the vertical marks of 2 and 3 began to look a lot like our modern symbols. And here's a bit of irony. The new numerals entered Europe mostly through Spain and southern Italy. This meant they were introduced to Europe by those in the western half of the Islamic world. But this area was the cultural backwater of the Islamic world, and the cultural center was in the east. And the numerals had a different form in the eastern half of the Islamic world. Which meant that, by and large, the Arabs weren't using Arabic numerals. Now the open circle is probably the most natural way to represent an absence. It's a whole or a void, sunya, in Sanskrit. When the Arabs got ahold of this, they called it their own word for empty, sifer. This became transliterated by Europeans as cipher, then progressively mangled as words like sifer, sifer, and eventually zero. Now an interesting thing happens when the Hindu-Arabic numeral system gets translated into Europe. The Indians wrote the numbers starting with the lowest order of magnitude. So 3,257 would be 7 ones, 5 tens, 2 hundreds, 3 thousands. Islamic mathematicians followed the same pattern. But since Arabic is written from right to left, this put the smallest order of magnitude on the right. So this 7 ones, 5 tens, 2 hundreds, 3 thousand would be written this way. European translators read this as a single symbol, so they retained the order. However, since European languages are written left to right, this meant we see the highest order of magnitude first as we read our numbers. Now, Algarizmi wrote a book on Hindu reckoning. Unfortunately, it's been lost and we only have translations made centuries after he wrote it, so we don't know exactly how he described these Hindu numbers. However, his work proved influential enough so that the steps for computing with the new numerals came to be known as algorithms, after Algarizmi, and books describing the procedures were called algorithms. And at this point, European translators penchant for fanciful stories got the better of them. At least one European writer claimed that the name came from Algor, a king of India. No, not him. Now, because the Hindu Arabic numerals are how we write numbers today, and how we compute with them, you might expect that these algorithms for working with these numbers resemble pretty much our own algorithms. And that's true in the most general sense of the word true, while we can find our algorithms in these more ancient works. It's worth pointing out that in the early stages of any technology, there's a number of different solutions to the same problem. And it's only over time that one preferred solution emerges. So let's take a look at some of those algorithms.


OK, so we've got everyone here, which is a static analyzer. You speak up a little bit. And we speak up a little bit. There we go. So why are we in the room today is because programming is hard. Actually, it's pretty hard. And it's a new program. And you want to write very, very much as possible. You need to write all the popular cases in the work case. You need to keep track in your head of the possible values that this function can be called in or that it can close through your program from the user. If something had been out of your program, it will be out someday for someone, and your program will crash. And you ship books to your users, and you want to pay. And sometimes you need to take a deep step to create other books, because it's a great way to add services. So what do we do to embed that in engineering? Well, we try to do that code. So we develop pretty practices. We add tests, try to architecture the code in a way that minimizes the likes of the boundaries. We add more tests. And then you can sort of read the language that has more or less your opinions and your pitfalls. Because your language will not value a lot of text, you know? Or if you have a new menu to make files, for instance, you just try this one so that you don't forget both the files. On your language, you can have more or less which fixes them through the both of the random issues. Although you can always choose your language. There's tons of other in there. Showing your real work is a real good business and making sense of that in your life. Or you have to pick a particular language to use a particular language. So this talk I'm going to be talking about now is this. And it's just one additional way to give signal to developers that the code is going to go and doesn't have too many bugs. So in contrast to testing, Staticam is the way our company ever represents. Attempts to check all programs as and all values at the same time and make sure that the program works in any case. And you can also think of it sometimes and pilot it from key language features. For instance, if your language, for some reason, decided that all objects could be now and there's no reason to test at runtime, then Staticam is just the way to make sure that things are not at the point where you take them. So I think there is such an item either. We can come up and look at it. It's an item that is Java. And C family of languages, C, Objective C. And we have the C++ support here. And the main characteristics are it's inter-procedural. So if we try to pull the values from functions to functions and across translation units to find inconsistency in the code, something can be deep inside the function code and you can deep inside another function code. And the other characteristic I want to stress is that it's incremental. So it's very fast analyzing code changes. And that's very well done for those of you who use it. It varies on GitHub, using among stars. This is from back when we were going to do it there. People at the time seemed to like it. Since then, we've opened collaborations with other companies. So it's not just only a big book. It's a pedophile, a viewer, a follower, and more and more. And if you want to use it, for instance, in the website and your socials, you can get started on your code base. Or you can even try it on your browser if you want to quickly test some functionality. This is for an older version of it. It's a good, good idea for what you can do for Java. So that's it for this protection. Now we start with a quick demo. So this is a tiny project. It's a bunch of C files, and the Mac files that make, compile the files. And if I want to run in for this, first, I'm going to make in code in for. We just get, we use your first build command that's used for your project in for. And then we hijack the compiler and the computation. And then the computation. The build is done. To fill out what it needs to build, and then we hijack the compile calls to read the supply itself and analyze them. So here we see that it's detected by make mode. This is make talking. Then it compiles, compiling the files. And then once these are captured on this page, then the analysis starts. And here we find the three issues. And one is not the reference, so it's not here. So it's a point above, which I got here. The reference here, and here we go. It's going to be in the memory. So this one, we can stand straight away. And we declare a number in there, and with the reference it. And so we're running out of this. So we can explore the report. Here's another tool that she's using. Are you sure? Of course. Will you try to keep the terminal up at the bottom? Do you think so? We try. So yeah, it is big trace. Which you can withdraw. It's informative, but let's do it in Emax instead. So here it repeats the back. But then we see the actual symbolic trace. So these are the steps of symbolic execution that you got forward to take on the mission. So it says, oh, I entered in this other procedure. And if you go inside, it's in another file. And it's not also made a connection with the tool. And so you call this procedure, which was lab. There are these issues here. And then here you get to here. And the trace says, condition is false. So p not equal to null is false. So at this point, we know p is equal to null. And when we return p, we get out the function. And now what that means is that bug is null here. And then we get into get age, which is, again, another five. And what we see in this procedure is just a reference point. There you go here. Not the reference. So what we're going to do to fix this is that it doesn't affect. And then we're going to rerun in here. And if I rerun make here, what you expect is that only file that I changed will be compiled. So you can tell him for this. You can tell him for exactly that. It has to capture some reactive change. It has to react to a change that I'm doing in fluid analysis. So we've not discovered what it captured before. It was not like before. We just capture whatever is new. So here just person.c. And reanalyze just that file here. And then the file that you can omit. So here, in particular, I realize bug.c. Because it depends on person.c. And so now you see that there is one for bug.c. here. Because we're reanalyzing all things that depend on a change. So then the memory age is a, which should be easy to fix. We don't need to get a trace for that. So here we get real jbub. And we get some filbub. That's the end of what we still like. And we haven't freed it. So what we need is, we need to remember the age of what somewhere to run again. I only get my issues. I don't believe the real issues. Okay, so this is a quick game. So what we can do here was very simple my project. But again, very practiced and very hard projects. And this is the ordinary of this system. And the kind of things that we find, we go over quickly there on the website. And there's more explanation there. But briefly, for cc-class test, there's another front memory leaks and resource leaks. So if you open it back and you forget to close by descriptor, I think it is. So very, very important. For C++, it doesn't quite do the Raybound checks yet. That's the hard problem in stake analysis. So we haven't quite come up with something happy with it. But what it can check is, which is the pattern happens sometimes is the vector is actually empty and you try to access an element. So this is the object. This is also the text. It can be a very different note than I wanted to make. And I don't know for things. We do Objective C because we run on that for iOS. So there, the only thing I mentioned is that we infer the text with the cycles. With our cycles in the memory that you see the single counts in the arbitrary top bubble. This is an example of things that static analysis can have with issue language assumptions like this. And for that, there's no, there's a GC so we don't care about memory leaks. But we can have another reference on resource leaks. There's a tank analysis between two dots. There's, that's an interesting difference in game for some engineers to do that. So this is something where you can annotate some methods as performance critical in your code. For instance, things that run on the UI thread in the beta. And you can annotate other methods as expensive. And then infer, we check for you that there's never a co-chain from a performance critical method to an expensive one. You can see the website. We have also some Android specific checks that you can paste this and quite likely thank you. So I mentioned that this was just a type project. For instance, we run on Vector Go, which is the app for this Vector Go browser search engine. So here's an example bug. So the record by info was there's a resource you acquired a line through and it's never released. Some other line. What I mean in the code here is we had updated the resource here by doing this TV query. And here there's an if branch. And in that if branch you can return for the function before you put those. And so here you did the first one. So that's that. Another example. So here what do we have? It says that this field object here from this nested method code can be done. And then it's the reference. Let's see it goes into the function, which inside initiates things to now. Then it does a TV query. At this point the cursor can be empty. And so we don't ever enter the branch. And we get the final way. We close it and we return out, which we never changed from the beginning. So we just did none. So here the end of the space field object is none at this point. And we go inside this color function and info when you analyze it so that's one of the things it does is it references the form. Okay, you got that. Okay, that's it for now. So I will just say a little bit about how it works. Not going into the details, the various phases of the inference. So let's help you understand how to use it. And then I will tell you a little story of how we use Facebook. So the architecture is like this. So this is your program. It's a bunch of source files and the build system that knows how to define them. And these are the things that are very important. And so the first thing is it goes through the format which knows how to drive the build system to get to the source files and translates the source files from all these languages into a common, very simple, intended language also. Which is basically the go-to-lose and load-for and assignment. And then once it's captured all the lines in your project, it starts the analysis. And so for each procedure that is found in the source file it will produce summaries. It has some points to produce. It will attempt to prove that the procedure has no bounds. At some points it will not manage to prove that and at that point it will decide whether to report that as a variable. So then taking it to the first step, the capture. So here's a simple tab out class. Let's look at this method. Compute something. So it does the flip as a logarithm if you don't like that note or something. And right then we translate this method as a simple control program. So here you see you cannot read it. But what you can see is you can see the two E-branches and these are the instructions in the instructions just assigning a string. And then at the end both branches join to the exit note. So that's it for capture. It does that for all the source files and then we translate each procedure as something like this. And then the analysis runs on those smoothies or PhDs. And what it attempts to do is it attempts to understand two specifications for them. So what do I mean by that? So for instance this method it will discover that if the parameter exposes then it will run something and it is true you've written it now. And so the state before the procedure is called the pre-condition and we say afterwards it's the pre-condition and together they perform a specification of the function. So if you start with this pre-condition and you return the function then you will be done with the pre-condition. And so for this function there are two specs. And then if we look at the other method it calls the first one. The order is of interest then tries to compute the rest of them. And if we're smart enough to see that this function depends on the other one it will or if it hasn't already when analyzing this method it will realize that you need to first compute the specs for the other one. So at that point in the method it will have these two specs for the coding. And we call compute something of truth so if we look we expect to make sense of that and only this one makes sense. So when you call that function with truth you know that it returns now. So at this point you know that this is now and the next line it can use because of zero-prancing. And that's it for how info works in its main mode of operation. I want to briefly talk about two of the mode of operations. One is eradicate. So in Java Objects can be known and if you wish it once so you can use eradicates so with eradicates you can annotate objects that can actually know with ad-mobile and everything else will be assumed to be known. And what the eradicate does is it will check that the local base is consistently annotated in the fashion and what that means is and whenever you're there for something that was marked no then you better check from before and eradicate with the other two. And so if you do your local base like this in theory you should have no render and no render exceptions. So it's my good type system top of Java rather than the main mode of info which tries to really try balance. Another mode is for the client side of info we have linters which are simple simple check which are just syntactic and walking over the AC and looking at the nodes what's interesting is you can write your own checkers easily either inside infer you can add an infer to a node or a camel or you can even use a simple DSL we have and wanted to show what one of these checkers can look like so this is a checker ranking of XC and the property with a point type should not be the same what I'm talking about and so the checker for that is just destruct that's a mental report but message to report and the checker triggers and so mental report is easily expressed on here if this is a sign property then it's a pointer type and if I decide an objective C project like all then I can report so you can write a point range of checkers okay so now I open this I'm very happy to hear that thank you so how does it work so I think when the team arrived and they wanted to fix this so how is it a minimal amount of good and get to C and so there was a question of how to do that how to showcase bugs to developers because you have this tool you can output a list of bugs and you have people working on the code base so the first thing that dried is just an infer, get the bug list and try to be smart about see some people in the room about that so that actually works so well in terms of a couple we solved this already story for developers so completely switched to different tasks but then if it hasn't caused a crash in front then you can still do that and for bugs reported by static analyzers it's very hard to know there are actual bugs on that the analyzer on the analyzes functions locally and it doesn't try to stop from entry points or anything like this and so the metric here is really the same but just the developer thinks it's worrying enough that he takes it so instead what we found out is we have to integrate her inside the developer so when they go to the mine and last time to do that it's a different time so we're submitting code video and in her we comment on the code just like the rest of the CI and on the reverse so the developer sends a diff and so this is more or less a set up by Facebook so we use PiCator as our concrete system it's also open source so it goes into the CI and the Fabricator the CI runs the test and one of the things it runs is Infer meanwhile the code videoers in their opinion of the code Infer we try to find issues with it so for instance they say it on the back then what the developer will see something like this just message the same message oh hey I think this can be on the reference and then at some point everyone happy Infer is happy as well and the diff goes so in a bit more detail on the Infer side of what happens here what happens is a lot of good when we get a diff infer on the top revision one with the diff with the changes of the developer and we run it also on the version the base revision of it so before the change and then we compute only the new bugs the one introduced by the diff but presumably reduced by the diff and we recall those so we recall old bugs because as we saw the developers they're not really interested in fixing those new bugs and this way this gives a high signal to the developer that their responsibility is different or he's finding the stories to why this definition so for now these steps are infer and order and I think it's much better to render for example because the business that they do that is in facebook so yeah not in Infer self but these days we're working on bringing that logic in for itself so that more people can yeah, that's it so every month the program there are thousands of modifications and it records hundreds of terrain per month that is based by the developers and what I was talking about before what we measure is the rate which people fix bugs so we want that to be very high otherwise before we start ignoring the tool and then the part of the business most people are trying to start to come back so approximately 70% of the one in Infer is and that's it thank you for the function in the group so Infer is in theory what you do in Infer is when you have a maturity function you start by using any one of them and you analyze the others but on the results of that and then you go around the loop some amount of time and you convert them and then it's some theoretical point future space will stop changing Infer in practice we go around the loop twice and I think now we don't go around we go around the loop we start somewhere because in practice people don't write that many things so we don't have to do that if someone wants to I mean the theory supports it and the tool supports it it doesn't matter if somebody does another thing so the question is how do you compute control progress given that for example functions loops function pointers and dynamic dispatch so there are several issues in what you mentioned that all need to be tackled and the answer so the cfg itself is just a no representation of BST so it's nothing like in Infer when you go to function a method code and you do the method resolution and at that point Infer will track the precise type of type of the object in it and so you use that type to figure out the method but that means the biggest problem we have to overcome is that the code graph is now dynamic you can first start the continuous code graph and start analyzing function in order starting from the continuous code because you don't know which one is putting which other one and so the way we cope with that in Infer is that we are under an analysis so when we get to a code site it could be that we haven't analyzed that function yet because it's dynamic dispatch and we didn't realize that this was a code and so at that point Infer knows that the code is doing good in other functions but these are all very good, very tricky issues and we saw some in the dispatch and we didn't see some of the function pointers so we saw some of that so which one so what was your list again so in Infer Infer assumes everything is sequential for now we're starting to develop a differential analysis in Java and of course with extra functions so close to the exact function that's an interesting one so we have two approaches one is for libraries that I use often and for which it matters we have models inside Infer so it knows what's the hash map so you can always add models and in general but the basic thing it does is it finds a function that it doesn't know anything about then what you do is what we call inject mode we assume that function is the best people thing for the rest of the program so if you return some object and you reference it then oh yeah it was probably a little bit better and during that we found we enabled us to analyze a lot more code than when we used to do more of this instead so the question is there are 30% of issues that are not fixed by the developers and so as I said it's impossible to make this thing a false policy and mix in one vector and figure out things like this so we don't try to measure that and we do the developer but I don't care so what we do is in our team we have someone who can do that and we have developers in several directions of that and we go look at those and we have a discussion with developers oh maybe then you fix that it's like a bug me or oh sorry it's clearly a false positive we try to improve it for that case so we improve the tool continuously based on that for C which compiler is that part so the question is can we do you because there is an intermediate language for false policy so we do the analysis we don't talk about the source code so to elaborate so we do the analysis for clearing on top of the KNST so we start from this T for Java we start from bytecode that means we develop the strategy actually it's kind of in theory you can but the thing is we have I mean there is no particular difficulty there but we don't have a mode where we can just give bytecode inference and we will analyze it you have to give the source code but if somebody wants a nice time then they have to do it with code because there is a lot of code so the question is how does it compare with static analysis there are a lot of static analysis in the wild and when we found that when trying to compare them they all work pretty much different sets of bugs so the best strategy here is minimal but it doesn't come forward but we want to give this kind of open session but if you can't find any way then it's not going to work because it's a fast version of stable so the question is what it says actually it's a good question so I don't have a very good answer to that I can put technical differences in the tools static analysis is needed to analyze a single transmission where I think it works across competition units in general it's not just to find sort of debugs it's pretty inter-procedural so it will find bugs sometimes across encode chains and items and it's also not looking at the best site so yes this how do sports bring integration and how do I write the last one do sports integration and for example how do I write the last one how do I write the last one screen integration screen integration how do I write the next one I'm sorry how do I write the last one I don't know what that is that's your answer there's another we can talk about that we can teach you about that and as we consider the matter in the report in each yeah that would be great and thank you do you find what's for the kids so do we plan to vote in for like 10 kids so I don't see any difficulties with that I don't think we want to do that because we don't use it so it doesn't make much sense but what we're doing as I said is we're trying to put most of the logic you would need to do that inside so that you could say infer different analysis of this and that and then it would automatically just do what I said, organizing the top vision, the base revision and then the reports from in-car are simple objects so hopefully someone will write some interface for that I will just write the question for you do you work your line to write foundations, defense injection oh right yes so I think we'll write this result before we go the question was do we have any ideas or not at the moment it would be nice to have we're using it's just we can also format it in a way that it's not there's nothing to integrate to run current changes what's the question infer is written for camel you said that you run on deep just on deeps is it implied that you need some great storage for storing some for this right and the question is in the term that we run on deeps so don't imply that we make an external storage so not really so no because what we do is we really run it for on the deep and on the distributed so we run it twice for every deep so that we can do comparison and so forth so that's the longer story is we're most of our projects are back and we used to have cash to cash the results of the analysis so some very often the case that some parts of the analysis results are already in the cash and we don't run it if I recall correctly I saw one slide where the output from infer was pushed to a source code management system or review system was it correct or do you support integration with for instance bucket or a kit app that the remarks of infer coming to the machine pain so the question was what comes inside a review tool it's just integrative fabricator and that's not even infer talking to a fabricator API it's just the CI reading the results from for and then looking at fabricator we only have this sort of integration but that's something we're hoping to build tools for there was a lot of commented code where I showed something in HD this guy how am I going to do this everyone is working to write so the thing is it's just a matter of writing a compiler from your language to read a person so what we can do is we should be able to so if you need intermediate language then you can base whatever content you have we have times for other projects learning biophones so we were offered a lot of footage to run on that for example for Libra for Libra for Libra for Libra for Libra for Libra so we're here information so the question is how long does it take for access as a pyrofoam and we delegate so I'm running in pyrofoam so for the way that I work we do have so in a CI working perfectly fine so the answer in the deep analysis you can give the on this we end to we work within 10 minutes and so our P50 around that is much worse because because of the deep analysis in products there is a small change to trigger and so it depends on how much is in the so the question is I mentioned that we go look at work that people don't fix do we also look at work that people don't fix sometimes we're great at it because speed has been fixed and we first talked about it at some point so we got it and then what do they have like that's the most great work we've done we'll just do it while in fact we've got people the question is I don't think they do so these are not runtime bugs these are sure so my thing is info will be running on the next this as well so if you found it this time we'll find it next time so maybe you already know that we're going to do more questions ok thank you very much