We definitely understand - we plan on tackling this with the release of our Containership Kubernetes Service. Users will be able to enter the credentials to their hosting provider, and CKS will provision a highly-available and secure Kubernetes cluster on the IaaS of their choice.
This is really nice. In our experience, databases are still a huge hurdle for running stateful multicloud deployments. As we try to simplify multicloud container deployment, global replication and multi-region support are going to come in handy. I’m really excited to start dev’ing against this release, and hope to have a containerized version of FaunaDB available via Containership soon. I’d be interested to gauge interest in a containerized FaunaDB among the broader dev community, since to me it seems like a perfect match.
this is definitely a valid concern. decoupling automation from your cloud provider, moving it a layer up the stack, and leveraging only IaaS, can actually be quite helpful in these scenarios. this is an area where having a multicloud strategy, or minimally the ability to move between clouds at will, is essential.
Wow, this is great - I started using Meter Feeder a few months ago in Pittsburgh. I'm sure Pittsburgh is similar to most of the country in that we've had no choice but to use antiquated meters. It really is one of those situations where since it's now easy, I've found myself always paying for parking, whereas before I skipped on payment more often than not.
Looking forward to watching Meter Feeder execute on its goals, and congrats on the acceptance to YC W16!
Thank you! We believe with native support for running persistent applications, ContainerShip leads the pack in simplicity for a full-featured containerized workload platform.
If you haven't already, check out http://12factor.net/config for their recommended best practice for dynamic configuration between environments through the use of environment variables.
It seems like Confidant can and will be great for customers using AWS, and frankly it's nice to see open source projects built using AWS services, but is not a complete black box (like many AWS services themselves). I also totally agree that utilizing the tools provided by your hosting provider can be majorly beneficial; however, I think that sometimes teams employ hacky solutions so they can use a hosted service from AWS (or similar), in which case they end up with technical debt and the inability to change directions in the future.
As you said, until tools exist that offer operability between clouds, users will be stuck with the smallest combination of tools. I do however believe such a day is coming.
That's an interesting perspective and observation. I've always found lock-in to be a bit scary, and I've heard this echoed by a number of colleagues & companies. No one can deny the usefulness of tools provided by hosting providers, namely AWS; however, to me, architecting a system in such a way where you are literally unable to jump ship when the need arises (compliance, cost, etc) is unacceptable. With hybrid / multi cloud more of a reality with the existence of tools like Docker (and others), there needs to exist sets of tools capable of handling such variability. I digress, this really belongs in an entirely different thread.
This article needs significantly more content to be useful to a user genuinely curious about the topic. Answers to the following questions would improve its usefulness:
Why would someone normally install globally?
What are the advantages to installing globally?
How can these advantages be reproduced, without global installation?
Are there disadvantages to using scripts?
[... etc ...]
Creating content for the sake of creating content is as useful as saying "don't do it" in regards to global npm installs.
ContainerShip, the open source software, is different in a few ways.
* Automatic clustering of nodes. Follower nodes should automatically find and cluster with existing nodes.
* Out-of-the-box load balancing via on a port generated when an application is created.
* Built-in service discovery which easily allows you to communicate with other applications running on your cluster.
* Easy extensibility provided through a plugin system. For instance, the open-source web-ui where users can interact with their cluster is simply a plugin on top of the core ContainerShip software.
ContainerShip Cloud offers more compelling differences such as:
* Automatic installation on your favorite cloud provider with a few clicks (constantly adding new providers). As well as the ability to scale your cluster (leader & follower nodes) directly from ContainerShip cloud when additional capacity is needed.
* Point-in-time backups of the entire state of your cluster, including all applications and any persistent data being written to a volume.
* Restoration of backups to the same cluster, or an entirely different ContainerShip cluster you are running on any cloud (or on-prem).
Even more features are currently in the works. I hope this helps.
When launching a cluster from ContainerShip Cloud, ubuntu is installed. You can install ContainerShip, the open source software by hand on any linux distro; we will be supporting more distros from the Cloud interface in the future.
The pulldown is powered from dockerhub search.
Private docker repositories with authentication are currently in the works.
containership/engine is the default image if one was not provided. It sounds like there may have been a bug when passing "molinto/nginx". Even if it does not autocomplete (it doesn't seem to find it using dockerhub search for me) passing that string in the Create modal should still set it correctly.
Co-Founder here. containership is free and open source (https://github.com/containership/containership). You can run it in the cloud or on-prem behind your firewall. Our SaaS product, ContainerShip Cloud, allows users to launch clusters on providers with a few clicks, as well as backup the entire state of their cluster (including persistent data) for disaster recovery or to move between your Containership clusters with a click. Users still have direct access to docker.sock on their clusters, so everything is still under your control.