All right, good morning, everyone. I will have to do a confession. So this week at the OpenStack Summit Berlin, there were like 27 talks about edge compute. I actually counted them, and more than 30 on Kubernetes. So I tried to basically attract as much audience as I could by combining all the hot topics of the week. Unfortunately, I didn't manage to get a full room. I'm hoping that is because this is the last day of the summit. It's pretty early, 9 a.m. Anyway, thank you all for coming this morning. My name is Marc Rappoport. I'm a product manager in the contract business unit in Juniper. But this morning, I'm here to represent the TankStand fabric community. And we are going to talk about how to combine OpenStack, Kubernetes, and TankStand fabric to build an edge compute stack. Very briefly, who is familiar with TankStand fabric? Okay, I would say one third, maybe one fourth of the audience. How about maybe Contrail or OpenContrail? Oh, okay, I see that we still have some kind of branding recognition issue with TankStand fabric. Basically, TankStand fabric is a new name for OpenContrail. So let me give you a bit of history on what used to be Contrail, I mean OpenContrail that is now TankStand fabric. It's basically an SDN solution. And the objective is to provide connectivity and security for any workload in any kind of environment, whether we are talking about private cloud based on OpenStack, obviously, but also public cloud, whether it's Google, AWS, or Azure. It's not limited to IS environment, it provides the same set of connectivity and security services for containerized workloads, especially orchestrated through Kubernetes. And last but not least, TankStand fabric was recently extended also to cover bare metal workload management. As you can see, it's already a pretty mature product since it started five years ago. I would argue it's the most feature-rich commercial SDN solution today on the market that is based on an open source project. Back in the days, it started in 2013 as a startup called Contrail, which was acquired by Juniper. And when Juniper acquired Contrail at the time, they decided to open source it. And that was the beginning of OpenContrail. The original version was focused on the Telco Cloud NFV use case with a specific focus on how to integrate inside a Telco environment, leveraging all the standard BGP, MPLS VPN framework, and also building key capabilities like service chaining. So over time, the product was enhanced to cater with different orchestrators like VMware, providing support for Kubernetes, obviously. And this year, with the version five of the product, the scope was significantly enhanced to not only cover networking and connectivity, but also expand to providing an integrated layer of security and move beyond private data center to expand towards public cloud, like the three main public cloud players I just mentioned earlier, but also going beyond the pure software network virtualization layer by integrating also with the physical underlayer layer and providing the management of your data center fabric to natively extend the same set of services for bare metal servers. And last year when we decided to join the Linux foundation, that's when OpenContrail was renamed TankSendFabric. Hopefully, that clarifies for good the naming of the different projects. And so now there are multiple products actually based on TankSendFabric. The main one, I mean, being a Juniper employee is obviously Contrail, but there are two other companies who recently launched their own commercial product based on TankSendFabric. So we are currently hosted inside the LF networking next to a number of other open source SDN solutions like OpenDelight or ONOS or Datoplane projects like OVS or FIDO. What is unique about TankSendFabric is that it's the only SDN solution that combines both the Contrail plane and the Datoplane, since TankSendFabric includes a component called Virator and I'll go through it very quickly. Another thing to note is that we heavily contribute to a number of other projects that are also hosted inside the Linux foundation networking group. We are a member of Acreno and I'm going to talk a little bit about this. We are contributing a lot to DPDK and we also active members in ONAP and OPNV. So very briefly, as I mentioned earlier on one side, we have the Virator component which is a data plane which provides all the forwarding and security enforcement for the various workloads whether these are virtual machines, containers, bare metal servers, also potentially the same VMs or containers running in public cloud. TankSendFabric control plane itself includes a number of components, config, control analytics. I'll quickly go through them. And once you have this abstraction layer that is up and running, you can deliver a number of services across all these workloads, obviously the basic building block which is layer two and layer three connectivity through EVPN and IPVPN fabric, but also all the entire IPAM, IP addressing, DNS assignments of your workloads, cross, security, load balancing, service chaining all fully distributed on the Virator. There is obviously an analytics engine that is part of the solution that provides a visibility on every flow that is managed by TankSendFabric and there are obviously multiple ways to consume the product, APIs or UI and in the case of API, which is typically the main way to consume the product, that's the way all the orchestrators, whether it's obviously OpenStack or Kubernetes, ONAP, so on and so forth, this is the main way to consume TankSendFabric. So very briefly the architecture of the product. I mentioned earlier that we have this centralized control plane which is using actually BGP between the different control instances to provide HA and scaling. The control plane manages and program the Virator that runs inside the server through XMPP and it also orchestrates and configure your physical environment using a mix of all the standard networking protocols, BGP, MPLS, NetConf, EVP and the EXLAN, whether we are talking about the data center gateway or your top of rack switch. And what it provides is an abstraction layer where all your different workloads which are connected here, whether they are located on one server, the other server, whether they are behind the top of rack switch. On the left in the case of bare metal servers, you attach these workloads to virtual networks and all the blue ones, virtual machines or bare metal servers that are part of the same blue VN are natively connected between themselves, same for the red ones, and then you can define routing policies on how these virtual networks are connected between themselves and you can also define let's say service chaining saying I want all the traffic between the workloads that are part of the blue VN on the left to go through a specific firewall instance when they want to reach workloads that are connected to the red VN on the right. As I mentioned earlier, there are two main ways to consume the product, obviously there is a UI, but in a large production environment, typically the way to consume the product is through the standard APIs, whether these are the neutron or heat APIs in the case of OpenStack environment or using some of the native REST APIs of TankSend Fabric. TankSend Fabric has a pretty rich community of contributors, so we have a healthy mix of, I would say, one-third of vendors, networking players, all the main OpenStack distribution companies obviously are here, Red Hat, Canonical, Mirantis. And there is another third of committee members, which are mainly system integrators, software companies that build solutions around TankSend Fabric are integrated as part of a larger ecosystem or global solution. And the last third of the members are actual users, a lot of telco, as you can see, but not just telco, there are also a number of enterprise gaming companies, and some of these users are actual contributors who are providing and pushing code to the project. So if you want to have a quick feeling of the product, you can go to TankSend IO slash start, where you can deploy a sandbox in AWS of a TankSend Fabric cluster that is going to be orchestrated through Kubernetes. Now, just to obviously get a quick feeling, it's not meant to be used for any kind of real life environment. Having said that, we also have what we call a standalone, Ansible-based deployer to deploy TankSend Fabric. But typically the way users deploy the product is through the installers. We have done heavy work to be fully integrated with all the main lifecycle manager tools of the orchestration, HALM, where AT&T talked a lot about it during the last couple of days. They are investing heavily around HALM, airship, and all these set of tools that generate common life cycle management layer. Kola Ansible is another one. We've done extensive work to be fully integrated in terms of lifecycle with TripleO, which is the upstream life cycle manager of Red Hat OpenStack director, but also obviously Canonical and Mirantis. You can really pick whichever deployer solution you want based on what kind of orchestration you want to use alongside TankSend Fabric. As this talk is about edge compute, I just want to briefly mention that we recently joined the Ukraine project that is part of the LFN. That is the original blueprint that was published by AT&T, one of the key founders of Ekreno, where as you can see at the network control and data plane layers, there were a number of components that were considered to be in this blueprint. With TankSend Fabric, our ambition is to provide all these capabilities combined inside TankSend Fabric, whether it's about providing kernel-based forwarding, DPDK, SIOV, SmartNIC, which is not mentioned here, but which is also supported by TankSend Fabric. There is actually a very active group of SmartNIC vendors that are contributing to build a common set of offload APIs that can be shared across the SmartNIC vendors to basically accelerate the router data plane. And here are a few more pointers on how to get more information on TankSend Fabric if you want to get involved. OK, so let's talk about edge compute now.  There were a lot of presentation on this topic this week. I'm just here reusing the framework that was built by Acreino to identify the different use cases for edge compute. And just to mention that right now, TankSend Fabric in the context of edge computing is focusing heavily on the, I would say, telco network edge, not necessarily on the IoT or UCP use case. This is more the focus, I would say, right now in the short term on how to leverage this combination of OpenStack, Kubernetes, and TankSend Fabric for an edge compute deployment. So keeping in mind this use case, what are the key requirements for edge compute? Basically, the first one is having a centralized control plane. Why? Because in these remote locations where you don't have much resource, you cannot afford to deploy a full-blown control stack in each and every small location. Not only that, but that will also create a huge amount of control plane to manage if you have, let's say, thousands of tens of thousands of COs or base stations. If each of one has a full-blown control instance, you can imagine the pain it would create to manage them. Another key requirement in edge compute is being able to support containerized workload. Yes, NFV started heavily on virtual machines and virtualization, but now we see that more and more VNFs are being containerized. And a good reason to use that in the context of edge compute is that typically a container has a smaller footprint than a full-blown virtual machine. The third requirement, always in the same context of how do I deal with the fact that I have very limited resource is how to have a data plane, which in the case of Tencent's Fabric is V-Router, how to have a data plane which has a small footprint in terms of CPU and memory requirement. Fourth one is multi-tenancy, which is especially needed in the context of 5G for things like network slicing, how you can leverage the same physical infrastructure, partition it into multiple virtual instances that are dedicated to a set of different internal or external customers, whether we are talking about MVNO in the context of 5G or other types of, let's say, enterprise customers, enterprise VPN, for example. And last but not least, security, which is a very strong requirement, even more than, let's say, regular, typical, existing NFV. Because when we are talking about distribution in the case of edge compute, we are talking about small sites which do not necessarily have a lot of physical security. They can be easily or much more easily accessed than a large centralized data center. And also another key difference for the security that in some cases, the service provider that is deploying the service might not own the entire access network. They might need to lease capacity from some local, let's say, small sales provider. And so, as they are not using their own network, they need to include the traffic to protect it. All right, so let's talk about the first requirement, centralized control, and how we solve this requirement with Thanks.10 Fabric. So the main concept is basically to centralize all your control functions, obviously all the compute orchestration, whether it's OpenStack for VMs or Kubernetes for containers, and also all the control functions of Thanks.10 Fabric itself in your large regional data center. And then what you distribute and deploy in your remote COs is just all the data plane-related functions. Now, how does that work in practice? So bear with me, this is a bit of a busy slide here. As I mentioned earlier, what you have on the top right is inside your large regional data center, you have all your control cluster, typically a cluster of three instances for HA and scaling. In the case of Thanks.10 Fabric, you have this configuration control analytics cluster that manages both the local data center gateways using BGP peering that you see on the upper right, and XMPP protocol that I mentioned earlier that is used between Thanks.10 Fabric control plane and the VRouter data plane. What is new in this diagram that you don't see in a regular, let's say, data center-only environment is you have a number of extra instances of control plane, which are the control pop 1, 2 and 3 at the top. Basically, you have a number of virtual machines that you deploy in your large centralized regional data center that I use to manage all the routing and security control information for all these pops. They do it centrally, again, by building the same BGP sessions to the remote gateways that are deployed in the small pops and XMPP sessions towards the VRouter of the small compute nodes which are deployed remotely. One of the key values of this model is to allow really optimized routing while you don't have to send traffic between, let's say, two workloads between, let's say, in this example, the container that runs inside pop 1 needs to send traffic to the virtual machine that runs inside pop 2. Traffic is not going to go back and forth from pop 1 to your original data center and then back to pop 2. Since you have a full awareness of the routing topology of your NPRS-EPN network, you can optimize the traffic flow to go directly from one local site to the closest local site. Now, let's talk about how do we manage containerized workloads in TankSend Fabric. First of all, there are two main touch points between Kubernetes and TankSend Fabric. On the control plane side, we have the KubeManager which basically listens to the Kubernetes API servers for all the new events of pod being deployed on the specific compute nodes, let's say. And on the data plane side, the integration point with the KubeNet that runs in each compute node is through the standard CNI plug-in. And then the Virara replaces the KubeProxy. So these are the basic building blocks of the integration of TankSend Fabric in Kubernetes. And then each object that is specified in Kubernetes is mapped to an equivalent, namespace maps to a project, a pod maps to a VM in the context of TankSend Fabric. Service will map to an ECMP load balancer. I'll go into a bit more detail, both for service and ingress. Which is a layer 7 load balancer. Contrary to service which is a layer 4 load balancer. Ingress maps to an HAProxy instance. And the Kubernetes network policy is mapped to a security policy in TankSend Fabric. So just a quick clarification for the people who are not fully familiar with Kubernetes terminology. The difference between service and ingress. So service in Kubernetes is an abstraction to group a logical set of pods that deliver a service. Basically they are all used to provide HA and scaling. And what TankSend Fabric provides in the context of a service construct, it implements it by doing layer 4 based load balancing natively on the VR. So this is fully distributed. You don't need to send the traffic to some centralized processing points. On the other hand, ingress is typically an object that is visible externally. And that is used to do more granular type of load balancing all the way to layer 7. For example, to do URL based load balancing, sending one part of a website to another service, another part to a different service. And the way TankSend Fabric implements an ingress object is by spawning by default an HA proxy instance. Which will do this layer 7 load balancing. Having said that, this is fully configurable. And you can use the load balancer of your preference, AV load balancer or whichever other mainstream load balancer of the market can be used to basically implement ingress. Okay, this is a bit of a busy slide. There are two main models to have coexistence of virtual machines and containers, basically OpenStack and Kubernetes inside the same environment. So the first model that is described here is a model side-by-side model where you have your virtualized machines which are deployed by OpenStack. And you are running Kubernetes directly on top of bare metal. And so what you see here, you have your OpenStack domain that runs on one side all the control components, OpenStack, TankSendFabric. And on each compute, you have your VRouter, KVM that provides the virtualization layer for your VMs. And then NovaAgent basically talks to VRouter agents which then programs VRouter to implement all the forwarding and security policies. On the other hand, you have your Kubernetes master cluster and the Kube manager that listens to the API server. And in terms of running your actual pods, same thing you have VRouter. Here you see that the pods are directly connected to VRouter since they are running directly on top of bare metal. And inside each compute, the minions, you have your kubelet that talks to the CNI plugin which itself programs VRouter through VRouter agent. Now what we often see is the need to run Kubernetes not just on bare metal but inside virtual machine. And that's what's called the nested mode. And that brings another layer of complexity because by default what you would need would be two different layers of SDN which would also create two layers of encapsulation where the traffic that would exit from a pod would go through a first tunneling to get out of the VM. And then when it would reach the router that runs directly at the host, Linux operating system would get another layer of encapsulation. So not only would you have to manage like two separate planes of encapsulation but also two layers of tunneling. So the way we solve this challenge in TankStand Fabric in the nested mode is basically when your pods are running inside a virtual machine, what we are doing is just instantiating a VLAN ID to separate the traffic that comes from different pods inside the virtual machine. And that's only after that when the traffic reaches the router that we apply the regular layer of lookup, tunneling and forwarding outside of your compute server. And that's how you can have coexistence of virtual machines and pods running inside other virtual machines on the same compute server. That's a very busy style. I think I'm going to have to work on simplifying it at some point. Okay, one just quick comment on service chaining. Service chaining is a key requirement in NFV and there are many different scenarios that you typically have to deal with. Have a chain of multiple VNFs that you need to steer the traffic through between your different virtual networks. You typically also need to be much more granular than say I want to send all the traffic between these two VNs red and green through the same set of services but say I want my HTTP traffic to go through some kind of HTTP proxy optimization and the rest of the traffic to go through another service chain. The reality is you don't have one virtual machine that provides your VNF service. You're going to have a pool of VNFs that are grouped to provide logical scale out. And so you need to be able to balance across these pool of instances. And the new challenge that the containerization of VNF brings is how to provide service chaining for containers. And here the issue is that Kubernetes itself doesn't have a construct to identify interfaces. By default, a pod is single attached. And service chaining typically requires at least two interfaces, two logical interfaces, to identify the traffic that comes from your left virtual network and that needs to be sent to your right virtual network. So what we did was extending Kubernetes capabilities using CRD to be able to support more than one logical interface on a pod. Which will then allow us to reuse and leverage all the service chaining capabilities that were already available inside the product for a virtual machine and being able to extend them to containerized pod types of network functions. Okay, next requirement. They need to have a smaller footprint of the router. So originally when TankSendFabric was designed, it was meant to be deployed in large scale data centers with potentially hundreds, thousands of compute nodes, if not more, in service provider environments where you would have tens of thousands of virtual networks, hundreds of thousands if not millions of IP prefixes. And that's why the focus being on scalability, obviously VRR by default has a fairly big footprint in terms of CPU on memory. It's expected to be deployed on a high end server like typically 16 to 20 cores dual socket with a lot of memory and VRR itself can easily use 4gb of memory, can potentially use up to 8 cores if you try to get the highest possible foreign performance using DPDK where you have to fully dedicate your cores which are going to be used 100% CPU for VRR DPDK processing. So the need was to, and we are just at the beginning of this journey, to put VRR on a diet to deal with these environments where instead of having these super beefy Intel servers you have these much smaller compute servers in edge compute environments. And so the first step is to decrease the amount of memory and CPU needed. And in the future what we will also work on is supporting not just x86 but also ARM CPUs which are much more common on these smaller platforms that are used in edge compute environments. Okay, multi-tenancy, very briefly. What we did in Tangsten Fabric was extending the connectivity and isolation model way beyond what default Kubernetes provides which is basically the default model that any pod can communicate with any other pod. The point was to provide connectivity to developers and not having to deal with any kind of security or isolation. So the first simple isolation mode that is available with Tangsten Fabric is a namespace isolation which basically does how it's named. Isolating all the pods that are from different namespaces but inside one spaces all the pods can communicate together and that's probably the most common scenario deployment but we can go beyond that and even isolate different pods of the same namespace and there are some specific scenarios for that. Let's say the equivalent of what is a micro segmentation scenario where you want each and every single individual workload to be by default isolated from all the rest of the world if you have very stringent security requirements. As I mentioned at the beginning of the talk all the infrastructure of Tangsten Fabric is based on the IP, BGP, MPLS, VPN framework so the way traffic of different tenants is isolated is by leveraging typical VRF type of behavior where each tenant is connected to a separate routing and forwarding table whether it's a virtual machine or a pod that's the way each tenant is basically isolated and how you can provide some kind of network slicing behavior. Okay let me cover the last requirement as we see for this edge compute use case which is security. So one requirement related with security is basically the capability to define in a very concise way your security policies and being able to apply them across multiple orchestration environment. Let's say you define a set of security rules in OpenStack environment that would be security groups that are defined across the different virtual networks and then being able to reapply the exact set of security filters across your different environments and that's what Tangsten Fabric provides within an abstracted policy construct where you can define your domains, the type of deployment, the geographic location, you can use abstract tags, labels that could be for example very useful in the context of 5G network where you have all the 3GPP interfaces for people who are familiar with the mobile world there are a number of interfaces to deal with, GI, S1, X1 you can easily tag all these interfaces with these specific names and then by default all the endpoints that share the same tag will be connected between themselves and they are going to be isolated from all the other endpoints and that's just the way the network policies in the case of Kubernetes environments are being translated as firewall policies on Tangsten Fabric. So a Kubernetes label becomes a tag, same for namespace, a network policy maps to a firewall policy, I already mentioned about ingress and service how these are basically mapped in terms of Tangsten Fabric construct and last but not least the need to encrypt your traffic as I mentioned earlier in the case of H compute you have to deal with higher security issues the fact that you are deploying your compute nodes on sites that can be potentially owned by a third party that is not managed by the service provider or you might have to use some least capacity 5G itself come with some new security requirement and that's where being able to natively encrypt the traffic between your endpoints which is what Tangsten Fabric provides where you can define the very granular policies to say I want to encrypt traffic between these two workloads all of this is implemented natively inside the router and it also comes with a visualization engine which allows you to basically see in real time what is the flow matrix between your different endpoints obviously the first layer of aggregation is the virtual networks you see the traffic matrix between the different virtual networks and for each virtual network what are the endpoints that are sending and receiving traffic allowed between themselves and just a quick pointer if you want more information on the project the code how to participate so hopefully you've seen that we already have today a pretty solid base to leverage Tangsten Fabric to deploy an edge compute use case and we'll keep adding more and more capabilities over time as we identify more use cases thank you questions I have a question regarding the constraints on the network between your central data center and the data center or the places where you run your pods because in terms of edge computing we can have constraints on that and in my case in the banking area we have countries that are unreliable in terms of network or we have overseas location very far from western Europe for example right so if I understood correctly your question it's about what are the constraints in terms of latency between your control plane and VR data plane what we typically recommend is a 50 millisecond round trip time and that's relatively aligned with the constraint you would have also on the compute side with let's say OpenStack itself between your Nova compute your Nova agent and other components between your centralized control plane and what's running in the local remote compute node that's typically enough to cover scenarios where your edge compute nodes are in the same geographical region whatever it means in terms of tens hundreds of kilometers not clearly thousands of kilometers but that's just giving you a rough idea of what is possible to do in this context hello about security and the tags and so on this is also open source so all the security and tags part I think I understand where this question is coming from yes that's part of the tanks and fabric product what is followed in tanks and fabric is what is called the open core model all the key building blocks and infrastructure components are part of the tanks and fabric project in the case of Juniper what the commercial contrail product provides on top is a new UI that allows you to define your security policy in a more I would say user friendly fashion but all of these can be implemented in tanks and fabric using the API calls for the small compute you show those figures is is it possible we have a roadmap to go to virtual CPEs with the VRouter so use it as a solution to use that sorry could you repeat the question solution because you have IPsec now yes like running VRouter on a UCP type of platform yes that's definitely part of the plan it's not available as of today but that's part of the plan I would say probably something for next year and then lost on Arista and Cumulus networks they speak with EVPN or is it still with OVSDB so we we started with OVSDB to basically integrate data center fabric we are now moving away from this model that's something that was done two three years ago now we move to an EVPN VXLan model which is becoming the de facto standard to program a DC fabric and that's what can be used for third-party networking switches any other question thank you very much


