Hi guys, my name is Aditya, I work for a browser stack as a leader of systems engineering and I contribute to Fedora and Atomic and other community related projects. Today I am going to talk about a very touchy topic which has given me a big burn in my heart. We got breached last year, the entire details of breached are available online, we have written a white paper and published it, you can read how it happened and what we did to address it. What I am going to talk about right now is that what we did once the breach happened, what helped us in containing the breach and basically there are things that all of us know but we usually do not pay attention in the rush of getting the product out or probably we never thought that this small thing can cause that much impact. So I would like to take this 15, 20 minutes to probably highlight those points which probably we already know but we never do them. These are the topics which we will try to cover, so let us start.  Anybody who does not monitor the production, everybody does that, we all monitor production. How many of you monitor production from multiple locations, am I doing something wrong? How many of you monitor production from multiple locations, just 2, 3, 5, 6, 7, wow, 8, right. So I guess there are good at least 100 people or 70, 80 to 100 people sitting here and about 10% of us monitor production from more than one location. That is extremely bad because what happens is that when you monitor your production only from one location and if that monitoring says that production is down, it does not really mean that production is down. It just means that that one single site is not able to reach your production. It could be a lot of variables in between, it could be bad network, in between it could be your monitoring node failure, it could be a production node failure. How do you distinguish that one actually failed there? That is why you need multi-location monitoring. Please do that, that is the first thing which every production site should have. So that was the one thing which actually helped us a lot. As soon as anything goes down, we have monitoring from 8 different locations. It is cheap, AWS rocks, use T1 micro, right. Monitor unlikely situations like table locks. So there are certain alerts which might not actually sound in infrastructure ever. But trust me if they sound, it is a fire drill. Table locks is one such thing because if your table is locked, then something is not right, your production is down. How will it go down? Either it is a code bug and trust me code bug is very easy to handle. If it is not a code bug, then again you are in for a fire drill because that means that somebody is trying to do something to your database which is not very good. So pay extreme attention to such things which can, which are very unlikely but they are very, very harmful, right. One thing is one last thing in monitoring outsays, monitor IP addresses in the sense that our application servers or web servers which front the entire web sees a lot of traffic. It is not possible to monitor all the IP addresses there, leave that. But you back end machines, for example, your databases, your cases, your non production but important components which do not see direct consumer traffic, you should monitor them for any anonymous IP addresses. For example, if your database doesn't have a whitelist based access control, then you are in for a very bad time, right. Am I able to convey what I am trying to say? Wildcards, this is the next big thing like all of you have some sort of database in production, right. And when databases are in production, we create a user, we create a database and then we do grant all to my best awesome user with my best password, right. How many of you have done that? Fix it, fix it, fix it. This is going to be a nightmare because you have given a, you have given a grant all. Is it me? Am I doing this? Some mic is not right, okay, right, am I audible? Okay, is this better? Am I audible? Okay, right, so we were talking about wildcards. How many of you have heard of a company known as CloudBits? CloudBits was the name? Cloud, something, okay. So just a quick story. What happened to them was that they were under this premise, grant all to the user and one fine day they got hacked. The hacker, the good guy that he was, he downloaded all of their data, then extorted them. They refused to give in.  See how efficient it is.  So never use wildcards, especially in your database grants. And for that matter, any wildcard ACL, if you have any sort of wildcard ACL in probably your sudoers or probably any other application whatsoever, remove them. Be very specific about ACL. Again, this is one of the very big problem which is introduced because of the cloud environment which we live in these days. Machines can come up and go away instantaneously. And because of that, okay, code spaces, yes, sorry, yep, you're right, code spaces. So machines come up and go away very quickly, right? So do you actually, how many of you can tell me right now how many machines you have in your production at this point of time? Do you guys have a good enough system to tell that? How many of you have that sort of system which can point out, okay, okay, but still like 10 maybe, 10 people here? Yeah, so I think we need to work on this area as well. We need to have better inventory systems. And we need to remove the involvement of humans here. This is a machine's job. Probably we should have scripts or probably tool like Informer which was discussed previously. Tools like some sort of auto discovery tools which can actually identify what all machines you have in your infrastructure are those machines patched, what are the loop holes and all those things. We need to have a record of them, right, next is your API keys. So when people usually start with something like AWS or Google Cloud Engine or something like that, we generate API keys to do a lot of automated work. But usually because when we start, again, the rush is on product to push out the product, we create very generic keys, okay, this is one key, this key will have EC2 access, S3 access, RDS access, Route 53 access, we do that, right? Because we have to get the work done. Now what happens is that eventually with time that key goes on to a lot of people, somebody wants to work on S3, what does he do? You won't give him a new key, you will say, okay, take this key, this has the permission, go ahead, very, very wrong idea. Because now you just gave the person key for S3 but he has now access to EC2, RDS, Route 53, this is extremely bad, right? What if the laptop on which you store the keys, somebody stole it, or just somebody was just browsing it and he got the keys? There can be a lot of scenarios where you can leak out this very important key. So it's always, always better to create very specific keys. Like if you want an application to see how many files are there, you just need S3 list keys, you don't need all of the stuff that comes along, just remove it. Another thing is applications like AWS and Google for Business, these applications are supporting two-factor authentication these days, please use it. It's there for a reason, it helps a lot. Even if your password is stolen, you still have a reasonable amount of protection if you are with two-factor authentication. So yeah, please use it. Another thing is that we have been advocating that production and staging environment should be very similar. But exactly how similar do you want them to be? Because if they are absolutely identical, what happens is that the powers that my production should have are also now with staging. So effectively, something which should be controlled by production could now also be controlled by staging. So now if my staging keys are gone, probably somebody can misuse them to delete my production instances, right? So if you have keys which are of same privileges as production and you're distributing them to everybody so that they can do testing on staging, then I think you need to revise your strategy, probably have another region where you can generate region-specific keys and just have your staging there. Don't give your staging keys permission to entire AWS so that they can play around. Don't do that, right? This is another issue that these days we have CVs coming in, right? A lot of bugs are coming in. I think in last one year, we had a lot of big vulnerabilities like Poodle was there, Shellshock was there. Now, latest one is Venom. How many of you heard of Venom? Okay, still better number, right? So what happens in this scenario is that it's very difficult to keep up with the number of CVs, the number of vulnerabilities that are coming up, right? So what I suggest there is have an automated system, something like OpenVas. Again, doesn't cost you much, just pick a T1 micro instance, install OpenVas, it's an open source project. They give you a list of CVs against which you can scan your hardware, scan your instances and you can see what kind of vulnerabilities and what kind of CVs are there, which can be exploited for your machines. So that will help you a lot in catching and fixing the bugs early on, right? OpenVas is one such tool, there are more tools. I think if you want to go take a deep dive, probably use Nectar or something like that, that will also help you. Right, backups. This was one of the mistakes that cloud spaces, cloud spaces, right? Cloud spaces did, code spaces, sorry. This was one of the mistakes that code spaces did. They took the backups, but they stored their backups in AWS only. So now effectively, if I compromise their AWS account, I have access to their main databases as well as their backups. So I can wipe them out easily, right? What you need to do is have the backup in AWS for easy recovery. But you should have an off-site backup and by off-site, I don't mean in another region. I mean with a totally different provider with having totally different access keys and everything all. So even if you are compromised from AWS site, your off-site backups shouldn't be compromised, right? And yeah, encrypted. It's a very cheap process, doesn't cost any money at all. And it's not very bad on IO as well. Look at looks, Linux encryption. It supports AES encryption, which is very strong, good enough. And that'll help you a lot. Also, I think logging is something which we miss. I think first point is something which all of us try to do. We try to have all the important logs centrally. We do that. But we almost always fail on the second point, which is while we log our applications, we don't log the actions, right? So if I ask you today that can you tell me what all instances were booted in your infrastructure in AWS or Google Engine in last week? How many of you would actually be able to tell me? Okay, how would you tell me that? What kind of logging do you use? Uptime, no, no, okay. Let me put it in better way. You monitor the uptime. I'm asking that, who actually fired the command to boot that instance? Anyone doing any activity on the system? Okay, no, I think, okay, my question is, somebody got the key, booted up an instance. Can you tell me what time, what key was used to boot that instance? No, right, yes. CloudTrail on AWS? Yes, CloudTrail is one of the solutions that can do that. Other than CloudTrail, is there anybody else who's doing something else? Or how many of you are actually using CloudTrail? Two, okay, four, right? So these are the things which you need to do. You need to monitor that who is actually booting up what, booting up when, and how, from where. These are the things which you need to know, because they are the ones which will bite you, right? And lastly, and I cannot stress this enough, when the breach happened, we were very blessed to have an amazing team, which helped, I mean, we pulled out, I think, two days straight. And even after that, we, you know, people came up and, you know, were ready to help, including some of the ex-employees who are there, okay, we can help you, tell us what to do, what should we do. Having a good tight integrated, tightly integrated team will help you to, you know, go through bad phases. So that's one thing which I think you should build. That's very nice to have. I think that's about it. Do you guys have any questions or anything? Hi. I think also we should be investing time in figuring out what could go wrong, because when we talk about vulnerabilities, right?  Agreed, you should do that, but there are only so many things you can hack which you have designed. It's like testing your own code. You almost never find any bugs. The developer may not be doing it. That can be, you know, a third party or a white hat or something. See, I agree to that and that's a good thing to do. But what I'm trying to say here is that there would always be one smart guy who would be slightly better and who would probably be able to hack you even after you have done all that. One more thing actually is honey-tapping. So basically, you know, if someone is pushing a malware or some kind of code where he can get an entry into the system, right? We can actually design a defense system which may protect to a greater extent. I can't say it to be 100% proof, but at least we can have an effort towards it. Right, so there are such systems already out there. There are IDS, Inclusion Detection Prevention System. There are malware scanners. There are Rootkit hunters. They are there. Yes, they help. They help a lot and we should have them. Is this that they are not, again, like you said, they're not 100% sound. So yeah, they give a good coverage, though.


