 Live from Vancouver, Canada, it's theCUBE. Covering OpenStack Summit North America 2018, brought to you by Red Hat, the OpenStack Foundation, and its ecosystem partners. Welcome back to theCUBE's coverage of OpenStack Summit 2018 in Vancouver. I'm Stu Miniman with my co-host for the week, John Troyer, and helping us to bring it on home. We have Roman Alexiankov, who's the co-founder of Apdemy, brand new startup. I feel we've got the exclusive here to help, you know, we have some blog posts out there and the like, but helped introduce you to our community and some of the broader world. Thanks for joining us. Yeah, my first time at theCUBE. All right, so Roman, give us a little bit about your background and, you know, we need with any, you know, founder, the why of your company. Okay, so I guess let's start with a background. So I used to work for one of the cloud infrastructure startups called Mirantis, and I worked there for a very long time. And last year, I decided to start something on my own. Right, so now I am one of the main guys and one of the core contributors to the project called Apdemy. So, and I don't know if it's relevant, but before Mirantis, I've been doing a lot of the programming competitions, like Google Code Jam, ACM-ICPC and TopCoder. My team ended up winning the ACM-ICPC World Finals. So I have like a decent background on algorithms, computer science, data structures and things like that. Yeah, so that's me. We always, you know, people are always humble there. It's, we know Mike Vorkin is on your team. People in the networking world, you know, might have run across Mike and so super smart people. Give us the problem statement that your company is looking to solve. You're right. So I think it's going to be not the one sentence answer. It's going to be slightly longer answer. So when we talk to a number of companies who are using Kubernetes and who are building apps on top of Kubernetes, we looked into CI space and the CD space. And we looked at the CI and in the CI, for the most part, most of the problems they seem to be solved, right? Everything that starts from your source code and then Docker file, how you build your artifacts, how you test it and how you publish the binary to the repo, all that part that seems to be streamlined. You take Jenkins, you take Docker, you take all the tools, you write some Kubernetes YAMLs. So this part, the packaging components, it's not a big deal. And what we saw is where a lot of people are struggling is actually in the CD space, right? Once you start putting multi-container complex applications out of those pieces, once you start wiring those pieces together, maybe microservices, maybe not, but once you start wiring things together, when you start running them across multiple environments, multiple clusters, right? That's where the things become really, really difficult for people who just rely on the tool set that you have today, right? And that's where we saw an opportunity to build this service abstraction, which allow people to wire things together and run them and operate them in a controllable way across multiple clusters and multiple environments, integrated, obviously, with the continuous delivery pipelines. So if people weren't using app to me or what would they be using now or what kinds of tools and processes that they bring it together if they're not doing this? They're doing everything by hand or how do you compare to some of the other tools? Right, so a lot of people, they use some homegrown frameworks right now on top of Kubernetes and Helm or maybe on top of Kubernetes and YAML files or maybe Kubernetes and JSON, that is also one of the ways to do this, but there are some drawbacks in the approaches, right? Because we think that you want to start reasoning about those as actually applications and services, not as like a bunch of YAMLs and containers, right? Once you start talking about this as services as well as the rules around those services, right? And maybe I want to say like, hey, everything that goes to my production environment should be secure or I want all my services would label X deployed to the Dev environment or deployed to cluster US East, right? I mean, the things become easier for you as you don't have to deal with YAML. From the abstraction layer up to maybe upstate in other parts of IT, you might say it's policy driven almost, right? It's declarative. I want that intent driven. I want this to happen rather than writing this kind of crazy YAML. Actually, one of the Kubernetes founders recently on Twitter or somewhere I was reading was saying that YAML was never supposed to be actually written by humans, that was kind of a mistake. We meant it for it to be under the covers, but here we are, yeah. Right, but you are exactly right. It's services as well as intent around the services. Yeah, Roman, I want to get your thoughts on just the Kubernetes ecosystem itself. For years here at OpenStack, it was, oh wait, there's lots of different distributions. Moving between one or the other wasn't necessarily easy. Kubernetes seems like we're a little bit better, a little further along, might have learned from some of the issues that we had here. The last I saw was getting around 40 different options, but the thing I also wonder about is, Kubernetes tends to get baked into platforms, so you've got people that will build their own, just take the code, but Red Hat has a platform, all the public clouds have a platform, and there's a number of startups there. What's that like from your standpoint, kind of being in this ecosystem, is it, and maybe give us a little comparison compared to what it would have been like in the OpenStack world? Sounds good, so for us, we actually, we don't really care on what Kubernetes we run, because we help people to deliver apps and services on top, but if you talk about Kubernetes itself, we don't, actually last year, we haven't seen a lot of issues with Kubernetes, because we run a cluster in our lab, it just works. We, JKE always doesn't let you down, we also run things on Azure, so speaking about the Kubernetes infrastructure, I think the state of Kubernetes right now, it's pretty reliable, right, so we don't see a lot of issues with that, but you also mentioned the platform, right, so that Kubernetes is a part of the platform, and that's the interesting part, because a couple of years ago, everyone was talking about PASS, right, it's PASS, PASS, PASS everywhere. Now you don't see a lot of conversations about PASS, because PASS as like a monolith platform doesn't exist anymore, because it basically gets decomposed into what people call, I guess, container as a service, and a modular tool set, right, and container orchestration is one part, and there is like 15 or 16 different parts from the app definition to orchestration, and CD pipelines, and security components, right, and that's why you see so many products out there with overlapping functionality, right? I mean, do you think that the concept of PASS is going away at this point, you know, will we continue to redefine what a PASS is? I think every few years, maybe that's the pattern. My personal opinion, that the concept of PASS is gone, there is no more PASS. The future is the modular stack, and the modular tool set. Yeah, so absolutely the future is becoming more distributed. I'm curious, your thoughts then, on something like Serverless, which tends to change that even a little bit more than what we've been looking at? Sure, well, Serverless is, I guess it's not for everyone, right, it also depends on the type of workload that you run. If you want to run something compute-intensive, I guess it's still going to be containers, or even VMs, but likely containers, but if you have some stateless front-end or API, right, something that you sometimes make a call to, and then you have to do something and get a response back, Serverless is great, and Serverless actually fits quite well into what Mike and I are trying to do with Apatomy. Roman, I also wanted to ask about dependency mapping and visualizing dependencies, and it was with Hybrid Cloud, been a big theme this week, it's actually a big theme in the enterprise and elsewhere, right? When that happens, even if, when you have separate components, whether they are kind of monolithic components that are talking to each other down to microservices, dependencies are huge, that the application level dependencies, especially as you move to Hybrid Cloud, because you might be moving some components away from the rest, and then you better know what's talking to the other components. Any thoughts on how that is developing as architecture, application architectures, and what you guys are doing to help there? Yeah, so there's basically two ways how you can approach this. So one way is the traditional way, right, where you just open up your Kubernetes to a bunch of developers, and people just run their things in different namespaces. If you use that approach, I think those dependencies between different components, what relies on what, who's talking to whom, they become non-obvious. It's really hard to discover them once you've got things deployed, right? So we are taking a slightly different approach because we require a little bit more information up front about dependencies between components. So once you deploy things through Apptomy, we kind of already know what exists in the clusters and why, and who owns the resources and who asked for certain services to be deployed. So we do provide some contextual visibility into that. And what's really nice is that we're trying to build this, or we're building this on the top of the community standards, right, we're not reinventing like the whole platform, we're trying to reinvent the new language. It's basically built on top of Kubernetes and Helm. Just a simple declarative service-based abstraction and rules. All right, last thing I wanted to ask, Apptomy itself, you know, what's the state of the project? Is it kind of a 1.0? You're looking for contributors? You know, where are you with customers? You know, help round off the understanding of the company and the project. Sounds good. So we are one year into the project. The project is completely open source. It's on GitHub. It has four contributors right now and close to 2,000 commits. I think maybe a little bit more. 100 stars, 100 plus stars on GitHub, so we're getting some traction in the open source. Speaking about the readiness, I think it's we're not 1.0 yet, but we're getting close to 1.0. And the core of it, and the whole project is completely open source, right? It's 100% Apache 2.0. But what we also do, we also offer hosted version with support, right? So when people come and they can just get a complete CD system with the service-based layer and abstraction through our hosted version with support, and that's what we are charging money for. And revenue-wise, we do have paying customers, but it's only a year in, so not a big amount, but there's going to be more. All right, well, Roman Alexiankov, really appreciate you sharing with us. Congratulations on the progress so far. Say hi to Mike for working for us. And for John Trier, I'm Stu Miniman. We thank you for joining us for three days of live wall-to-wall coverage. Big final shout out to the OpenStock Foundation and the supporters of theCUBE for the whole crew here. Thank you for watching theCUBE.