Valley, hard of big data, which is the O'Reilly Stratocons. I'm John Furrier, the founder of Sylvanango.com and joining my co-host Dave Vellante. We're at Sean Connolly, who's the Senior Vice President of Corporate Strategy at Hortonworks, on the executive management team at Hortonworks, which is pioneering the big data, fast follower to Cloudera, really putting out the open source and fueling the open source movement around the Duke. Sean, welcome back to theCUBE. Thanks for having me, John. So Hortonworks, obviously, is growing like crazy since the Yahoo kind of step out or spin out, however, was classified, has been growing like crazy. You guys are funded by Benchmark. Great success with your data platform that you guys have been initiating. 100% open source business model. And really, the credibility level is really high with you guys in the community for a variety of reasons.  Obviously, we cover the Hadoop Summit for you guys as well as Strata and Hadoop World here at theCUBE. So we're very intimate with what you guys are doing. So a lot of updates to share. So one, just tell us through quickly update on what's going on with Hortonworks as recent announcements, traction, et cetera. And then I really want to ask you, Dave and I want to have a conversation around the big splash by EMC Green Plum and Intel in particular. The two big money players coming into the industry, EMC and Intel, you know, throwing their weight around a little bit and, you know, taking a little bit of different approach. Some are saying proprietary, we're saying open source plus, however you want to put it, they are attacking the marketplace in an aggressive way to get a position and certainly called out Hive and Impala, specifically over the past announcement. So update on Hortonworks and then we'll jump right in and talk about what SQL means in this new world. Sure, yeah, so the past nine months or so in particular the last quarter or two have really been accelerating just from an industry perspective. You know, one of the things that the last Hadoop Summit in June, we had Jeffrey Moore crossing a chasm there. Market indicators are we're on the right side of the chasm. Just mainstream brands that are actively seeking out deployments. They're more educated on what they want to accomplish. So we're concreted. So it isn't a kick the tires, you know, science project. It's beginning to get clarity and sort of repeated use case patterns. In that space, I tend to sort of categorize things as refined explore and rich use cases. And so refined to sort of get it all in one spot, transform it, right, ship it to downstream, EDWs, so a partnership with Teradata fits into that and we're seeing that rinse and repeat pattern. The explorer, frankly, is what a lot of the SQL stuff, the excitement on how do you interactively, get your hands around the data. And then the enrich is really how do you build intelligent applications, deliver, you know, analytic models to online apps to influence behavior. Are those sequential? So it's, you know, six, nine months ago, we saw them as sort of three different patterns. Right now we're actually seeing is you graduate from one to the next and the next. So it's actually a crawl walk run strategy. And so they are, there's a connection. Well, why is that important? And it gets to the, you know, at Hortonworks, one of the things we've been driving is the yarn aspects of the Hadoop 2 platform that actually have, you know, a richer cluster operating system to support multiple workloads. So if you think of Refine Explorer and Rich, that's batch interactive in one line, you want the platform Hadoop, which most folks just think of it as it's batch MapReduce, right? It isn't, it's a broad platform that spans batch interactive and online application needs increasingly, particularly as you plug things in. So continue to innovate that platform forward so we can serve those, you know, higher speed workloads is important, but do it in a good citizen way. So if you need data in a fast way, you're not going to monopolize the memory and CPU if you're also doing batch processing at the same time. So you need to co-exist in a manageable way. And that's really an area of folks.  When they meet in the middle, all the magic happens. Real accelerated market acceptance, growth, et cetera, on the product side. And really what's happening, and we've seen it with Oracle on one hand, Oracle has the purpose-built infrastructure, and then you got everyone else kind of open-source multivendor. Here what's interesting is you have EMC and there's a lot of customers. Not like they're new to the business. They have a lot of enterprise customers, big customers with storage. And then you have the community innovating underneath. You have innovation coming up from the bottom-up, which is an open-source business model. And then you have EMC, which is kind of top-down. They're on a collision course, right? So we want to document that. So what I found interesting about the EMC announcement was the software-based approach, no appliance. That got good marks, you know, aggressiveness aside. You know, they had that, that was very positive. Same time, they have a lot of customers. So proprietary's been kicked around. We're calling it open-source plus. So I want to ask you, okay, where is this collision? Do you agree with that statement? And two, is that a short-term snapshot of a market they're just going to have to serve with a business intelligence, which makes a lot of sense from a business strategy standpoint, is it obviously different than what's going on in the community where apps need to be data aware, data as code, as we introduced this morning, a concept called data as code, where the data itself is not just one data mark. So you have an interesting kind of positioning here. How do you look at that? What's your point of view? And obviously, and if you can comment, specifically with the top-down bottom-up. So at Hortonworks, like I said, we're focused on that Hadoop platform for mainstream enterprise use cases. But a key part of our strategy was enabling it to interoperate with the ecosystem. That was set very early on. So you mentioned EMC, I'll also mention Teradata, right, with their unified data architecture, Microsoft, right, with their approach on integrating Hadoop in Azure as well as with their SQL Server and BI tool, right? So, you know, it's, yes, our focus is on enabling any and all of those types of use cases because that's what enterprises want, right? So there's not really much religion around that. I think we all see that we want to make sure we accelerate the enterprise adoption of that, right? So that's sort of first and foremost. With that said, having been at Jboss and Red Hat and Spring and other places, as I like to say, the open source tide rises inexorably, right? So it'll continue to get better and better and better. And so in the case of interactive SQL, as an example, we've chosen to double down on the Apache Hive community in order to make that solution, which operates at large scale, for operational batch processing, but to move that into human interactive use cases where you can do visualization, ad hoc reporting and those types of things. And we've gotten very strong reception from customers who already invested in it, as well as the Facebooks, Microsofts and others who are working in that community on wanting to roll up the sleeves and move it into that space. Because at the end of the day, it's been the de facto SQL interface and just one sort of final point. It's been the de facto SQL interface, but as I like to say, it's also fortunately or unfortunately been the pinata that people beat up on, right? The kid in the schoolyard being bullied. Yeah, and if you look at a lot of performance comparisons. So let's all, just one second. So the kid in the schoolyard being bullied or the pinata, as you say, the candy will open up and so was it warranted? I mean, what's your take on that? I see Green Plums saying the performance is significant and we have Donald Miner on Twitter. He's going to give us the data on the benchmarks.  How do you address that? And Cloudera kind of agrees with you, sort of. Right, yep, yep. So we're trying to squint through that. Exactly. Customers are too. So there's a couple ways you can look at it. Right now, Hive is used in petabyte scale use cases and you don't want to lose that, right? But what you want to do is for either the smaller data sets or for the more human interactive scenarios, make it faster, make it more responsive, get it down into the second response time. Some people use the term real-time, I don't like that because real-time to me means sub-second machine to machine. But it is, it's human interactive use cases. Number one. Number two, a lot of the performance comparisons tend to configure Hive against just the plain text mode, which it totally supports, but it has optimized file systems that many of these new ones also have. So it's an apples to oranges comparison, fortunately or unfortunately, and we'll be investing in that area.  Obviously, EMC's business is pretty clear. They're targeting a market that's addressable in the data warehousing business intelligence market. It's SQL-based, but there's a world beyond SQL. But EMC's putting the bridge across their chasm, which is saying, hey, EMC customers cross with us. Don't worry about anybody else. We got you covered. I mean, that's a credible message, assuming that the products can be delivered, but what's your take on that? It's viable. So when you look at an Xgen data platform, SQL is an important use case. It's not the only use case, all right? So there is a large population of users who want to interact in that way. But if you look at the original incarnation, it was like the SQL, the structured model didn't map well and that's why MapReduce and Hadoops was generated in the first place. So the point there is, and that was one of the things I saw on Twitter was like, people abandoning MapReduce, heck no, right? Because it does a lot of the data refining at scale that's required, but you do need to appeal to these new folks. So you'll see the Green Plum solutions, the Aster solutions, the Vertica solutions, all rowey around you. It likes more people to the party, right? Exactly.  Can you sort of explain to customers how that all works? Sure, and a little bit of is maybe a little inside baseball talk about some new technology. So definitely SQL Server, it's out there in our recent announcement of Fortmore State platform on Windows, sort of helps you deploy a consistent footprint. If it's SQL Server and Hadoop in the same servers, you can have that as an option now, right? It wasn't previously an option. But if you look at their PDW solution, they have this new PolyBase layer, right, that sits on top of that. That is a, that's sort of like a universal translator for SQL that can sit on top of PDW and Hadoop, right? Awa Hive and federating queries so you can get data out of either system easily, right? So the end user is oblivious to where the data comes from, right? But so why is it important to speed up hive in that scenario? Last data in is a rotten egg, so to speak, right? So it's as slow as the slowest query, right? So that's why we've been working with Microsoft on optimized file formats and really speeding up the core engine of hive in the community to make sure that those use cases are blazing fast. So that's why our Stinger initiative, 100X Performance One Hive is what we're after here. We're going to bring you back on the cube later for another segment, but we're getting, we're under a lot of time pressure because of the keynotes we're getting over. But I want to ask you one final question. This is kind of more of a 20 mile stare because there are a lot of CIOs in our audience and also developers, right? So what EMC is basically saying is, hey, cross this bridge with us, we'll take care of you. Don't look behind the curtain, but we got you covered on SQL. And I like their announcement, but my only criticism of it, it felt like they're making the horse and buggy faster. Okay, and that's great today in data warehousing. But one thing that we've been talking about in the Cuban and with Wikibon and SiliconANGLE is the new use cases, those new questions, those new data resources that are emerging aren't SQL. They're new applications, it's data as code, a term we coined today. And one thing that's interesting is I haven't heard from EMC is what their plan is outside of SQL. So I want to ask you specifically to talk about one point of view. If you're a CIO and you're an enterprise and you're investing in the future, business value is on the table right now. It's the number one conversation, not making data warehousing faster or a few purpose-built queries. I need to be positioned for the future. So does the EMC bring that to them? What, can you comment on that? Intel's out there as well. They don't want to foreclose the future. So what's your point of view on this new future? So, and then we'll wrap it up after that. Exactly, so I think taking a point of view where you're allowing all the different flowers of access to bloom will win out in the long term, right? So, your point is the SQL sort of use case is fine, but what about the platformers who are inventing a new way of just visualizing on top of that? Or the sasses who are finding ways of running their analytics in the Hadoop stream directly. They're not traditional SQL use cases, right? But they are going to deliver very targeted enterprise value to the customer. And that's a very interesting value proposition to unlock. And so, like I said, SQL's the hot thing right now. Real-time, other alternative patterns are going to be emerging in the next quarter. It's not big data, it's big answers, but it's also, which is one of the things that they talked about, which I like, but also, one thing that they didn't talk about what we said on theCUBE yesterday, it's about new answers and the right answers. And that's, I think, what's interesting in the business value, and that's going to be, I think, the future of the data platform. So, competitive space, final comment we'll break is what's your take on the whole competitiveness and what's Hortonworks going to do to compete? So, it's clearly an important market. So that's clear out of a lot of the competitiveness. What we're going to do to compete is we're going to stick to who we are. When we look ourselves in the mirror, we represent a community-driven Hadoop platform and integrating it with existing enterprise systems and solutions, and we feel strongly that if we stick to that knitting, we'll win in the long run. This is not a sprint, it's long distance running. Okay, Hortonworks talking about their response to all the competition and different approaches. We'll be right back with our next guest. Thanks for coming on Sean Connelly's Senior VP of Corporate Strategy at Hortonworks. We'll be right back. Yep.