Hi guys, welcome to our session. I hope you guys are having a good time at Rupalcon. There's still about a couple of days left, so make them the host of it. Okay, so jumping right in, I'm going to quickly introduce ourselves. I'm Devanju, I head business at OpenSense Labs. You guys can call me Dev, but I am not Dev, I am Biz, he's Dev. Okay, so a few of you laugh, but I had this slide just to like empower me, so just to give you off to Biz again. I am Biz and I had architecture at OpenSense Labs, and so one of our key focus area is to bring technology, which is outside the periphery of PHP and Rupal, and use that to make better digital experiences. So that's where NLP and that's where IPFS was something we picked up, right? Awesome. Someone who can take a picture, beer is on me. So the agenda of the session will be very simple. We'll first understand what are the current problems of the internet with the dealing with. Okay, what is the common thread connecting those problems? Possibly put a solution out there via IPFS, and then connect Rupal and IPFS and let's think about that. So just to be clear, the agenda of this session is to bring the community together to be more accepting to technologies that are outside Rupal as well.  So that was said by Bradbury, author of Fahrenheit 451. So he meant it in a more literal and metamorphical sense, that there will always be people who are deterrent to accepting new technologies, but we as an open source community should be more accepting, and see what are the possibilities outside of Rupal and amalgamating that. Okay, so these are the three network topologies that we essentially deal with. How the internet started out was essentially a distributed system itself on the right-most side, where the client and the STB server was handled by a group of people or a single person. So it made more sense to share data and files in a much more seamless way. How the web has progressed is towards the centralized system where a few organizations or corporations control how we access our information as well, which basically means that if that central node was to go down, all that access to information would go away eventually. And considering now we are at that centralized system, we want to shift back to either a distributed method or a decentralized thing. So what are the current problems with the centralized system? One is of course a single point of failure. So just to give you that perspective, so Google about three to four years back went down for about five minutes which brought down web traffic by about 40 percent. In Jan 2011, Egypt was able to shut down 88 percent of its web traffic because they control the logistics behind it. And that's sort of the power that those central nodes have. Censorship again, so Russia has anti-extremist laws. If you post or share post-opposition content, there are a lot of countries like China, Bahrain, Israel who control the sort of information you can access. There are bad keywords in China. Okay, so again, it's a censorship that's pulling away from the centralized system as well. Impermanence, so everyone's aware of error 404. So one is of course with how much information you want to share out. If it's given with consent that you're putting away information and archiving it, but what happens if those central nodes go down and your users are served with this massive message itself? Bandwidth latency multiple times. So according to me, this is one of the most important failure points of the current way the internet is panned out. With the advent of low-cost smartphones, what's happening is the way people can access internet is growing exponentially, but the logistics behind are not at the same rate, so which is causing a lot of latency. For example, if I was to ping a server in Netherlands from New Delhi, it takes about 200 milliseconds. If I was to do it to Iowa from New Delhi, it's about 350 milliseconds, and that time is eventually gonna rise because people who are accessing that kind of information, they will grow at an exponential stage, which brings to another problem, bandwidth. So for example, I have to download a one GB file, a movie file, and Vid here has to do the same. So we are collectively using two GB, and for example, you guys wanna do that, so we're using multiplied into that bandwidth as well. Now, if I have that file already on me, he can just access it from me versus doing multiple network hops to get that information in. Multiple devices, if they are, let's say, accessing that central node to access that information, okay, well, the channel is restricted, so it becomes slower for you to access those files. So that's another problem we're dealing with, offline. So we're still living in a world of online offline at the end of the day. That central node, I keep repeating the word central node because it's a centralized system that we're dealing with. And if that goes offline, you're not able to access that information. For example, that one GB file was there on that server, I'm not able to access it, but if he has it, why can't I use that? Why can't we use that together? Security, so again, so we think security has encryption of data, but what we're actually doing is we're just encrypting the route to access that data, not the data itself. If we were to do that, that basically means either we'd be security experts or we'd have to hire one. So we have to, in terms of give that power to ourselves where we are able to share, hide the kind of information we wanna do and then share whatever that's relevant to us. So those are the problems that we're dealing with and yeah, we can throw a laptop off, yeah. Okay, so what's the common thread that connects all of these problems? It's location-based addressing. If I was to access a file on my own website, I'd have to do multiple network hops. I'm sitting in New Delhi, okay? So this does a network hop to Europe first, then somewhere in the US and a couple of cities in the US itself to access that file, which means I'm accessing a physical location, okay? Why can't it be something much more simpler in that sense? So what's the solution, content-based addressing? It basically means I'm taking that file, passing it through a hash function which returns the hash of the file itself and it's almost like a digital fingerprint of the file. This is essentially what Git uses to track changes in repositories as well. We make the content, it's a content addressable, right? So which brings us to IPFS. So IPFS is essentially a protocol and it's a peer-to-peer method of storing and sharing hypermedia in a distributed file system itself. It started out with a mission or a vision to replace HTTP itself, which I personally, and that's my personal opinion on it, it will happen because the internet has evolved to a certain extent but not from HTTP, HTTPS, from content perspective itself. So advantages, so no content duplicacy. So what happens? So if I'm, let's say, uploading a file to the IPFS, it returns a hash, right? And he was, let's say, sitting in another part of the country and he uploads the same file, it will return the same hash value, which basically means I cannot have duplicate data on the IPFS network. Integrity, because the data structure behind, which we will cover later is, the data structure behind is the Merkle DAG. So if there was, let's say, in that image file, a pixel was to change, it will change the entire hash value itself, which basically means I will be able to detect if my data has been tampered with. There's, of course, high performance now because you don't have dependency on central nodes, but nodes around you itself, which means you will be able to access that information much more faster. It's cheaper hosting. For people who are hosting a lot of data, they have to pay thousands of dollars. It becomes a more cost effective way to use IPFS and distribute data internally as well. Censorship resistant, again, there's no central dependency, so nobody can block keywords. You can post as much content as you want. And yeah, keep it censorship free. Access to offline data, so those central nodes never go down. You will always have nodes with you. As of now, there are about a couple of thousand, 3,000 IPFS nodes that are active right now, and you can host data all over the world with these guys. So yeah, okay, Johnahill always saves the world. Okay, so who else is using IPFS? You bought, it's basically an identification system that uses IPFS to create an identity for you guys. Akasha Project is a social network that again uses IPFS to have censorship free content posting. Open Bazaar is essentially a marketplace where buyers and traders can transact online without any platform fees. They use IPFS for the distribution methods itself. Argo is, if you just put it across, it's Dropbox on IPFS, yeah? Okay, so this is where it comes in. Hi, so we have seen what Drupal, what IPFS is about. It's a distributed file system built over the core technology which Blockchain has, but it is meant for sharing files on a decentralized system. And so the common philosophy, Drupal is all about openness and content and giving editors the power, right? And IPFS is about keeping them, keeping them maintaining the integrity and keeping it immutable, right? And it's, it appeared very natural that these two things have to come together or might be very early staged at this point of time, but they will come together to probably solve bigger problems, right? And that's, so just let me quickly go through the internal data structure that is behind IPFS. This is Merkle DAG, it's a cyclic tree structure where each of the files is actually split into multiple blocks and each of the blocks have their own hash and the combination of the child hash is used to generate the parent's hash. So in this example, they've already mentioned that if you just change one of the blocks at the last level, try to modify it, it will actually change the topmost parent's hash itself. So that ensures integrity and that also handles redundancy of files. And this is something which is a similar behavior if you notice on a S3, if you upload two exact files internally as S3 on AWS, handles redundancy. Not sure if they're using Merkle tree or Merkle DAG, but yeah, something like that happens. Yes, so now we started brainstorming what would be the possible use cases of IPFS around Drupal or websites in general, okay? So let's, as a backend storage system, so Drupal file system, let's create two file entities, same image. We upload into different media entities and we have duplicate copies on the file system, right? If something like IPFS or the algorithm that Merkle DAG provides, we could actually, this is not a problem for everyone from small sites, but when you're storing large amount of content behind a dam, it is actually a problem. And that's where these technologies inspire us to put this method of creating the signatures using hash to handle redundancy. So that could be one use case in the space of internet and websites, right, applications. Then version control, so we already mentioned Git uses a similar, say, Merkle tree algorithm, right? But version control system for images behind dam, you know, large video files. If you try to upload similar video files, we can use a versioning system which is not actually creating two full copies of the same video file which has slight changes, right? So that could save and storage and have a better versioning system for media assets, large media assets. And CDN, this looks to be the most promising and interesting one, so we had this problem of network hops accessing a server which is based in US here and we are accessing from India or any remote location. That's where the CDN solved the problem to a point where it is replicating the assets to, say, eight, 10 data centers and you are able to access the nearest one. IPFS can be used to solve the problem to the next level where it's not only about eight or 10 data centers but it's across the world on a full IPFS network of 2,000, 5,000 nodes, right? So I think that's one of the very interesting possibilities that can be used in the very near future. Then we started more brainstorming, okay, how do we give the power what Drupal provides to content editors? So IPFS is still a technology which only very tech people, tech savvy people can actually leverage and that's the beauty of Drupal, giving editors and the content creators that power to manage and handle content. So this is a small blueprint that we made and there's a small demo based on that just after this. So it's a really simple, editors create the content on Drupal, we actually push the node object as adjacent to IPFS, we maintain the mapping of entity ID and the hash returned by IPFS within Drupal, okay? And that's what is again used by the users to fetch the content. Now there are a lot of problems in it. This is not something which will actually solve a serious major business problem right out but yeah, this is a good starting point. And so yeah, I have a small demo right there, sorry. So we made a small module which interacts with, so I would like to, so what we're doing is we are uploading three images on three different nodes, two of them are exact same images and it is being sent to IPFS, I'll skip this three images upload, I'll just show you the final result. So yeah, this is where we are uploading two exact images into the entity IDs are different but the hash returned by IPFS is exactly same. If you notice 30 and 32nd one, yeah. So this is what I was referring to, okay? So this is a smaller demo which is where we're trying to use this with the media system of Drupal, okay? And the challenges, now to solve problems, to make it actually usable in real world scenarios, there are certain problems which needs to be addressed, probably as I said, it's in the early stage, searching in IPFS, the only way to address the content is using the hash that it generates, right? So we cannot, it's not a full-fledged database, it's a distributed file system in the end, right? So we cannot actually search based on keyword or try to access the content in any other way apart from the, say, hash as a primary key, that's it. So that's a problem. And again, second is the complex content relationships, the flexibility that Drupal provides us to reference content, to reference to, we can create a complex hierarchy of content pieces, right? That cannot be handled very easily on IPFS, but that is something we need to probably, moving forward, might be solved. IPFS has views back in. Now, we love views, everyone does. And that is something which Drupal provides to end users to make things fast quickly. And again, the same problem that we have with searching, the only way to access the files on IPFS is the hash. I don't see a straight up way of doing it, but again, this is a problem which needs to be resolved. And orphaning of content on IPFS is very common. So for example, in the previous blueprint that we discussed, if we get to lose the mapping of entity IDs and the hash mapping, if we somehow lose it, the content which is already on, is on IPFS is orphaned. There's no way to figure that and find that out, unless someone else uploads that again and gets the same hash, right? So these are the few of the problems that needs to be addressed to where it becomes a real problem solver. But yeah, the other use cases, not necessarily around with Drupal, but in general as for archivist, who if you want to store large amount of data and make that permanently available, yes, IPFS is a good solution to store it's cheap. It's cheap and the performance is pretty good. If you're delivering large amount of content, as the example we discussed about the CDN, if you're delivering large amount of content to users or media to users, IPFS is a good solution. It's cheap and where you actually save a lot of money on bandwidth. Researchers are always short of funds, like running short of funds, and hosting is a large amount of research data is a problem. So now they need it to access them really fast and in a cost effective way. So for them, it's a good solution, it's a good way to approach I think. And content creators are just about the spirit of web keeping content out there without keeping it uncensored and at a low cost. I think for them it's a good start. Yeah, so Dave. Okay, so now we understood how Drupal can amalgamate with IPFS itself. So we're running at that almost as a threshold where the cost of producing content will go much higher than cost of delivering content. And Drupal is content centric. So, and if there's an alternative to avoid that, I think IPFS becomes inevitable in that sense. Again, like we said, for content creators, you get to empower yourself, what the sort of content you wanna share, the sort of content you wanna talk about. So because it's content addressable and we're using content signing, so DDoS attacks become impossible because there's no physical location to do those DDoS attacks. So again, you save money on security measures as well. Because there is no origin server and there's a lot of internet penetration that's happening in the developing countries. For them, it becomes much more easier and faster to access the web itself, okay? So now we as a community need to come about and think as to what all possible use cases can add on, okay? And that's about it from us. I think we wrapped up exactly in time. Yeah, okay, awesome. Thanks. Just thanking a couple of more people who are not here but helped us put this demo and this stuff together. So they are for people from our team. And I just met this gentleman from Wipro who they're actually working on something, putting Drupal and Hyperledger together. They're having a BOF, this is a BOF 4 at 345 PM I guess. So if you're interested in taking that discussion further, that is a good point to start. Okay, join us for Contribution Sprints Friday. Yes, definitely. And you can always give us feedback. Yes, we can open up to Q and A. Yeah, okay, awesome. Guys, any questions? Or we can, okay, oh yeah, okay. Nice work guys, thanks for presenting this. Is this module available for community to try? Yes, this is. Okay, could you mention that on your slide somewhere when you post them on your session? All right, perfect. So when we upload the deck, we'll upload it with the module. Perfect, I have a question. So I think you guys are mentioning this file system stuff from a public standpoint. Things are open. How would something like this work when things need to be, there needs to be access control? So I'm a researcher, so this is very interesting, right? So how can something like this work with access control? In some ways you have done a CDN, right? With hashing, right? But what about access control? Because that's the next level. So when we actually, the signature function, the function that actually generates that hash when you upload a file or any content on IPFS, you can actually use a secret key to encrypt that. So IPFS has that possibility. That's encryption, not necessarily access control. So you are saying, oh, our stuff is open, but nobody can get to it. That's, you know, I don't think many of the PHI data people would like that kind of, you know, encryption level access control. The access control means nobody can get the stuff, right? So different. The content is out there, the only way to access is if you keep it non-encrypted, only way to access is using the hash key, right? If you encrypt it, again, you need the secret key with it. But the more, ACL is more on the application side, right? And that's where systems like Drupal needs to be able to talk to IPFS in a way that provides that flexibility. When I was talking about complex entity relationships, this gets into that. Okay, perfect, thank you. Thanks. Hey, guys, thanks. So since this is, you know, sort of like you're investigating technologies that are not really business ready yet, right? Like you're looking very far forward. Do you have a roadmap or do you have, like, maybe some next stages? Where are you gonna build that connection so that maybe we have, like, something as a CDN or something we can use on our sites the next six months, year or two years? So this was the demo that we showed was just something we just put together in two days before the triple con, okay? But we have been researching and doing POCs around other blockchain technologies apart from IPFS. But IPFS was one we figured out that which is closest to solve business problems, right? And I think, for example, if you look at the, one of the examples they've mentioned was about Dropbox, which is using IPFS, something like Dropbox. So I think CDN is, we are not actively working on it right now to build something like that. It is more of a POC stuff. But I think CDNs should be coming up. Someone should be doing it very soon. Okay, great. All right, thanks. I think with the media module, okay? Implementing a simple versioning of, let's say the hashes itself and you can avoid duplicate large files. That should be the first thing that we should be actually getting to immediately after. Nice, thanks. Hey, thanks for your good presentation. I had two, like, related questions about sort of the way hashes work in IPFS. The first one is, I've heard a lot of criticism around, like, for instance, Facebook and other social networks that use hashing for files because when you delete something, it isn't necessarily ever deleted from the servers. It's, the pointer is deleted, but because they store hashes of everything to prevent duplication, the file is actually still out there. So I guess my question is one, what do you think about that? And then the related one is, if all the files are being hashed, it seems like that would actually, while it would make tampering with the files easy to detect, it would also make surveillance of who's receiving those files or the file traffic much easier because all you have to do is look for the hashes of particular files that you as a government or a agency or an internet company doesn't want someone to access and all of a sudden, the metadata has it all, right? So I guess I just wanted to hear your thoughts on those too. So about the first one, sorry, what was the first one? I just wanted to... Like if you delete something, it's not really deleting. So the guys behind IPFS, they are, so currently there is a mechanism where the content, which is not being accessed, so they age out and it's still out there, but eventually they age out and they are overwritten at some point. So I think they are working on improvising this aging out and deletion process, but it is not something that you can actively, okay, I wanna delete this, you cannot do that. It will age out because it is not being accessed. So that's what how IPFS guys are handling it. And because in the end, when we say that, it's permanent, it's permanent, but it could be overwritten because the number of nodes are limited and the amount of storage that each node is giving is limited, recurrently, right? When the number of nodes increase, probably the possibilities might change. So that's what this current state is. And about the hash itself, like surveilling the hash. If we are in a, for example, we are in this room and we have five nodes here and we are communicating and you have a file copy, which I need, it's just between me and you. It's not something where there's no central point where the transaction are being logged. Gotcha. Yeah, so yes, like the standard blockchain stuff that you actually can access the full ledger, right? There is, but not sure if it is being handled right now. It's absolutely like blockchain. So the problem you are seeing, persists, yes. Okay, thanks. Hi, so my question is, is it looks like you're still tying on a base level to the centralized system as far as like, I build a site and I have my images or PDFs or whatever hosted on IPFS, but that on the back end, but that front to end is still a physical location that somebody goes to at least get the base links. Do you have any sort of plan to offer, because hash is not a very distributable piece of information, you know, it's not very memorable, I personally can't memorize 32, 64, you know, 36 character digits. Anyway, so do you have any sort of implementation model for impounding a truly decentralized sort of, like let's say I want to publish a newsletter that would be disapproved by certain governments. Not saying I want to, just picking an example. Nobody here wants to. Is there a way that there could be like, for instance, an address that then goes to the decentralized, a simplified, almost like a bitly, for lack of a better example. Yes, so the IPFS organization itself, they provide IPFS.io, so that becomes your central entry point to the complete, you know, the files stored on the IPFS network itself, but you can actually put your own DNS server, which can directly talk to the IPFS system behind, without actually depending on IPFS guys themselves. Okay, that is one. Second, if you look at this blueprint, there's the right part, I missed that one. So this was something which I was also thinking about, in the end we are putting a centralized Drupal application behind all the content, right? We have all the content on IPFS. How do we promote distribution of that? So in that case, we can think of a prepackaged Drupal profile, which comes with mapping, which comes with the current mapping of the hash and the entity IDs. So all you need is a Drupal application which understands how to talk to the IPFS behind it, and has a first starting point of existing mapping. I think that is a workaround. I don't know if it's a full-fledged solution, that's why I mentioned, if public repositories of that websites, anyone can deploy that and access all the content. Now, within this mapping of the entities and the hash, they can further be put into IPFS of the full mapping, and then that can be accessed by, so you basically just distribute one key and it fetches all the mapping, and then as a next step, get to the content. Kind of re-interprets it out too. Yeah, so these are all workarounds which could be thought about, but... Because Drupal is all about dynamic content, so if I edit something, if I post a new article, and I want it decentralized across the IPFS network, that's the ideal. That would be the beautiful thing. So Drupal, the structure is pretty complex, so there are a few frameworks. So there are browsers who utilizes IPFS, so all you do is install that browser, it creates IPFS node, and also lets you publish web pages on it. But again, the power available is very limited compared to Drupal from an editorial perspective. All right, thank you very much. Last question. Great presentation, first of all. What I see, this is gonna revolutionize the internet, and I'd say about five to 10 years. Oh yeah, absolutely, I mean, because you see all this stuff happen in third world countries, not only from an honest, open interpretation of all the data, but also financially. So it's a two-part question, I'm sure, of business side and tech. Number one, I see this as potentially being the next Bitcoin wave of data, not only currency, but you're talking about data here. And what kind of investment opportunities do you see in the future for something like this business-wise? That's the first part of the question. And the second part is how do you foresee governments and other agencies sort of trying to circumvent this new wave of information that's gonna be freely spreading through the internet? So I'm gonna answer this later part. Open source is free, but... Not always, right? Yeah, so information will always be available freely in that sense, okay? Whether Drupal jumps the bandwagon or not, it's gonna happen either way. People will be publishing content that'll be censorship-free, okay? It's about how we as Drupalers utilize this new technology in place. Juan Bennett, who are the guy behind IPFS, started this with a clear cognition of to replace HTTP. So yeah, of course, there's no governmental control. There's no central control that's gonna happen, but that's gonna happen either way. Because we are moving to a world where information should be available more freely, okay? And there should be no central organizations or corporations that should be controlling it at the end of the day. And we as an open source community understand the value of that. And that's why it just only makes sense to bring them together. Could you give the first question again? Oh, just the business opportunity behind it. Yeah, investment, I mean, cryptocurrency was kind of a thing and I see this being similar, but with different intentions. Okay, so we wanna know, so definitely not being equivalent to cryptocurrency at all. So that's one use case of blockchain. IPFS is another use case, absolutely whatsoever. So if you're thinking in terms of, do you wanna invest something here? I mean, that's cryptocurrency and that's totally separate from that perspective. There's a lot of mining. There's a lot of proof of work that goes on there. Nothing in terms of this is basically a protocol to share and store files across a distributed file system itself. Right. Okay, so yeah, does that answer? Yeah, I don't know if that makes sense. Yeah, yeah, yeah. Okay, awesome, awesome. Thanks guys.


