Hacker News new | ask | show | jobs
by nickmerwin 3519 days ago
Here at Coveralls.io we can't recommend Replicated enough. We were able to migrate our internally-developed, Github Enterprise style packaged VM delivery approach over to their system in a couple weeks.

But I'd say the real value is in not needing to support an additional deployment platform -- their Docker based approach is like Heroku for on-prem, it abstracts the infrastructure details and just works.

2 comments

Container folks currently advise to not put the database into a container unless you really really really know the internals of both. Even Kelsey Hightower stressed this in a talk - "if you want to keep your job, keep databases out of containers". ReadMe had no prior Docker experience, and they started by putting Mongo (which is complex to manage as is) into a container. This would make me uneasy.

Does Replicated assist with this database/persistence layer? Perhaps by helping you to spin up the DB as a separate VM on the clients' side?

Replicated founder here. Great question. The main concern most people have when considering putting a database in a container is around data loss or corruption. (i.e. What happens if the instance disappears and the data was stored on an ephemeral disk?) We have a couple of features to help with this:

Replicated allows for the end customer to choose if they want to run the containerized version of the database, or provide their own instance of it (not in a container) and simply provide a connection string so the application can use that instance. Generally this is exposed as a checkbox on the settings page, and doesn't require a lot of configuration.

If the end customer decides to install with the containerized version of the database, they can choose to run the database container on a specific instance (or instances) and control the host path of the volume mount(s). The idea here is that they will store the data on an EBS volume, network attached storage etc.

We also have a feature that allows for snapshots and restores to help in the scenario where the database was store on the local instance and there was a hardware failure or corruption.

These features work out of the box, without a lot of effort from the software vendor to configure.

Thanks, Marc.

After reading your docs and install scripts, I think another option for us is to run the database directly on the client's host. That is, as part of our installation guide, we'd say Step1:Install Replicated, Step2:Install DB, Step3:Run setup. This might be easier in a trusted environment where containers can be started on the host network. This approach has potential issues with replication, encryption, upgradeability, etc, but those are normal infrastructure challenges and have nothing to do with Replicated.

I can't find any details on Replicated pricing, is it reasonable? It seems like a product which would be nigh impossible to replace once installed at a customer site (making the customer do anything risks cancellations).
IIRC it's 10% of sales to begin with and goes down to 5% after some threshold. I'm sure marcc will correct me if I got it wrong.