How well do you know YouTube? For example, how do you go frame by frame in a video like this? forwards or backwards? There's a hot key. Did you know it's the comma and the dot while a video is paused and here I am moving forward and here I am moving backwards. Try it in this video. Pause the video, press the comma and the dot. What other tips do you know? How about one? That takes you 10% of the way into the video. Two, three, four, five. Five is halfway and so on. Press zero to go back to the beginning. How do you skip ahead five seconds? The right arrow jumps ahead five seconds. The left arrow jumps back five seconds. How do you jump ahead 10 seconds? L is jump ahead 10 and J is jump back 10. How do you adjust the volume of a video? Hold down the up arrow to decrease and the down arrow to decrease. How do you pause the video, space bar?   The full list of YouTube player shortcuts is down there in the description below and you can use that anywhere a YouTube video is playing on Facebook, on YouTube, on any website embedding YouTube videos so it doesn't just work on YouTube.com. This is the start of my YouTube tips series. This is tip one. What other tips would you like me to feature in future videos that you think everyone can benefit from that not many people know? Tell me in the comments below. The reason I want to start this series is because many of you have asked me questions over the years as I've been making the George show and I realize I don't have a single video to answer most of those questions so I'd like to create one video for every YouTube feature and I would love if you were to help me pick which topics to cover so we can make them very useful and helpful to everybody. Was this video about the YouTube player keyboard shortcuts helpful to you? Did you learn something? Tell me in the comments below. I personally like the skip frame by frame forwards or backwards so I can look at exactly what's happening in the video at that moment, the comma and the period keys. What is your favorite tip about YouTube playback? Tell us down there in the comments below. This is about sharing best practices so we can all learn from each other and help each other grow together as a family which is the spirit of freedom. We are also running a 3D virtual set contest that you can win freedom family this set behind me. All you have to do is fill in the google form the link is down there in the description below for you to get this set sent to you so you can make videos using it. See there's another 3D set behind me. We call that our penthouse set because it's high up in the sky and we use it for our music videos. Click that I to learn all about the music factory and see the playlist of all the videos we've created in the penthouse set which you will also be able to use to make your videos soon freedom family. When I showed these 3D sets to YouTube they jokingly said well George I guess we don't have to build any more YouTube spaces that is one of our long-term goals is to use these sets to recreate the YouTube spaces that some of you have been lucky enough to record videos in. If you don't know what YouTube space is it's basically a professional production environment where people of a certain channel size can walk in and use to create their YouTube videos for free. There's only a few around the world you have to be close enough and yep your channel has to be big enough in order to make use of it but one of our goals is to make a YouTube virtual space available to everybody in the freedom family and eventually maybe to everyone on YouTube but of course we're going to focus on the freedom family first. Why wouldn't we? Do you think that is a cool idea? Tell me in the comments below. Do you have any other cool ideas on things we should do with these 3D sets? I would love to know also down there in the comments below. To see all of our 3D sets click that i to see the playlist of every video I've created so far using these various 3D sets. Here are all the contest entries so far and as you can see there are quite a few. Now some of them have been colored and I won't tell you what those colors mean just yet but I will tell you that everyone will get access to these 3D sets soon. Right now I'm giving early access sneak peek to the people who really are passionate and want these sets and make a good pitch showing their passion. Now I have a question for you freedom family. Do you think I should keep picking winners from these entries or do you think everybody who's entered should get the 3D set? I would love to know. Tell me down there in the comments below. Who am I? I am this guy. I am Papa George. George Sunpai and many other names you the beautiful freedom family has given me and these are cool silver play buttons achieved by members of the freedom family which we spotlighted in an earlier episode. Click that i to see the silver play button celebration episode and we will happily spotlight any one of you freedom family who creates a video after you get your silver play button. We'd love to promote you just click the link down there in the description below to the submit your best video form and I will happily feature any silver play button videos because it's such a big achievement. 100,000 subscribers is what you need to get a silver play button and I know all of you are capable of growing to 100,000 subscribers because we even did it from nothing. This channel had zero subscribers and zero views when we launched it on December 1st 2013 which is the day freedom launched as a YouTube MCN and look now we have 170,000 subscribers and anyone can build a channel up if they put in the time and they never give up and that's what we're here to help you on your road to 100k subscribers so you too freedom family can get your own silver play buttons. Oh and I didn't finish introducing myself I am George CEO and founder of freedom for freedom and the freedom family the beautiful family that helps each other grow together as a family which is the spirit of freedom. I'm George and you've been watching click that i to partner with freedom and join the freedom family so we can all grow together you get many perks like position music you also get epidemic sound a lot of other access to royalty-free videos sponsorships and many things to help you grow just click the links down there in the description below to get involved in our community our forums our discord chat servers meet our graphics team meet our community team all of that on discord and the forums what are you waiting for get started and we will grow together as a family because this is the freedom family you are part of it we are all part of it and we're all growing together to get more george click that big f that will subscribe you to freedom central home of the george show and pewdiepie gave one of you freedom family a big shout out click that video to see the shout out and to see our new 3d sets for you and click that video to see what youtube recommends you watch next