The most basic use of pairs is as a data service that is to ask questions such as what is the temperature or the temperature of forecast at some location. In this sample query, we're going to simply request the temperature of forecast for Kyoto. To do so, we create a new query. We select the data we're interested in, namely this is weather. We pick the weather forecast from the global forecast system. We are interested in the ground temperature, so we select this. Subsequently, we have to specify the location, so this is a point query. And we select Kyoto simply from the map, which is here. Now finally, we have to select the time interval we're interested in.  Essentially, it tells you for what time there is data available from the specific data layer. Since this is a temperature forecast, you see that this actually goes somewhat into the future. So just so you know, today is March the 5th. There's roughly two weeks of forecast range for this forecast. So we can select something up to March 17. At the same time, there's actually historical forecast data available, which is why this goes back all the way to 2015. And we can simply select the complete time series like this. So finally, we have to give this query a name and then we can submit it. Now point queries are actually very fast, so this doesn't take very long. You can see here immediately after submitting, this is at 95%. So it only takes a few seconds to wait for this to be finished. And now we can take a look at this. So in this window, we see at the bottom the temperature time series. Now if we hover over it, it basically highlights the temperature at this point. We are hovering over units for temperature here and Kelvin. If we wonder, we can just change the map into standard maps for our political map. And the neat thing is, since point queries are very fast, we can simply click somewhere else in the map, such as Tokyo here. And now get the time series for Tokyo. Okay, this is requested in real time from the system. So this launches another query. And now we can see and compare the time series for Tokyo. If we wanted to, we can also change the time interval to zoom in on some aspects. So if we're just interested in the last year, we could select 2017 like this. So now we have the 2017 cycle here. And finally, you notice there's a button at the top bottom right corner here to download the data.


