You can also point your browser at Containers on redhat.com to learn more about:
- Container portability with deployment across physical hardware, hypervisors, private clouds, and public clouds
- An integrated application delivery platform that spans from app container to deployment target—all built on open standards
- Trusted access to digitally signed container images that are safe to use and have been verified to work on certified container hosts
Listen to MP3 (0:16:32)
Listen to OGG (0:16:32)
[Transcript]
Gordon
Haff: Welcome to another edition of "Cloudy Chat," Podcast.
I'm Gordon Haff in the Cloud Product Strategy Group at Red Hat. I'm here with
my colleague, Mark Lamourine. Today, we're going to talking about
microservices, Rocket, and Docker, and how these various things relate to each
other.
Before
we get into technologies, one bit of housekeeping. We're going to be talking
about the technical aspects of these things. Unless I say something explicit
about commercialized product, none of this should be taken as a product
roadmap, or product plans. With that said, Mark, let's take it away.
To
start off with, maybe provide a little context. Where does Rocket fit in the
container landscape?
Mark
Lamourine: Prior to Rocket, if you were trying to build containers,
you really had two avenues. I'm leaving older technologies, like Solaris and
stuff aside. We're talking just about Linux containers. It was LXC, which was a
build‑your‑own, handcrafted, rather complex mechanism which has existed for
years, but really didn't gain any traction outside of a couple of important
areas, which we’re not going to get into
today.
Then,
about two and half years ago, Docker emerged and made it much easier. By making
a lot of assumptions for you about what a container should be, they made it a
lot simpler to create containers to move images around to distribute them. They
did a lot of tooling around it.
Since
the advent of Docker, containers have really caught on, at least in mindshare
as a new way to distribute software and distribute applications. Rocket came
into that as a slight alternative. The community that was working with Docker
and with LXC, they noticed a couple of things that were a little restrictive
about what Docker does.
There
are some assumptions in Docker that make it slightly more difficult than it
might be to create containers that communicate with each other, or to create
containers that have multiple processes or a number of different little things,
that people have noticed only after they started trying to build complex applications.
Rocket was designed specifically to fall into that middle space.
Gordon:
It's probably worth mentioning something here, which you touched on,
which is that Docker is often equated with containers, the base level
technology. Whereas, Docker really encompasses a lot more than that.
Mark:
You're right. You made two points there. One is that people think of
containers, and they think Docker like that's the only way. There are a lot of
ways to do containers, or there are now three ways to do containers.
But
also Docker encompasses a lot more than just the containers. They've built an
ecosystem. They've built a life cycle, or they're starting to build a life
cycle. Rocket, again, falls somewhere in the middle of control spectrum. Where
LXC, you have very little in the way of infrastructure, very little in the way
of control and boundaries, and it's very free, where Docker provides a lot of
infrastructure, and a lot of help in producing, and managing your containers
and in running them, but it also imposes a certain level of restriction.
Gordon:
Both of these technologies are independent of a containerized operating
system, such as RHEL Atomic Host.
Mark:
In fact, they're independent of the operating system in general. You can
run both Docker and Rocket on ordinary hosts. You can embed both of them onto a
container host, a stripped‑down host, like either Core OS, Project Atomic, or
RHEL Atomic.
They're
really orthogonal pieces. In fact, they can run side‑by‑side. You can run
Rocket right next to Docker, and you can run Rocket containers right next to
Docker containers.
Gordon:
I think there's been a tendency in the marketplace, deliberately by some
folks to mash things together that don't need to stay together.
Mark:
In some senses, that makes sense because, in the end, the goal is to
produce an environment where people can create containerized applications, and
stop thinking about the underlying operating system. In that sense, the idea
that somehow the two are equated, it makes a certain amount of sense.
But
when you're actually developing for one or another, it doesn't really matter.
In fact, you don't generally develop containers on a container host. You
develop them on a real host, then you migrate them over, test them, and
hopefully deploy them out onto a container host.
Gordon:
Mark, what is Rocket at a high level from the technical perspective?
Mark:
Rocket's a container system. What that means is that Rocket is a means of
starting processes that have a different view of the host operating system,
than an ordinary process does. It's different from other isolation mechanisms,
like virtual machines, in that the containerized app is running on the host.
From
the host, it looks like an ordinary app, but the containerized app has a
different view. Rocket is one mechanism of creating one of these, and what
Rocket does is it allows you to create a single image with a single process, a
set of process binaries, and run it on the host in its little special
environment.
Gordon:
Now, if you think about how Rocket is different from other approaches to
implementing containers on a containerized operating system or in some other
way, what are some of the most salient characteristics?
Mark:
The big difference between others is that when you're crafting a new
image or a new container, if you use LXC, you have to handcraft all of the
boundaries, all of the contents. If you're using Docker, you use the Docker
file and a base image, which helps you define what goes inside.
With
Rocket, you have to handcraft the image in the same way that you do with LXC or
a similar way, but Rocket also offers you the advantage of the image spec,
which LXC doesn't. It's a simpler image format. It's a simpler set of contents,
but you do still have to handcraft what goes inside.
What
that means is that you get a very lightweight container image. The container
image doesn't have all of the package adding mechanisms. It has just what you
need to do your application.
Gordon:
What are the pros and cons of those approaches?
Mark:
For Docker, the big advantage is that the application developers can work
very quickly. They don't have to understand a lot about the specifics of how
their application works. They can treat it like an ordinary RPM. The
disadvantage is that, they tend to get a lot of bulk into their images that
doesn't really need to be there at runtime.
The
biggest example is whether it's an RPM or Debian‑based system, all that
packaging infrastructure is included in the image and is used in composing the
image at build time, but it's essentially unused afterwards.
People
have to do some fairly interesting tricks to get around that. In Rocket, you
just put the files you want in and go on.
Gordon:
We've really been talking about the impact on the developer. What are the
differences at runtime?
Mark:
Again, we get back to comparisons with Docker. With Docker, you get one
image and it has one process. The boundaries of the container are defined by
the contents of the image. With Rocket, the image is a start and the runtime is
specified. But when you create an actual container with Rocket, you can supply
multiple images and it can run multiple processes.
It
establishes one set of boundaries around all of those processes. With that
means is that the processes can communicate with each other, but not with the
outside world, except through the holes you push. When you're working with a
Docker container, and you want multiple processes to communicate with each
other, you can't easily have the two processes communicate without explicitly
punching lots of little holes.
What
it means is, again, that it's easier to compose a Rocket container from
multiple images that cooperate, and still have the containment boundary.
Gordon:
Are there any implications for application architect or microservice type
application architectures?
Mark:
There are a lot of implications for that. There are a number of places
where what Rocket does is it recognizes that the processes running in a service
have more or less affinity to each other. Some of them only connect via a
network. Other ones need to share files.
They
may need to share pipes. They need to be on the same host. Rocket gives you the
flexibility to control the distance between the processes and to control more
finely which ones are treated as close boundaries and which ones are treated as
wide open ones.
Gordon:
Presumably, there are also implications at the orchestration layer, like
Kubernetes, for example.
Mark:
One thing about Docker is it's taken what we've learned about
orchestration so far and is starting to apply it to the containers themselves,
the container design. I hadn't looked at it until very recently, but it turns
out that the Rocket developers have actually adopted some Kubernetes
technology.
They
had started out calling a container this thing which has multiple processes in
it. The documentation recently has started to refer to that as a pod, which is
a term pulled from Kubernetes, which refers to multiple processes which run on
the same host, and which share resources more tightly than merely ones that are
communicating over a network.
Gordon:
This all very much corresponds to some of the terminology, different
terminology of the ideas in microservices where you expose every microservice
or do you have nested microservices because some things don't really need to be
explicitly exposed to the outside world?
Mark:
I think there's still a lot of exploration that needs to go across the
container community about how good application architectures will look. There
are purists. Actually, it's interesting. There aren't that many purists in this
area. Everyone's pretty much exploring. There are a few. But I think we'll find
out from practical experience, over time, what works for what situations.
Gordon:
One of the things people adopting microservices have found to be very
difficult is figuring out what these boundaries are to start with. In fact,
I've even seen for some situations the recommendation that maybe you start out
doing a more monolithic application, and then break that out into
microservices, once you understand how the parts relate.
Mark:
This is one of the areas where you might call me a purist, because I take
exactly the opposite tack. I think part of the reason we don't know, we find
difficulty in finding those boundaries when we're trying to decompose an
application, is because we've deliberately ignored them. They were unimportant
in a host‑based environment.
If
you put the files down in their own root and two different parts of an
application share them, on a host it doesn't matter. There is no boundary to
cross. As we start putting applications into containers, if you treat them as,
what someone I found out last week calls, "Virt‑Light," if you treat
them as if it's a virtual machine that you're stuffing things into, you
actually continue to obscure the communications that you've been ignoring
before.
I
think it's still early, and I think people are going to probably take the
monolithic path at first as a perceived easier first step. But I think it's
really important to start uncovering the ways in which these covert
communications can hide inside the applications and try to find ways both to
identify them a priority, to figure out whether they need to be there in the
first place, and then figure out how to flag them, split them out, establish
proper communications boundaries.
In
some senses, this mirrors the object‑oriented wave that took place in the '80s
and '90s where one of the points of object‑oriented programming was to enforce
the boundaries, the modularity, and the coherence. Some of the people took it.
Some people decided that wasn't so important after all.
Gordon:
New global variables are really useful.
Mark:
At times, yes.
Gordon:
[laughs] As you were talking, I was thinking exactly the same thing,
because I mean none of the things are perfect today. But I think it's
absolutely true that when you first saw object‑oriented programming out there,
there were a lot of people that couldn't be bothered with having to use methods
to get data out of classes and that thing. You took a lot of shortcuts.
Mark:
It was perceived as a lot of these new waves are, it was perceived at the
time as overhead, as extra work, as unnecessary work. I know what's there. I'll
go get it. The changes have been informed by the recognition that software has
a life cycle and, that by doing this little bit of overhead, it actually frees
the developer of whatever the tool is to change the implementation without
causing problems for the user on the other end; for the consumer, in the case
of libraries or objects.
Because
containers are this object where we want to treat them as a unit, and then we
want to be able to push things in and get things out, these boundaries are
going to become very important.
If
we expect in the end to build this hardware store mentality, where someone can
go in and get, "I need a database container, but I need one that's tuned
this way," rather than having one container for the database, which you
have this monstrous set of tuning parameters.
What
I'd like to see is that we discover, "Gee, there are some people who can
just use the default tuning parameters, who never touch them, and that's
fine." Then you might find others where they have specific patterns,
because I suspect that not every tuning parameter has equal value.
You're
going to find specific situations where you want to tune specific things. The
response to that rather than having one highly configurable thing is to have a
small set of slightly tuned ones, and you can go and say, "Oh, I want the
generic database thing. Or, I want the storage tuned database thing. Or, I want
the throughputs tuned database thing," and then only passing parameters
that are necessary to get your job done.
It
puts some of the work back on the developer to try, and think through the
common use cases, and figure out what the right tuning choices are, but it's
going to make it much easier for the consumer in the long run, if we can shift
that work.
Gordon:
Well, great. It's, as always, been a great discussion today, Mark. Thank
you.
Mark:
Thank you.
No comments:
Post a Comment