>> Announcer: Live from Vancouver Canada, it's theCUBE covering OpenStack Summit North America 2018. Brought to you by RedHat, 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 Alekseenkov who's the co-founder of Aptomi. Brand new start up, I feel we've got the exclusive here to help you know, we have some blog posts out there and the like, but help to introduce you to our community and some of the broader world. Thanks for joining us. >> Yep, my first time at theCUBE. >> Alright 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 Aptomi. 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, ACMICPC and Top Coder. My team ended up winning ACMICPC world finals. So I have like a decent background in algorithms, computer science, data structures, and things like that. >> Yeah. >> So that's me. >> We always see people are always humble there. It's, we know Mike Dvorkin is on your team. >> He is. >> People in the networking world, you know, might have run across Mike, and so super smart people. Give us the you know, the problem statement that your company's looking to solve. >> Right, so... I think it's going to be not one sentence answer. It's going to be a 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 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 seems to be streamlined. You take Jenkins, you take Docker, you take all the tools. You write some Kubernetes key, so this part, packaging components, it's not a big deal. And what we saw is where all the 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, once 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 we 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 Aptomi, what would they be using now? Or what kind of, what kinds of tools and processes are they bringing together if they're not doing this? Are they doing everything by hand, or how do you compare it 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 is also one of the ways to do this. But there are some drawbacks in, in the approaches, right? Because we think that you want to start reasoning about those as actually applications and services not as like as a bunch of YAMLs and containers right? And so once you start talking about this as services as well as rules around those services, right maybe I want to say like hey everything that goes in my production environment should be secure or I want all my services with label "X" deployed to the dev environment or to cluster US east right? I mean the things become easier for you, 'cause you don't have to deal with the YAML file. >> Kind of from the abstraction layer up to maybe up, say to in other part of IT you might say it's policy driven almost, it's declarative, intent driven; I want this to happen rather than writing this kind of crazy YAML. Actually one of the Kubernetes founders, I dunno recently on Twitter or somewhere I was reading was saying that YAML was never supposed to be written by humans, that was kind of a mistake we meant for it to be under the covers but here we are. >> Roman: Right, but you are exactly right. It's services as well as intent around the services. >> Stu: Roman, I want to get your thoughts on just the Kubernetes ecosystem itself, you know for years here at OpenStack it was "Oh wait there's a lot of different distributions", you know, moving between one or the other wasn't necessarily easy. Kubernetes seems like we're a little bit better, a little further along, might've learned from some of the issues that we've had here. There's, last I saw it was getting around 40 different options but you know 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 you know Red Hat has a platform, all the public clouds have a platform, then 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? >> Roman: Sounds good, so for us we actually we don't really care on what Kubernetes we run because we run, 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 right because we run a cluster in our lab, it just works. JKE always doesn't let me 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. So we don't see a lot of issues with that. But you also mentioned the platform, right so Kubernetes is part of the platform and that's the interesting part because a couple of years ago everyone was talking about Pass. It's Pass, Pass, Pass, Pass everywhere. Now you see a lot of conversations about Pass because Pass is like a monolith platform, doesn't exist anymore because it basically gets decomposed into what people call I guess containers of service and the modular tool set. And container orchestration is one part, and there is like 15 or 16 different parts from ad definition, to orchestration, and CD pipelines and security components, right? And that's why you see so many products out there with overlapping functionality. >> I mean do you think that the concept of Pass is going away at this point? Will we continue to redefine what a Pass is? I think every few years maybe that's the pattern. >> My personal opinion is that the concept of Pass is gone. There's is no more Pass. The future is the modular stack and the modular tool set. >> Stu: 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. >> Roman: Sure well Serverless is, I guess it's not for everyone. 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, something that you sometimes make a call to and have to do something and get a response back sure Serverless is great, and Serverless actually fits quite well into what Mike and are tying to do with Aptomi. >> John: Roman I also wanted to ask about dependency mapping and visualizing dependencies. Hybrid cloud has been a big theme this week. It's actually a big theme in enterprise and elsewhere. When that happens when you have separate components whether they are monolithic components that are talking to each other down to microservices, dependencies are huge at that, the application level dependencies, especially as you move to hybrid cloud because you might be moving some component away from the rest and 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? >> Roman: Yeah so there's basically two ways how you can approach this so one way is the traditional way 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 got things deployed. So we are taking a slightly different approach because we require a little bit more information upfront about dependencies between components so once you deploy things through Aptomi we kind of already know what exists on 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 we're trying to build this, or we are building this on top of the community standards, we are not reinventing the whole platform, or trying to invent a new language, it's basically build ontop of Kubernetes and Helm. It's just a simple declarative service based abstraction and it rules. >> Stu: Last thing I wanted to ask, Aptomi itself, you know what's the state of the project? Is it a 1.0, are you looking for contributors, where are you with customers, help round off the understanding of the company and project. >> Sounds good, so we are one year into the project. The project is completely open source, it's on Github. It has 4 contributors right now and close to 2,000 commits maybe a little bit more. 100 star, 100+ 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 a hosted version with support. Right so when people come and they can just get the 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. >> Stu: Alright well, Roman Alekseenkov really appreciate you sharing with us. Congratulations on the progress so far, seen an item I'd like working for us and for John Troyer. I'm Stu Miniman, we thank you for joining for 3 days of live wall-to-wall coverage of big final shout-out to the OpenStack Foundation and the supports of theCUBE for the whole crew here. Thank you for watching theCUBE. >> (electro-dance music) >> (soft piano) >> Astronaught: I recommend you activate my bit-ray over.