josephjacks

They spent only $15M of the nearly $500M in VC they raised to get to a $500M+ ARR business. Let that sink in.

Sam doing a 180 on non-profit to for-profit was egregious, IMHO. Having said that, plenty of extremely profitable organizations masquerade (literally and figuratively) as non-profits.

Also: https://twitter.com/elonmusk/status/1626516035863212034

I love the casual feel of this app. I would just keep this humming along in the background during code sprints and general digital (a)syncing with friends.

I hear you... but this "run an auction" narrative he's proposing is very dangerous if implemented in any way close to actual auctions.

This is horrifically BAD advice. Shopping a TS to a few folks is not an unwise thing to do, but running a full-blown auction absolutely is!

Founders: If you want to ONLY optimize for max price + max check size, the “partners” you bring into your business are bankers.

Hey, Tony. :) I believe that COSS companies are extremely successful when they are able to build large and successful positive-sum and inclusive ecosystems around their FOSS core (specifically, that core being FOSS licensed, not source-available license'd). My partner Heather Meeker has written most of these non-compete licenses. They are useful at the crust around the core, not in the core, IMHO.. if they are applied to the core, there is very little distinguishing it from freemium/proprietary which != FOSS. Also, many of the most successful COSS companies never raised a cent of VC to get to scale: Jetbrains, Liferay, Odoo, etc. and the ones that did raise a similar amount of money to get to scale did not really need it, they just accepted it along to way maybe to speed growth a bit, but their commercialization strategies were often working quite well and their customer acquisition costs highly efficient.

Two resources:

1) http://oss.cash/

2) https://medium.com/open-consensus/

I tweeted an analysis of the S-1:

https://tinysubversions.com/spooler/?url=https://twitter.com...

Envoy is an extremely exciting project. I've been following it closely since OSS inception and am thrilled to see the upcoming deep integration with the Kubernetes project. Such a natural and complimentary fit!

With flexibility as both a side car and host proxy network call fabric for polyglot distributed services, I see Envoy as a kind of modern ESB for the reincarnation of SOA we are seeing in the microservices movement. Congrats to the awesome contributors from Lyft/IBM/Google and others!

My team at Apprenda built the first K8s distro/toolkit (0) with support for Linkerd last year.

0: https://github.com/apprenda/kismatic/blob/master/docs/LINKER...

The folks behind Rook at Quantum have put together an operator (custom K8s controller and TPR) for Rook: https://github.com/rook/rook/tree/master/demo/kubernetes

As long as your apps run well in containers (Docker or Rkt or others even), they can run and work well on K8s, which also runs well on AWS. You should consider K8s to replace imperative CM-based (Salt/Ansible) deployment mechanisms. The native pod abstraction in K8s can also nicely address multi-container composition issue you mentioned.

Minikube is awesome! We used it at Apprenda in a recent K8s 101 webinar (0). Standing up a local K8s cluster in 1-2 minutes is a really great experience.

(0): https://apprenda.wistia.com/medias/ckbmoa10sd

Thanks for the great blog, Mike!

I think the article provides some great foundational perspectives on how HA/service discovery/port mgmt and so on were handled in the "pre-containers" era of VMs with a look into how these challenges are somewhat re-imagined in this current world of containers (predominantly Docker). I'm looking forward to the follow-on post about why they chose Kubernetes and how that solution works for them.

Take a look at the new DaemonSet abstraction Kubernetes. Great for running things like HDFS and other distributed data workloads/frameworks: https://github.com/kubernetes/kubernetes/blob/release-1.1/do...

Kubernetes is supported on AWS by various companies in the industry, including my own, Kismatic (the enterprise Kubernetes company). We have been pushing for the team at ECS to adopt K8S as a standard framework on which to run containerized workloads. As Kubernetes gets adopted as a container cluster management standard for orchestrating and running microservice-oriented apps, all the cloud providers will need to support it based on customer demand, in the same way they are all supporting Docker due to the demand.

Great series, Kamal! Keep up the great work.

Disclaimer: I work for Kismatic.

It's exciting to see further investment in Intel® Clear Containers. At Kismatic, we have been fans (0) of Clear Containers since the beginning!

(0): https://kismatic.com/technical/quickstart-intel-clear-linux-...

To clarify, this entire statement is categorically incorrect: "The only thing I'll add is that k8s isn't targeting the same scale as Mesos. Their current goal is to support up to 400-500 nodes, max."

This is great to see independent software companies like Meteor embrace Kubernetes as the platform on which to build their next-generation services [0].

[0] http://info.meteor.com/blog/meteor-and-a-galaxy-of-container...

Only on their public cloud. For internal workloads, they run everything in containers. Mostly cgroups containers.

Understood, I was referring to major point releases vs minor. Thanks for clarifying.

I see Docker 1.6 in your [2] link, where do you see they are two versions behind Docker?

This is categorically incorrect. K8S will ultimately scale to N number of nodes. Within 2015, it will scale to 1K+ nodes, as per the roadmap. Being modeled after Google's Borg system, I encourage curious/interested folks to read at the recent Borg paper [0] which also outlines lessons learned in running Borg at Google for nearly 15 years and managing many millions of machines.

[0] http://research.google.com/pubs/pub43438.html

Disclaimer: I work for Kismatic.

I think the question was specifically in the context of CC.

I really like that Xoom is taking a phased approach with their service discovery model and not completely throwing out ZK right away. Shows that you can gradually bring Kubernetes into your environment without needing to re-think the entire stack, thanks to K8S's modular and extensible design.