 Everyone, welcome to this special CUBE Conversation. I'm John Furrier, co-founder of SiliconANGLE Media. We're here in our Palo Alto studios for theCUBE, talking about cloud computing and all the greatness around what's happening in tech. We're here with a practitioner who's also the CTO and lead engineering manager, executive. His name's Dan Jury, he's with Digia TV. They're a hot startup that's growing, doing a unique solution around changing the game and opening up a TV for the masses. Great opportunity, thanks for joining me. Thanks for having me. So one of the things I love about what you guys are doing is you guys are a startup that's challenging the status quo with TV, taking over the air in cities and having an app where you can watch TV without having to literally cutting the cord. And so it's challenging, but there's some technical things that require cloud, you guys are growing, you're a user of cloud. What's the, how are you looking at building out the engineering team? Because you're DevOps, you've been doing DevOps from day one, but you have to have local presences in these markets, you have a data center in each market, plus you get cloud, you're a hybrid. Right, exactly. Well, I mean, for us, the cloud is essential because we have, even though we have to have a local presence for each of these markets, because we're obviously receiving local signals and we can only do that in the market. You can't receive an LA signal in Boston, right? So we have the local presence, but at the same time, we want to have all of our central stuff managed in a much more effective way, in a central way that we can scale as we grow, right? So as we continue to add markets across the country, which we hope to do very quickly, we want to make sure that the central services that manage all the things that are common and the apps can grow and hopefully grow as automatically and scaleably as we can, and we can most effectively accomplish that by leveraging cloud technologies. Just to get the idea straight now, as we can kind of get to the cloud stuff, is you guys are taking over-the-air TV, which is free, the old antenna days, without cable, and there's channels that are available for free, and then putting that into a local region, so LA, Phoenix, San Francisco, Boston, they have their local broadcast over-the-air. You bring it in, and then it's digital, and then the users access it via apps and all the things that connect in the edge of the home. That's pretty much the general concept. So basically what we do is we allow you to get all those things without having to worry about an antenna on your house, or if you're a mobile or whatever. So a lot of people these days might just get a Roku and not want to worry about a physical antenna, or whether you're pointing in the right direction, or whether there's some other house in the way. And so we allow them to get the over-the-air channels at high quality, no matter where they are, without having to worry about sort of the antenna part of the problem. It's a great mission. I love it. It's ambitious. A lot of moving parts. You got content, you got transmission, but it really opens up freedom for people, whole new demographics, great stuff. So, okay, now how do you make this happen? You got to go deploy clouds. So you obviously want to use the most efficient. You guys are lean and mean. You don't have a huge IT staff. It's you and a couple of people, basically you. We have a two-person ops staff and me and some engineers. But yeah, we're pretty lean. Yeah, there's not going to be a big data center in the future, given what you guys got. But you've been successful with the cloud. Take us through how you guys laid this out with cloud and with the hybrid solution. What are some of the things that you've implemented? What's the architecture? How does it work? Well, as you can imagine, a lot of our problem is managing sort of network architecture. Make sure we have that laid out and that the data, one of the key things is for us is the data centers and the cloud talking to each other, as with any hybrid solution. So we spend a lot of time with automation. One of the challenging things with cloud is your first instinct is just get things up. And so you immediately just start going into consoles and start spinning things up. And the next thing you know, you've got a huge mess, right? And your ability to get things working or scale, realize you have to kind of start again or you're constantly working around the problem you created. So we've invested a lot of time in ramping up our automation, make sure every part of the system is well-defined, well-understood, that we have the networking setup the way we need to so that data centers can talk to each other. And then also a key part of the decision in a hybrid model is what's in the cloud and what's not, right? So for us managing the TV signal we have, we're basically transcoding incoming signals 24-7. So that's one area where if you look at cloud pricing that's not the most effective thing to do is to have 24-7 content going in and out. So that's the type of thing we look at, okay we're going to do that. Plus you've got a geography challenge so that's easy check. Yeah, yeah, but you might be tempted to say let's put all the transcoding in the cloud because scale and blah, blah, blah, blah, blah. But if you really look at the other factors like how is that going to slow down your network, your ability to deliver streams, your cost effectiveness, that's just where you start to say, okay that software's going to stay here, this software's going to go there. And that's a latency concern and cost both? Definitely latency, we pride ourselves on how quickly we go from over the air to someone's phone. That's table stakes for you, that's like a core app. Yes, I mean we're 30 seconds to a minute faster than Hulu or any of those people as far as our stream's going live. And then the other table stakes, because we're lean, is managing our costs and obviously piping all of that into the cloud for us is not cost effective. And then we also looked at other third party services like analytics, so our services that manage events and things like that that are courtey or app getting metrics or who's watching your app, how are they watching it, what device are they watching it on, what time are they watching it. So we looked at different solutions and that was again a place where the cloud solution ended up matching our requirements and from a pricing perspective just made a lot of sense for us versus some other third party or rolling around, right? So if cost is not an issue, if it's centralized you put it in the cloud because you take care of the geographies, that's key with the TV signals and whatnot and then cloud prices right and matches the requirements manage it within the Amazon. And Amazon's your cloud, right? Yes, that's right, that's right. Okay, so stepping back for a second, you mentioned networking, because I think one of the things I'm hearing in a lot of these conversations with friends and practitioners who are doing some cutting edge work is they're staying with the holy trinity of the three horsemen if you will. Storage, compute and networking, the game doesn't change, it's still going to, no matter what people say about storage being dead, it's never going to be dead, right? Those things will change though. So the question I have for you, Dan, is what's the impact that cloud has had on network? I mean, compute's pretty straightforward, you can know what compute is, you throw money at compute, you can have spin up stuff, so it scales, that's beautiful thing. Storage, some visibility on storage, some work to be done there, but network has always been a problem. Do you start with networking first? How does cloud and cloud native and those services impact networking? Well, it's one of those areas, you know, like actually like all of those areas, I guess, but network certainly, where there's really no replacement for expertise and really understanding how does this work? You know, and then being able to apply that to, okay, well, what does in our case, like Amazon provide as far as how much bank with can we get in and out? Right, and then planning, okay, and how do I manage my hops, you know, if I'm going to go build my VPC and my network layout and how that's all going to go from, we're getting a signal over here and it's going to hop, hop, hop, hop, hop. You know, what are those hops and how do we get the most bang for buck out of that and make sure that that's, there's a little latency between each of those as possible. And that's something where you just have to have the networking experience to understand what are all the variables. You know, because there's a lot of levers you can pull in the cloud, you know. They give you a lot of options, which is a blessing and a curse, right? It's not just push a button and it's magically the perfect solution. You have to really go in and understand what are all those things you can tweak, including what type of instance you choose, which can affect your network bandwidth as well as your processing power, right? So, I mean, you really have to dig into those things, but I would say for most companies, you know, Amazon or someone like that is still investing way more effort than you're ever likely to in making sure the network and the infrastructure is solid. And they're more invested in doing it because they have to support all these customers on it and they all have to be happy, right? So... They know they have to address it. It's just evolution. Exactly, you know. And yeah, and you may have special needs where there's options they provide where maybe you pay more to get higher performance if you need that. But I would say, you know, certainly for some, the company like us, there's no way we're going to spend as much effort, you know, trying to get the data sent up with the big pipes and everything else that you have. You just got to make sure that you don't shoot yourself in the foot by configuring it wrong, right? And that's really the key. I mean, provisioning, configuration, human error, these are all things. I mean, people also said about Amazon early on, oh, security in the cloud sucks. Now it's better security. I mean, the head of the CIA said on the record, my worst day of security in the cloud is better than my best day on premises. And so there's a kind of scale of things. But at the end of the day, packets are packets and you go from point A to point B. That's right. That networking, that's never going to change. So your point about serviceability and programmability comes up. So you guys are living the DevOps ethos because you have to. And you're building that into your entire plan. And this is kind of where I see this next level evolution where networks are programmable. So what does that look like, right? Is that just configuring configuration management? I think some of these early tripwires are the configuration management, monitoring, easy ones. What's next? What's programmable networking mean for cloud architect? Because that seems to be an open question right now. What's your thoughts to that? I mean, if you're talking about a system like Amazon or I assume like Azure or Google, I mean, a lot of that is there. I mean, where you see like the security issues, for example, is where people didn't really make the effort to understand how to lock that down or they couldn't figure it out and things weren't working. They said, all right, open the world, whatever. But if you look at like managing security groups, we spend a lot of time managing security groups who can talk to who. Make sure only the people that can talk to each other are supposed to talk to each other. And that's really where I think system like Amazon will again do that better than you can without a lot of effort, which is they sort of boil it down to just say, this person can talk to this person on this port and we'll do the rest. We'll manage firewalls and make sure the ports can talk to each other, whatever. But you just have to tell us they can and we'll worry about what happens underneath, right? And so I think you get a lot of that already. You just have, again, it's one of those things where you can shoot yourself in the foot. You can bang your head against the wall. A lot of why can't these things talk to each other? But the other day, I'd rather they couldn't talk to each other than it was too open or, right? It's interesting, you look at like the networking thing at the end of the day. If you make it programmable, it just has to work, right? And I think that brings up the trade-offs operationally and as you guys grow your operation, what are some of the operational factors that when you look at the dots you're connecting with your business as you guys grow on operations? Is it trade-off of cost and performance? Because obviously you have performance issues on the app because you're streaming to the TV, but you mentioned costs. How are you balancing those trade-offs and what do you look for operationally to evaluate the trade-off? I think a lot of time it comes from what do we want our core competencies to be? Is it worth it for us to build this ourselves or develop that skill set? And then you trade that off of what would it cost us to build it ourselves or use Amazon solution or use some other third-party solution, right? And then it really comes down to, even if that's more expensive, do we really want to build it ourselves even though that might be cheaper? Is that really worth it to us? Yeah. Right? It's not a core competency and if you can get it out on the web, why not? Yeah, so for example, you know, what's in our data centers, our transcoding stack, all of that, yes, we do that ourselves. We don't use Amazon's transcoders, all of that, because that's just key to our business and it's important that we manage that very tightly and it does what we want. And it's also just much more cost-effective because of what we're doing. We're not just transcoding it. It's your competitive advantage. That's what you guys are banking on as IEP. Exactly. But managing the network infrastructure, no. You know, spinning up Docker containers, no. We're happy to shell that off to Amazon and just, I was talking to a network buddy the other day and he's like, John, what's the big thing with Cloud? What's in it for me? I go, here's the modernization of Cloud. You are a command line guy. Command line interface is over because if you want to go Cloud, you're going to be dashboard driven. You're going to be looking at a much more operator role, less of it, go in and do more command line interface, configure these switches, do these things. Kind of connect the dots for him. And he goes, okay, then this next question I'll, which I'll ask you is, he goes, how do you evaluate Cloud service providers? I mean, what's the criteria? Because Amazon's got the most services that have been around the longest but Google's got great AI and Azure's got Azure stuff. So, I mean, trying to find some strengths here but they got Microsoft Office, okay, and some other things. But how would you evaluate if you're going to go back to, if you had to bake off again today, how would you advise friends to, in terms of what to look for in a Cloud provider? Well, I think obviously maturity. This is something, this is not something you change your mind about six months from now, right? If you're going to pick a Cloud provider and start deploying on it, that's an investment. Like you have to be willing to live with that decision for years, likely, right? Before, if you picked wrong, it was painful enough, you might make the switch, right? So I think you definitely have to do the due diligence on does it do what I need it to do? So for us, that's not just networking and infrastructure. That's what other service do they have. So for example, the database supports we use. We use their eventing supports, so we can send metrics, we use Redshift for big data storage. So you kind of have to look at, what does your product need now or in the future? And what do we get? Is it worth it? And you're never going to get everything, but you may find that one gives you 80%, and the other one gives you 60, and the other one gives you 30, one gives you office, whatever that, you know? And then also like integration, you want to look at what else might I want to integrate with and what does that look like? So for example, having done a lot of technology evaluations, that's a big key is, well, we're going to plop this not just by itself and it's going to solve everything. We're going to have 10 other things that integrate with it and how mature is that ecosystem? Yeah, right. And then you have tied to the core competency which you mentioned earlier. Core competency, and then you look at other higher level things like what a support looks like. If somebody goes down in the middle of the night, am I going to be able to talk to someone who can help me out? So there's a lot of things that, if you get sort of the higher level of decision-making, you really have to consider of, this is a bet for the product to be up 24-7 that people are going to rely on. And that's a serious, you want to take a real deep dive and look at it. Dan, we were talking before we came on camera here about Kubernetes and containers. You had mentioned there's been some homegrown versions of containers. Containers have been around for a while. But now more than ever, you're seeing that as kind of a linch pin attract towards microservices, which is a path towards serverless and all this greatness of that the cloud can bring with cloud native if you're ready for it. So the question I have for you is, if for folks that are looking at containers and Kubernetes, what should they look for there? Obviously, maturity is one, Kubernetes, thank God, is now kind of becoming de facto standard. But you still can pull that down and run it in your own Kubernetes. Do you use Amazon? So what should folks practitioners look for in the technologies behind containers and Kubernetes? I think it, well, I mean, at this point, like you said, there used to be about half a dozen different container management systems. And I'm sure they're still out there, but more or less, Kubernetes was one. You know, if you can go to any cloud provider, they will have Kubernetes support. And then there's a pretty big ecosystem around Kubernetes now. So you're really looking at what's going to help me deploy my software the easiest, right? You know, a lot of people still using packages and things like that. And I think a lot of the reason for the adoption of containers is not just, hey, it's another packaging system, but it has the advantages, kind of like virtual machines. And I think everybody loved virtual machines for the right reasons. But where containers kind of took over is they're more lightweight, you know, virtual machines because they are an entire hosted operating system, they have a lot of overhead, right? And you have to really reserve, you know, resources and things like that, that's, you know, for that world. And they serve the purpose at that time. Exactly, right? But the same concept of having an isolated package that I can just install on machine and it works, you know, still holds true. And that's what Container provides, but with a much smaller footprint, you know, where you can run them without all the extra overhead and all the extra stuff that's in between a virtual machine and its host, right? So I think they serve that container as just sort of the next evolution of the virtual machine. And then where something like Kubernetes comes in as sort of similar, like where VMware would have been where you can sort of put your services in a repository and then say, look, here's a bunch of hosts, go figure it out, right? Which once you get to scale, that's really where you want to be. You know, if you're still micromanaging how many instances you have, you're not going to scale. You're not ready for Kubernetes, basically saying. So there's a tipping point for Kubernetes. What is that tipping point? What's the scale, what's just order of magnitude, general view on your point? I would say, well, I mean, when you're talking about containers, if you're already sort of in the container world, you know, that tipping point for that or say Amazon's container service is sort of day one. You know, don't start deploying containers manually, that's just crazy, figure this out, right? And you know, even if you can figure it to say you're only going to be two and I'll worry about auto scaling later, at least you have that foundation. And you know where your containers go and you know someone's managing the host for you instead of you going, I'm going to go to host X and tell it to run container Y and I have to do that all manually because now you sort of gone back to the stone ages of operational deployment of where I'm going to log in and install a package and do everything manually, right? So I think- And nobody wants that by the way. Nobody, nobody should want that. If you do, please, please don't work. I don't know what to say. Don't show up. Don't show up, don't show up. Or buy short to stock or whatever company it is. Yes, exactly. So I think, yeah, if you're going to go the container model you want to go figure that out and get the expertise and get that set up. You know, and again, even if you are not going to use all the bells and whistles right away, there's a lot of like with any technology, a lot of quirks and challenges with managing containers like managing networking of, you know how does this request go from someone's browser to this container running on this host, you know, inside a container? You know, and that's not trivial, right? So having something like Kubernetes that just sort of handles that, not that Kubernetes doesn't have its own quirks and challenges to get it set up and running, but the whole point of that system is to deal with that, of give me a cluster of hosts and I will help you just load balance and deal with this stuff. So Dan, final question for you. You've been in the industry a long time. You've seen the waves of innovation. You had a stellar career as head of engineering, VP of engineering. That did you, VP of engineering, CTO. Again, growing startups and your DevOps, your lean and mean and growing, so that's cool. Not the big IT shop, but as the world changes, what are you most excited about now? Cause you've seen the movie before. You've seen the old days. You saw the transition. You've seen what cloud is bringing. Obviously you're on top of it here. What's exciting about this time right now? What are you excited about? Well, I think what's exciting is that you're seeing a lot more technologies that enable companies to scale and grow, right? Cause I mean, the hardest thing, any company, like once you get past, even like 30, 50 people, you know, your company's getting that big. You start to see people, the technology start to trip over, right? You really start to see the issues of crap, we got a spike and the whole service went down or whatever that is or a database fell over. You know, and so the fact that it's much easier and less effort to access technologies that allow you to scale, granted you have to make the effort to learn how to use them, but the fact that they exist versus go roll your own of everything, I think is exciting. And I think, you know, on the same track, you know, the availability of these scalable data stores like Aurora or Redshift or whatever, where you used to again, just have to figure that out yourself. And I mean, storage is the biggest pain for scaling. That's the first thing that dies horribly, right? So just the fact that things like those are available and managed for you, you know, I think will help make a lot of companies be successful where, you know, three, four or five years ago that wasn't available, you know, and you would have had to figure it out yourself and just falling over. And you know, the upshot too is when you're building all, when you're a builder like yourself, when you're building stuff and deploying, you can do more with 20 people on a team. I mean, just think about the productivity. I mean, think about what you do with 20 now with cloud that you'd have to ramp up to and fundraise for. Build out the data center, get the QA department, get the engineering, I mean, massive amounts of overhead and time loss. Well, you don't need three DBAs anymore, right? So absolutely, you know, what we can do with, you know, 10-person team today is, you know, massive, you know, compared to what we could do five years ago. All right, Dan Drew, CTO, Executive Vice President of Engineering at a company called Digia, D-I-D-J-A-T-V, check them out. Hot startup doing a really amazing mission trying to bring over-the-air TV to local communities on an app with programming. Certainly, guys, if you need any CUBE content you want, feel free to use all of our free content. Happy to donate the CUBE content to the Digia mission. Thanks for coming on, appreciate it. Thank you. Okay, Dan Drew here inside the CUBE, I'm John Furrier with a CUBE conversation here in our Palo Alto studios for the CUBE. Thanks for watching.