Hi everyone. I hope you enjoyed the Service MeshCon so far. In this talk, we are going to speak about how virtual machines are becoming first-class citizens in Service Mesh. I am the Nijano, director of field engineering in IMEA at solo.io. So at the beginning, everything started with these modern applications and we've seen the evolution to microservices and obviously Kubernetes became the most popular platform to run these microservices. But we ended up with two separate worlds. On one side, you have some legacy applications running on bare-metal servers or on virtualization platform like VMware. And on the other side, the new modern cloud-native applications running on Kubernetes. And then after that, what we've seen is the Service Mesh started to become really popular with this idea that you can have on one side a control plane where you define all your policies. And on the other side, the data plane where all these policies are enforced. And when we speak about these policies, we speak about things like being able to encrypt communication between microservices, being able to get some telemetry information, and all these things becoming possible because of this sidecar proxy that is running on each pod in most of the cases on most of the Service Mesh out there and that they are based on Envoy. And basically, you don't need to do anything at the application level. But instead, you use the Service Mesh to provide all these capabilities like encryption, telemetry, else check, and so on. And what's very interesting is that it's about to unify these two worlds. What I mean by that is that you have the virtualization, the legacy application running on VMware or Bar Metal that can now be part of the Mesh. And that's very interesting because it means that I can now have communication between the legacy application and the modern applications being encrypted. I can do some kind of canary deployment, for example. We'll see that just here. You can have the same application running on the legacy environment and on Kubernetes. And you want to seamlessly migrate from VMware to Kubernetes, this application that becomes possible because that's one of the nice things you can do with Service Mesh. You can do some kind of, you know, canary deployment, some kind of traffic shift, say, okay, at the beginning, I start by having all my requests for this application are sent to this legacy environment. But slowly, I start to send like 25% of the requests to the same application running on Kubernetes. And I can check that everything works well. And and then when I see that everything is fine, I can migrate completely the application. So I can now do this migration from legacy environment to Kubernetes or to containers without any downtime. I can also get some extra benefits for my legacy application, even if I want to keep them running in their current platform. I can still, you know, get the encryption, like I said before, but I can also get some telemetry information and another benefits that I generally get with the Service Mesh. They are different Service Mesh technology available. But here we'll focus on Istio. If you look at the CNCF survey that has been done last year, we can see that Istio is definitely the most popular Service Mesh out there. And I would say that it will be interesting to see the results in 2021. And I'm pretty sure it's even, you know, bigger now. So we are really going to focus on Istio in this talk. And also, so one of the reasons is because it's definitely the most popular one. But also the other reason is that it now has a really good support for VMs and environmental servers. So let's jump directly in the demo and show you how all these things are done. And especially what we will do in the demo is that we use this environment where you see I'm running multiple Cubans clusters using kind. And on this different Cubans cluster, I have deployed like Istio and two of them, and I've deployed Gloomesh in the third one. I'll speak about Gloomesh very quickly later on. And what's interesting here is that I will show you that you can test this VM integration using a Docker container as well. And it makes your life a lot easier if you want to put in place like automated testing and so on. It's very convenient to be able to simulate this VM as a container. So I'll show you how we start from the Docker container and we put in place all the prerequisites to join the mesh. And I won't go through all the details because obviously you can find them in the Istio documentation. If you go to virtual machine installation, you'll see a lot of the things that we will do in the demo are described there. The difference is that instead of running this command in the VM, I will run them in a container and we have to adjust a few things just to make it work. But the baseline for the demo is here. So let's jump in the demo environment. So I have like four windows here. You can see one where I will prepare everything for the VM. And then what we will do is that we will start with an environment where, as I said, we have two Cubans clusters here and I've deployed the booking for application on both clusters. And we are going to start with this situation where when I send a request on cluster one and I try to go to the product page, then the product page is going to send request to the different services and we will play with this detailed service. So we will have like at the beginning, we will try to have the product page running in a VM and that's where we will start. We will deploy all the prequels so that the VM becomes part of the mesh and we have the product page going to the detailed service running here. And then later we will show how we can migrate seamlessly to Kubernetes, so migrating this app from the VM to Kubernetes slowly, like taking a canary approach. And then at the end, I will even show you how you can have some requests going to the VM, some requests going to the pod locally and some even other requests going in another cluster that is made very easy with the blue mesh. So let's jump into the demo now. And as you can see here, I have like my booking for application running. But the details, which is this part of the demo of the of the page here, we will make it run in a VM. So to do that, I'll just jump here and you see I will call my VM, VM1. I will use the namespace virtual machines. I will create a service icon for this VM and I specify which network I am on, which is the network of the VM, like network one is the network corresponding to my first cluster and the VM network is the network of my VM. That means that I will use gateways to communicate with the clusters. So I just like to copy and paste here. Then I create a working directory where I will create all the files that need to be transferred to the VM, which in my case will be like a Docker container. I will create a namespace for this VM and service account. So the service account that will be used to generate a certificate for this VM is also residing on Kubernetes. And then you have this notion of like a workload group that you can use if you want to dynamically register VMs, but here we are just going to create this DML and we will use this DML as an input for the Istio CTL command line that will prepare all the files that we need for configuring the VM. So I'm just going to run this command here. And what's interesting is that we can take a look at what has been generated for us and you see we have like a short living token. So that's kind of a way for the VM to identify itself to prove that it adds access to this service account. And it will be used to be able to get the certificate from the Istio control plane. And then later on the certificate will be rotated and every time the VM will identify itself with this certificate, not with the token anymore. We have also some information. You can take a look at what you have here, but I won't go and cover everything. As I said, it's mostly documented, but you can see information about the networks and the name of the VM and trust domain and so on. So then now I'm going to start Docker container that will be, we will consider as my VM. And you see here what I do is that I use the image, the Docker image of the details cells. So that will be the baseline. It will be easier for me to run the detail service because that's already what this image provides. So I'm going to just run this image. And again, you can consider it as a VM. It's not part of the Kubernetes cluster. It's running as a Docker container like Kain is doing. So if I do Docker PS, you can see I have my three Kain clusters and I have my VM here. So now I have my VM as a container. I'm going to just deploy some prerequisites that are needed for deploying Istio, the Istio Agents. And I'm going also to prepare the OS file that I will need so that the VM knows how to contact the control plane. So that's the IP of my gateway to reach IstioD. Then here I'm going to just, you see, like, transfer the different files that I got when I ran this command line here. So just, you see, just doing like Docker exec to copy some of the files when I created, you see, when I started my container, I just mapped this directory here so I can just like copy internally. Then I'm going to deploy the Istio Sidecar proxy here. So it will be running directly in my container. And again, copying a few other files that I had before, copying the OS file that contained this entry and changing some permissions on directories. And at that point in time, there is one special tweak. So the way it works in a recent version of Istio is that you have a DNS proxy running within the Istio Agents. And there is an IP table rule that redirects all the DNS requests to this proxy so that it knows about the IP of the different pods or in our case will be like the gateway and so on. But by default, the DNS server is this one, which is kind of a local IP as well. And that prevent this IP table rule to work properly. So I'm just going to change the reserve.conf of this container so that it just use like the Google DNS and the IP table rules will work properly. Finally, I'm going to start Istio Agents in this container. So now I have like my container that you can consider as the VM. And if everything works well, and I look at the cluster's entries here, I should see information for how to reach my services running in the cluster, like for example, if I want to reach the product page. And you see here, I see if I want to reach the product page, this is the IP and this is the port. And as you can see, this is the same as you can see here, because I use the Istio Ingress Gateway because my VM is in a different network. We can also check that we can access the product page from the details, which is not really what we want to do, right? Normally the product page tries to reach the details, but it is just to show you that the communication from the VM to the services running in Kubernetes is fine. And you see I have a 200, okay. And everything is secured, by the way, I didn't say that, but everything is secured with MCLS. If I would go to cluster one and the Istio system namespace, I would see that there is a pure authentication that has been created here, which enforced StrictMTLS. So here we show that we can get like StrictMTLS and encryption between the VM and the pod when it's the VM that initiate the connection. And we are able to reach the services that are running in Kubernetes. Now we are going to start the details service in this VM. And we are going to create a service and a workload entry so that the pods that are running on Kubernetes, they know how to reach the details service that is now running in my VM. And you see here, the most important part is here, you see the VM IP, which is basically the IP of my Docker container. And I can just show you that here. So we need, so it needs to know, you know, that this is running here. So I'm going to just create the service and the service entry. And finally, what I want, and this is where we start to use BlueMesh, we are going to use like a traffic policy. It makes our life easier because I could do that directly with Istio create a virtual service and, you know, destination rules and so on. But BlueMesh makes that easier for me to do so. So I create what we call traffic policy where I say when I have a request coming from the default namespace and going to the cluster, going to the details service on cluster one, what I wanted is that I want to send these requests to the VM in state. So the product page will send the request to the details service on the VM because the product page is re-diting on this namespace. I'm just going to create this policy here. And what I want to do as well is that I want to see if I do like a tail minus F. I want to take a look at the access logs here. So I can see the access logs in the different places. So here is the details spot on cluster one, the details spot on cluster two and the details spot on the details VM. So because of the rule I created here, I should expect now the access logs to change here right on this place. So I'm going to just first of all try and see if everything works well here. I can still see my details and should see here. So that's good. It's going to the VM. That's easy. I can also even go to Kialli and I can see that it's going, you'll see the rating and you'll see the VM. So you see the product page is sending traffic to my VM. And I can also even go to BlueMesh and see that I have my current policy which says when I have workloads here in the default namespace that send request to the details service then everything goes to the VM. So that's the current state. Now let's say I want to start to send some traffic to the details running on cluster one so that I can start to seamlessly migrate from my legacy environment to my container. So then I would do something like that. You see I say I update my traffic policy and the difference here is that you see I only send 75% of the request to the VM because I start to send 25% to the service running on the cluster. So I'm going to update that and here again now I should see some of the request going here and some of the request going there. So I can go back here and refresh and I should see here very quickly some access logs showing me that you see here and here. The requests are going now they are spread across these two clusters and in Kialli I can also see that you see it sends some of the request on the same cluster in the details and some of the request in the VM. And again if I go to Blumesh I see that as well right 75% are configured to go to the VM and 25% and go to the details on cluster one. And now what's quite nice is that I can also refresh all the stuff here and I can create a nice policy. First of all I can say I want now to go and switch completely to Kubernetes so that now all the requests will go only here in the clusters. They are not going in the legacy environment any any more. And again I can just refresh that here and I should be able to see my access logs moving just there. So just proving that everything goes on the right place like I was expecting. The migration is done now from my legacy environment to Kubernetes. I can see that here as well all the requests go now to the details here they are not going to the VM anymore. And I can show you like a small bonus that and that's also another very nice thing you get with Blumesh is that it makes your life a lot easier when you want to do like you know cross cluster communication. I could have done like an example where I would configure a failover if I cannot switch locally I go to the other cluster but here just to make it simpler what I did is that I create a traffic policy where I would say 50% go to the VM, 25% go to cluster one and 25% go to cluster two. So now I spread my request not only between my VMs and my pods on cluster one but I can spread my request between my VM, my pods on cluster one and my pods on cluster two and everything as you can see very easily by you know just creating like a traffic policy like that. So I just go there I apply this and now I can refresh my app like click many times here again I can see the spread is done here and you can see the logs moving everywhere and you can see you know Kiatty will also show you like a nice picture where you would see all the requests going you know across all these different environments and even like depending on how long we wait for the for the matrix but we will also see even like the matrix showing that this is going through you know all the clusters and normally you should have like a cluster two box displayed somewhere here it's just that it's not shown right now so let me refresh a little bit more and we should see like the details here the details running in the VM but also the the details from the from the other cluster like you see here just like to be a bit of time to refresh but you see now I also see like the request going to the other cluster and that's possible because we consolidate all the matrix with glumesh as well and we can present them today you consume them the way you want like in Kiatty but tomorrow it will be even like integrated in the in the in the glumesh UI so as I said you know I use glumesh in the in the demo to make my life easier for managing the traffic but you can also use it like for discovery so it discover all the workloads on all the clusters instead of having each cluster discovering the workloads on all the other clusters this discovery is done by glumesh it's more secure and it just like make the other clusters aware of that you have the failover I spoke about before you have the ability to have like consolidation of the matrix like I said but also being able to do that with the access logs being able to have like a global airbag where you can define who can do what across all these different clusters we have like a very nice support of web assembly there as well so if you're interested you know you can go on our website and on our Slack channel and you can you can ping us so thank you very much for attending this session I hope it was useful and and I think we we now have some some time for Q and A


