HN user

normanjoyner

82 karma

[ my public key: https://keybase.io/normanjoyner; my proof: https://keybase.io/normanjoyner/sigs/BeTloBPqK-OJa2scO4ZKpPN4AUakVlMKxZPld0BUTP8 ]

Posts36
Comments20
View on HN
www.protocol.com 6y ago

Google Cloud CEO: Istio is going to a foundation

normanjoyner
4pts1
github.com 7y ago

Show HN: Kubevm – Manage local Kubernetes client versions

normanjoyner
1pts0
blog.containership.io 7y ago

Managed Kubernetes: EKS vs. CKE

normanjoyner
4pts0
blog.containership.io 7y ago

Containership Cloud Platform Kubernetes 1.11 Support

normanjoyner
2pts0
github.com 8y ago

Show HN: kubectl-tmux-ssh – A kubectl plugin to ssh into kubernetes nodes

normanjoyner
6pts1
medium.com 8y ago

Show HN: Overlaycloud – A New Type of Cloud Computing Platform

normanjoyner
9pts0
www.fitbit.com 8y ago

Fitbit ionic

normanjoyner
11pts1
techcrunch.com 8y ago

VMware expands hybrid cloud strategy

normanjoyner
2pts0
money.cnn.com 8y ago

Consumer Reports pulls recommendation for Microsoft Surface laptops

normanjoyner
3pts0
containership.engineering 8y ago

Bringing Kubernetes to Containership

normanjoyner
1pts0
containership.engineering 9y ago

Securing Containerized Infrastructure with iptables

normanjoyner
4pts0
containership.engineering 9y ago

DynamoDB to Postgres. Why and How

normanjoyner
13pts0
containership.engineering 9y ago

Tiling (Microsoft) Windows

normanjoyner
5pts0
github.com 9y ago

Feature request: node --install

normanjoyner
3pts0
medium.com 9y ago

Docker builds for apex

normanjoyner
2pts0
github.com 9y ago

Show HN: Tide – A cron-like job scheduler for ContainerShip

normanjoyner
10pts0
www.reddit.com 9y ago

Reddit is down

normanjoyner
8pts3
abstractions.io 10y ago

Abstractions Conference

normanjoyner
1pts0
calendar.google.com 10y ago

Google Calendar is down

normanjoyner
156pts78
medium.com 10y ago

Don't Reinvent the Platform

normanjoyner
5pts0
medium.com 10y ago

Don't Reinvent the Platform

normanjoyner
10pts0
medium.com 10y ago

Don't Reinvent the Platform

normanjoyner
13pts0
content.containership.io 10y ago

ContainerShip 1.3.0: native support for containers with persistent data

normanjoyner
5pts0
vimeo.com 10y ago

Migrating a containerized DNS server with persistent data using ContainerShip

normanjoyner
6pts0
github.com 10y ago

ContainerShip Community on Slack

normanjoyner
6pts0
github.com 10y ago

Spinning up an open source ContainerShip cluster locally

normanjoyner
8pts0
github.com 10y ago

ContainerShip 1.3.0 released with native persistent data support

normanjoyner
7pts2
blog.containership.io 10y ago

Tide – Cron on ContainerShip

normanjoyner
2pts0
github.com 10y ago

ContainerShip: simple, open source container management in Node.js

normanjoyner
6pts0
github.com 10y ago

ContainerShip: simple container management in Node.js

normanjoyner
6pts0

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.

Alibaba Cloud 9 years ago

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.

[dead] 10 years ago

Seems to be back now; pretty quick resolution.

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!

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.

We built https://github.com/containership/codexd (based on our https://github.com/containership/node-btrfs module) which provides filesystem snapshots / restoration for btrfs. Additional filesystems such as ZFS will be supported in the future. If a user does not have one of the supported filesystems installed, tar archives will be used. This library is not yet merged into https://github.com/containership/containership.core, but once merged will provide the ability for persistent data to be moved between servers, if and when a container moves.

Data persistence is already fully functional in our hosted Cloud offering.