This is your weekly summary of Compose news for those changes and updates which can make your life easier. In this edition, a look at how the Compose architecture means we're always up for your databases and a look back at the week in Compose Articles.
How the Compose architecture protects you
We recently had some issues with our application server, but as always, the databases we deploy to you carried on running. Some have called this curious, but we like to point out that we designed the system so it could withstand exactly that kind of incident.
When you log into Compose, you are talking to
app.compose.io where our management application runs. The thing is, that the application you use has no direct connection to the database deployments we run for you.
Those databases are scattered around the globe in regionally diverse clusters. Your commands and changes are validated by the application and then turned into messages which are sent into our distributed messaging infrastructure.
Those messages are received by our hosts which have their own localized management. They'll take a message, decode it and act on it. On our public infrastructure, one host server will be managing dozens of sub-processes, each carrying a database component.
The hosts don't do it alone though; each host is also part of a cluster, usually spread across availability zones or some other resilient regional structure. A database deployment, made up of multiple database components, will be spread over this cluster. We use the messaging system to coordinate operations over the cluster too.
The application that you use to log into and manage your database deployments is just one of the ways messages can be sent to those hosts and clusters. Our support team, for example, has their own application which can send messages appropriate to checking and repairing database deployments.
We've built Compose thinking about what can go wrong and brought many years of experience to what we know can go wrong. Our decoupling of the web front-end for users from the database deployments and hosts doing the work is a very deliberate act designed to ensure your databases stay running.
Last week in Compose Articles, we talked about database tools and rounded up the database news from around the internet:
First in a new, if irregular, series is Compose Tooltips for MongoDB, PostgreSQL, and Elasticsearch. In this edition, we look at updates to Studio3T for MongoDB and how they make it work with Compose's new TLS rules (TLS 1.2 only). We also check out the latest OmniDB which has added MySQL/MariaDB to its selection (PostgreSQL and Oracle) of connectable databases. There's also a look at Dejavu, the Elasticsearch GUI you can install as a Chrome extension (or a static web page or a standalone server).
In Compose's NewsBits, developments around Redis point to native TLS/SSL sooner rather than later, and we look at the new Node.js 10 as it heads towards becoming the next Node LTS edition.
That's it for this week's Noteworthy at Compose. Onwards to next week!
Read more articles about Compose databases - use our Curated Collections Guide for articles on each database type. If you have any feedback about this or any other Compose article, drop the Compose Articles team a line at firstname.lastname@example.org. We're happy to hear from you.