>> 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.