Recently, we got a support query... "What's a capsule? I see it mentioned in various Compose related messages but it's never explained". And it's our bad for not having really explained what capsules are, but then here at Compose, capsules are just part of every day life, like coffee, more coffee and the coffee. We've mentioned they have names when we talked about downloadable log files.
We defined them as the "unit of compute power around Compose" when we looked at software defined networking. But we've never really explained what they are so here's everything you might need to know about capsules.
Compose's infrastructure takes large servers and slices them up into smaller chunks using containerization, Linux Containers (LXC) to be precise. Containers are not virtual machines but they are a smaller slice of the resources of the system they are held on. You get a lot of control over how those resources are allocated with LXC so you can efficiently and effectively slice up a larger system. You can also adjust the resources allocated to a container on the fly, the importance of that we'll explain later.
You may have heard of containers as it's the technology that some companies have built on to produce their own application packaging/deployment systems. But containers and LXC predate them and Compose has been using them for quite some time.
Enter the Capsule
Capsules are the what we call our running containers at Compose. Each one is created from a combination of "slug" images which contain the binary files needed for the capsule to do its job. Once the slugs are combined and running they contain the components which are needed to provide a particular service.
We have our own build technology for slugs. We can take a "base slug" and install all the bits needed for it to do its task. We can then store them and retrieve them to create capsules anywhere they are needed.
The most common task for a capsule at Compose is running a node on a database. For database nodes we attach a data filesystem for storing the actual data and we can customize a capsule to optimally support a particular configuration or specialization of database node.
The other common use for a capsule is for access to the database – the Compose portals for SSH or HTTP/TCP access run from their own customized capsules which ensures they are appropriately isolated from the other components. It also allows us to add or remove portals on demand so if you only want one access method, that's all that is configured.
The newest class of capsule is the Add-on capsule. There are capsules configured to provide extra services which users can opt-in (or later opt-out) of having as part of their deployments. The New Relic Add-On, for example, has just gone live on MongoDB and uses a capsule to host the MeetMe, Inc monitoring plugin within your MongoDB Elastic Deployment.
By keeping it in its own capsule, the possibility of unintended interactions is reduced and it's easy to deploy when needed. Because they are allocated and consume resources, add-on capsules are billed in addition to the cost of the deployment. The cost is dependent on what the Add-On does and what kind of resources it consumes.
We have physical hosts that are optimally configured for data, CPU and memory. Database capsules will be configured on data hosts as they need high IO performance, portal capsules on CPU hosts as they don't touch the disk much but need to be quick, and so on.
The Compose infrastructure is built around creating software defined networks between multiple physical hosts which connect the many capsules running on those hosts. A deployment of a database – what you get when you select
Add Deployment in the dashboard – is physically distributed automatically between the hardware with the fastest possible paths to communicate between the capsules.
On each physical host all the capsules are monitored. If we see that a Capsule is in need of more resources, the Compose infrastructure can respond. For example if a capsule is regularly asking for more memory, then we trigger the scale up process.
This scale up doesn't just affect the one capsule, but, in the case of distributed database capsules, when one scales up, all are scaled up. That scaling up though just involves coordinating the increase in available resources with no restarting of the capsule needed. Capsules enable this at the physical host level while the Compose infrastructure manages the changes across the rest of the deployment.
In the past we've kept our capsule technology away from our user interface. We know that our users like to be able to quickly and simply bring up a database and have it accessible quickly and we aren't going to stop doing that. In the future though, we'll be releasing more Add-On capsules for our various databases. We aren't announcing any today, but safe to say future add-ons will include monitoring, integrated analytics, connectivity and advanced ETL. And each one will be integrated into the Compose dashboard. As we do release these and some other enhancements in the pipeline, you'll be able to be more aware of our architecture and that's why we thought you should know what a Compose Capsule is.
Photo Source: NASA