Good morning My weasel friend Good morning to you my other friends. Oh, it's right out here. Whoa What year is it guys looking at me? I'm gonna stare back at him He looked away Don't stare at me, especially in the morning. What? Good for you guys. You keep watching So we're here in Atchison, Alberta, which is just west of Edmonton, Alberta in Canada And I'm about to go into West Edmonton and pick up a load of lumber that is going down to Schiller Park, Illinois Which I believe is the part of Chicago If I'm not mistaken, and I don't know if I'm going straight through going straight there Excuse me or if I'm taking it there next week because it says in my computer that they only want it there on Monday like next week And it's Tuesday today. I could be there Thursday. Oh I was too early to think I got to wake up and go wash my face and clean myself up I literally I just sat down here put my jacket on Haven't even walked the weasel yet.  I'll talk to you more a little later Welcome don't forget to subscribe to my channel I make videos every day while I'm on the road traveling across all of Canada and the United States It'd be great to have you as part of the group And off we go Someone in Chicago is counting on us to bring them their Canadian wood I just got to figure out when they want it there. I'd like to go straight there Britt and I have another or Britt technically Britt has another fertility appointment on Monday It's like I said, it's Tuesday today. So I want to be there for Monday But if they want this freight in Illinois on Monday Well, that's gonna cause some problems cuz I can't be in in Chicago and at home at the same time. I Definitely don't live in Chicago. I don't know if I would even if I had the choice Chicago you scary I like where I live though for the most part I wouldn't run I wouldn't really live anywhere else Where I live I'm happy and content. I'm not a city guy I'm gonna tell you that every you know every couple of days. I like to remind you no cities for me unless I absolutely had to All right, so we don't have to go very far.  Oh, well, it's our turn now. Gotta follow this little forklift guide at the back Where he's gonna load me up with 48 feet of lumber what that's gonna look like I Don't need to tarp it. So that's the best part. I'm gonna be delivering it into Chicago on Monday And they're getting a load back home, so I'm gonna have to miss Brits fertility appointment But I do have my own fertility appointment on Saturday. I'm gonna be able to make it to that. So I'll be back home on Tuesday But for now we're going home. We'll be home tomorrow Whenever we get there a little over a day's drive from here probably tomorrow afternoon tomorrow evening And then we'll be home till Saturday evening Because I'll have to be in around the Chicago area Sunday night I don't want to sleep in Chicago, but it'll be close by Sunday night Now where do you want me bud? Right there right there It's good to me bud So I've got my old tire up here. This is the one. I'm bringing back getting my money back for this. This is Garbage tire looks round. I believe me. It's not round once you put it on the truck and start rolling down the road So that's the old one I'm gonna tie it down once I know where I have room for it after he loads me up here He said he doesn't need this space here.  I got you like shrubbed in there and It runs so smooth So while we're talking tires These drives that put on the back a little while ago, we're doing very well The recaps I'm really happy with them the rear axle wears down faster than the front axle But that's why we rotate them when the time comes but These are gonna do great in winter and so far, you know, they're doing all right. I was never a fan of recaps I'm still not a fan of them, but I'm testing them out for you guys. All right, and because I Couldn't afford the brand-new tires When they came out and these were a lot cheaper But I'm willing to give them a shot. All right. I have an open mind of mine give me one shot And so far they've been doing really good for me. So We'll see what happens. I'd like them to last two years yet Well, I guess technically I could have afforded to buy fresh rubber. We call it virgin tires but I had just dropped, you know, $20,000 into our roof in our in our house and Another couple of thousand just got put into it for all these repairs. I just done it's been an expensive year But we've gotten a lot done. We've made progress. We haven't stood still. We've taken steps forward, which is important We didn't get knocked back. We've been moving forward So I decided to save some money That's what I should have said I wanted to save some money and try out the recaps They've come a long way in their technology They don't just fly apart. I think a lot of people think that they just fly apart all the time I know a lot of guys that run retreads You can't have retreads on your steers. Your steers always have to be virgin rubber But on the on the drives and the trailer you can have recaps if you want Which means they take an old tire and they put new tread on it So you could also call it a retread retread recap And they're a lot cheaper Now they may not last as long they may wear down faster But I'm trying this experiment right save myself some money and hey, maybe if these tires are good Well, then I just found a way how to save a lot of money down the road because you got to change your tires every couple of years, right? Maybe I'll do it again. If it turns out that it worked really well. I don't know I don't know what to expect. There's a lot of people who think that they're they're really bad that they're a terrible idea There's a lot of people who swear by them that use only retreads on their drives As long as you don't buy the Chinese tires, okay? You buy the Chinese tires. You're just asking for trouble Don't even bother. Don't even go down that road. Don't buy anything from China No, if that's China, you know, you don't watch my videos. Anyways, you're not allowed to watch my videos Are you leave me a comment if you're in China right now and let me know what VPN you're using I know you're not allowed to use the internet out there off topic off topic rabbit drop But yeah, watch my videos and see how these tires go I'll keep updating you on them over the couple over the next couple of years Move through to do I bought my retreads from West End tire in Winnipeg and apparently they have a really good reputation for making really good tires But I don't know. We'll see what happens. We'll see what happens. It doesn't work out well Well, then I'll just never do it again, you know, but I've got to find out for myself. I think it'll be fine though I think it'll be fine from what I've heard from all the stories. I've heard I won't have a problem How long have you guys had this fingerprint on your face? Guys need to clean yourselves off You're still there. There you go Now you can see Load it up and off we go We're all tied down. I hope my weights are good I'm definitely not overweight to be in Canada, but I might have to adjust it at our yard to be legal for the US Sometimes it's tough to get it just right when they don't have a scale at the shipper I sort of just got to go off the Off the gauges off the air pressure gauges, right? Oh, there's no warning that there is a bump there. Okay What was there? I'll run it over the scale and if something needs to be adjusted Well, then we can do that at our yard. There's another bump Construction zone. Okay, so we got to the east side of Edmonton here officially officially begin the day a little late, but That's okay at least we're feeling good trucks running feeling good I'm gonna put it in gear Not just roll forward and neutral go a lot faster when I put it in gear It's over here on this side of the parking lot now didn't come here regularly. I wouldn't even notice it here I just go out the end. This is the one way you're not supposed to enter here As you can see it would cause a bit of a kerfluffle. There's only one line. Can you guess where we are? This is where we usually stop I was lately. This is a scratch Little flying J Because I could fuel up tonight I don't have to do it in the morning. I like stopping at this little place here I don't know Small not a lot of people stop here. Why can't these guys park straight though? Look seriously Who's teaching people how to drive in Canada? I Don't know why drivers up here just cannot park straight for the life of them I'm not saying all drivers, but y'all know who I'm talking about You go to a truck stop in Canada. You'll see Trucks taking up three spots part crooked part completely sideways Pumps that are so narrow Careful when you come through here. Tank just starting on the second one Get it. She's gonna take quite a bit. She's pretty thirsty today so Got my tire Tarps up here. So the way we distributed this weight was we put four of these stacks of two by four by 16s It's a 16 foot 2 by force for on the front And we got three after that Now on the very back we got two and the weights are pretty well evenly distributed. I have about 32,000 pounds on those axles right there Look at the front over there. I got about 33,000 pounds on the Full of fuel 604 liters We bought today cost us Seven hundred and sixty seven dollars how much fuel did you put in your vehicle today? We almost hit eight hundred bucks That should last us till the day after tomorrow What a great day this was man. We're off your phone man.  We're here in the light a little bit. Come over here Now over here. Can you see me? Can you see me here? You're lighting good. Can you get some new lights in here, man? Great day great Don't tell the good people anything. Yeah, really? Yeah, he's he's he's he's he's he's he's he's watching guys and gals and dogs So, yeah, this vlog comes to an end. I'm sorry did I smack your nose? That was an accident All right. Well, I guess we got to take you out one more time yet. Hey, I'll go outside One more time then I'm gonna go back there. I'm gonna sleep Well, I showed you guys this yet What's like check this out before we go outside on second check it out I guess got myself. I've been meaning to show you guys this This just goes in there It goes further back with the shirts are in the way right now And then while I'm sleeping or sitting here. I Can watch TV before bed and also when I have the table set up here You'll see it a bit. I can have my most and stuff on the table here and use this screen hook it up to my computer and Edit my vlogs on the big screen Surprise yay I'm excited. So thanks for watching.  I'm home for Thursday Friday and most of Saturday and then Saturday evening We head towards Chicago. We arrived there Sunday night deliver first thing Monday morning get a reload and come back home And that's as far into the future as I know Don't forget to subscribe means a lot to me if you do I know a lot of you who watch this video Just watch it, but you don't subscribe. So if you want to do me a big favor Please go ahead that subscribe button And if you really feel like it hit the bell beside the subscribe button as well That'll give you a notification when I upload a new video. So Thanks for hanging out. We'll see you tomorrow


Live from New York, extracting the signal from the noise. It's theCUBE, covering RapidMiner Wisdom 2016, brought to you by RapidMiner. Now, your hosts, Dave Vellante and Jeff Brick. Hi buddy, we're back to wrap up. RapidMiner Wisdom 16, we're here in New York City. Day long event, actually started yesterday, last night, the place was crawling with data scientists, Jeff. Good event, a lot of good thought leading conversations. Clearly, this industry, what do we want to call it? Big data, predictive analytics, machine learning, Hadoop, et cetera, evolving beyond the tire kicking phase. We're well beyond that. I think we were beyond that last year. Really into the, okay, how do I get more value out of this? We know this is an imperative. RapidMiner, as a company, fresh injection, I think it was 16 million? 16, yeah. New cash from Nokia Ventures. So that's key, I think that's really important because funding is drying up. B rounds are getting very difficult. You talk to you guys out in the West Coast. Furrier has his nose to the ground on this stuff and it's very clearly the sentiment is changing. People are nervous, obviously you see that in the stock market, so having a fresh injection of cash, obviously is important because now you can focus on the business. New leadership in Peter Lee, Ingo, visionary leader. So good story, a big install base. I think obviously the challenge of course that RapidMiner and companies like that with that open core face is how do you translate that and convert that into paid and add enough value to do that. So version seven is clearly designed to help that, expand the platform and expand the monetization model. I mean that's the big question is when the dust settles, who's gonna be standing, making money with a viable business model, right? You got, these guys are more, I would say, Cloudera-like than they are Hortonworks-like and that Hortonworks is selling just the subscription to the maintenance. Cloudera has an open core and then sells value modules on top of that. That's really precisely what RapidMiner's doing. The former model, the Hortonworks model is predicated on massive volume. They're in that for the long game. The Cloudera model, you're seeing their private company, they obviously have a lot more cash from their private investments can stay a little bit longer. You're seeing companies, as we've talked about many years in theCUBE, staying private longer, not having to go public. It's tough being a public company, right? Especially now, Hortonworks just had to do another raise, they beat revenue but they had to do another raise. Had to raise a hundred million. We saw that coming, George Gilbert predicted that and so it was pretty obvious. But they're in the game, now they have fresh cash. It's going to be really interesting, Jeff, when the dust settles to see who's standing and these guys got a good, strong community, a core to build from. What's your take? I couldn't help but think of Michael Dell over the last couple of weeks as the stock markets had a rough entry into 2016 and him smiling like the cat with the canary going private and not being exposed to this kind of whipsaw and massive changes and evaluation. I think what's interesting is this pursuit of the citizen data scientist. How do you get the data science out of the hallowed halls of the big brain PhDs? How do you get it down to the analysts? How do you really drive, as I think, Paul talked about, building a culture of analytics and that's where I'm really curious to know where are the entry points? Who are the people? What is the function? What is the application where you can start to move kind of mid to your decision makers into data driven decision making or they can really start to pull that in. The marketing example was interesting because you start to hear a lot of that in marketing. We don't cover a lot of pure marketing events but marketing is one of these scientists that's really moving now because they have the data to more of a data driven execution as opposed to the classic marketing, 50% of my marketing budget is wasted. The only problem is I don't know which 50% it is. So I think that pursuit of the data driven citizen data scientist is really important and I think that's really going to define it because that's the only way you're going to really grow your TAM, that's the way you're going to really bring a lot more people into this portfolio, a lot more people using the applications. And then the other thing that will be interesting to see how it sorts out is the ecosystems and the continuing shifting sands in the ecosystems. Clearly you have to have an ecosystem whether you jump on one like at AWS or pick your favorite big vendor that pulls along the wave or you can create your own. I don't think RapidMiner is big enough to really create their own, maybe they can around the open source piece of it, but ecosystems are so important in plugging into a system of other applications, providers. It's interesting, Peter said they have no delivery capability, right now they depend 100% on their partners. So that's goodness in that it's a clear value proposition for somebody like PWC. And if they're here, obviously they wouldn't be here if they didn't see the opportunity to build a really big practice. But to me that's it, Dave. How do we get out of the data scientist? How do we get out of kind of the unfulfilled promise of traditional BI, which I think people love to still put that in a bucket and get more data driven decision making broader into the company? So we've been on this theme for a while now of systems of intelligence expanding on Jeffrey Moore's concept and in our world it's really when we talk to our practitioners it's all about bringing analytic and transaction systems together. Leveraging the systems of record and evolving those into systems of intelligence. Not creating separate bespoke systems of insight. Really bringing those two worlds together. And speaking to George Gilbert, some of the things that he's going to be focused on is helping practitioners look, think about machine learning in the context of focusing on both business outcomes but at the same time improving their analytics capabilities. And they're complementary but you don't have the resources to do all of them. So how, based on your business requirements, can you sort those out? How do you prioritize projects? Should you look at the business impact and how do you assess the technical capabilities and the risks associated with that? Still a lot of customization in predictive analytics and machine learning. How can we move toward and leverage more commercial off the shelf software, clearly rapid miners trying to create that platform but still a lot of customization going on. How do you protect your IP if you're bringing in outside consultants? Talked about PWC here, world-class consultant. How do you deal with that? Could you deal with that contractually? I mean, you have to be very careful with when you bring in professional services for that customization. How do you protect your IP? You know the people skills we heard from David Weissman today, the organizational models centralized versus distributed, hybrid with a lean towards centralized. George talking about helping customers sort of sort through that with frameworks that allow us to sort of better understand what the right fit is for your particular situation. So that's where a lot of the research is going to be focused this coming year. Obviously theCUBE plays a big part of that. We're expanding our networks. theCUBE alumni network is a huge part of that. We did 77 shows last year. We're kicking off this year, obviously in our big data wheelhouse. We've got I think six big data events planned this year. We've got Spark Summit East. We'll probably do Spark Summit West. We've got the big data SV and NYC that we do every year. That's four. Then we've got Hadoop Summit and San Jose. We're doing Hadoop Summit in Dublin, which I think is in April. So that's at least six big data shows independent of the other ones where we go. It's where it's a vendor show, like a Splunk for example, or a Tableau. Hopefully those guys will have us back. So lots of focus on big data. Obviously infrastructure. Our tradition, Stu's doing the Gillette Stadium today, the V-Tug, the core, VMware, audience. Obviously Oracle is infrastructure and apps. The service now shows. And of course cloud, big, big cloud emphasis. We do reinvent every year as well as other cloud shows. We've got IBM Interconnect coming up, which is a big cloud show. So talk a little bit about so the year plans for theCUBE in 2016. So we're going to continue to do what we've done and we're going to try to do more. So as you said, we're going to continue our real big presence in big data. We're going to really continue to go in cloud. I think we're going to pick up a couple of new AWS shows. We're talking about potentially in Chicago. I don't know, Dave, we've ever done a show in Chicago with theCUBE. AWS Summit is going to be there. They have their regional shows. We've done San Francisco for a number of years. AWS Summit, I think we might do New York this year. And then the other opportunity is that we're looking at is a continued global reach. We just came back from HPE Discover. In London, not too long ago, you mentioned Dublin. There's some other opportunities we're working on that we have not closed yet. Keep an eye on SiliconANGLE.tv. And then we'll continue our application focus as well. We're starting to see this, I see big data is kind of this infrastructure layer thing. And I think eventually we're not going to talk about big data is big data. It's an enabler. And now we start to move to the applications. And the ones that are coming up next that we haven't really covered per se specifically is Internet of Things. And Internet of Things is defined by what's going on automotive, what's going on in wearables, what's going on in sports. There's a lot of now applications that have been enabled by computing power on tap, cloud, this really crazy connectivity that we're seeing now on the wireless space and the applications that are going in over the top of that. The other thing, we were at the Ford launch of their innovation center in Palo Alto. I'll actually be talking to Ford shortly and we've talked to Jim. What's fascinating is the whole transformation in the automotive industry around thinking about the whole experience, not about car ownership.  You may take a car sometimes, you may take a bike sometimes, you may take the bus sometimes, you may take the train sometimes. The fact that somebody like Ford recognizes the importance of changing the way that they look at transportation is pretty significant. We talked to GE in the context of the Predix cloud for Internet of Things, which is going to be coming down the pike. Bill Rue and Tim, I think he's got almost 1,000 people in San Ramon, which is not an easy place to hire. In the Bay Area, we're really talking to them about even within the jet engine group, they're thinking about the entire experience from the time you leave your house to the time you arrive at your destination. Oh, by the way, there's an airplane in the middle there that's using a GE engine to get you there. But the whole Predix cloud and what General Electric is doing, I think we're really going to see this huge push on IoT. The other thing that I think is really fun, similar is the virtual reality and seeing more and more applications. We did an interview with Spacetime Insight where they're using a combination of virtual reality with like a heads up display and Internet of Things in power grids and power stations so you can look at a piece of equipment and it tells you it's running hot, it's running cold, it needs maintenance, this one's fine, hey, pay attention over here. So I think that's another area that we're going to see. It's, again, it's a combination of these other technologies coming together and it's big data and it's cloud, but now I think we'll see a lot more in the application layer and really ways people are transforming their business and I'm really excited about some of those opportunities. I'm glad you brought that up about IoT. So George Gilbert's been doing a lot of work there along with David Floyer talking to Ingo off camera and basically there's the piece of, the humans are the last mile narrative and that's certainly true for much of the predictive analytics but a lot of it is going to be machines talking to machines and predictive analytics fits in there as well. When's the window mill going to break? I don't want to have to do a truck roll every time to figure out when that windmill is going to break. Ferry and I talked a lot about this at HPE Discover and basically of course you want to instrument the things but the things better be connected if you're going to instrument them because otherwise the data's going to be out there in an island and then of course what data actually comes back. So a lot of really interesting issues that we're working on and helping our communities understand. So we're a wrap, thanks very much for kicking off the year with me here. Thanks for coming down to New York once again. It's a pleasure, it's a pleasure coming out and the gents, Greg, Patrick Leonard, nice job, Bert back on the crowd chat land and all the team with Kristen Nicole and the writers and thank you guys for watching thanks for a rapid minor for having us here. So that's a wrap, this is theCUBE. Let's see, what's next for us? What is? Spark Summit. Spark Summit East. Spark Summit East, we're back in Manhattan. Mid-Feb, right? Mid-Feb back in Manhattan so look for that and as always thanks for watching everybody and we'll see you next time. Bye for now.