darren0

This is an amazing announcement, but... The beta requires a NDA. The source code is also not available. This gives the impression that this will be a closed commercial product and that really takes the wind out of my sails.

This component basically acts as a control plane for LVS which is implemented in the kernel. The data plane is not Go. Basically this load balancer is really the Linux kernel (and it's blazing fast).

I just wanted to throw into the mix Rancher. Rancher is a more recent comer into the space and still in beta. Rancher focuses on simplicity, flexibility, and pragmatic solutions for Docker based infrastructure. Rancher is different in that it can be deployed in conjunction with all of these systems mentioned or can be ran as a replacement. It includes a scheduler, load balancing, health checks, service discovery, application templating based on compose syntax, storage management, application catalog, upgrade management, github/ldap integration, UI, API, CLI, etc.

Disclaimer: Co-founder of Rancher Labs and chief geeky guy behind Rancher

This is shameless self promotion but check out rancher.com. It's open source and allows you to spin up a container service like GKE or ECS but cloud independent.

After running Linux on MacBooks for the past 5 years I would strongly recommend against it. The basics usually work fine but you are constantly dealing with issues. Each MacBook revision introduces some new issue. For example the webcam recently switched from being usb attached to being attached to the PCI bus and Linux doesn't have drivers yet. Other things like GPU switching, multi monitor, display brightness, all have quirks.

Just recently I gave up getting MacBooks to work with Linux and went back to ThinkPads and I couldn't be more happy. Granted you can still buy ThinkPads that have similar issues as the MacBooks. The difference is that you can find a ThinkPad (or some other brand) that works practically flawlessly. With the current line of MacBooks, not a single one doesn't have huge issues (like the webcam).

And you may be surprised that I ran socket activation well over 15 years ago, so yes I'm well aware of the approach. The comment is more around the fact that in CoreOS's post they seems to harp on the security of a daemon process running as root that is responsible for spawning containers. What I'm saying is that with socket activation you will essentially have that again. Rocket can only work around it today because they have systemd as PID 1 running as root doing the socket activation.

The app container specification has socket activation in it. This is going to essentially tie it to systemd. Otherwise you will need another daemon running to do the socket activation, but then that would seem to be a "fundamentally flawed" execution model.

Rocket is tied to systemd, that will definitely spawn some interesting discussions. https://github.com/coreos/rocket/blob/9b79880d915f63e7389108...

I wonder if Ubuntu LXD will participate in this?

Chief architect of Rancher here. Rancher.io is in fact completely open source. The intention is that Rancher will run below Docker. Rancher currently wraps Docker but going forward that will no longer be the case. We very much want users to use the native Docker CLI and remote API.

Rancher is packaged as a set of Docker containers. This may seem like inception but we build off of the portability guarantees provided by Docker. This means that the storage and networking services we provide should run anywhere Docker runs.

The source code for this project is mostly in https://github.com/rancherio/cattle at the moment. We will be moving things around quite a bit and in the end we will have a lot of repos that comprise the project. https://github.com/rancherio/rancher serves as a meta-repo that packages up all of the other repos.

Fleet is used only to bootstrap the system. It has very little to do with the larger architecture of stampede or cattle. I view orchestration and scheduling as two completely different topics. When looking at IaaS the scheduling needs are initially quite simple. As such I don't have a mature scheduler and really don't intend on building one. As your requirements mature the needs for more complex scheduling is needed. I've gone down that path many times and it snowballs so quickly into a very difficult problem.

With cattle I’ve purposely decided to defer the scheduling needs to something like Mesos or possibly YARN. I don’t intend to try to reinvent that wheel. I have yet to do that integration.

The CF Diego approach is one that seem very common today. In general all of the Docker “orchestration” platforms out there today are mostly just Docker plus a scheduler. This approach is great, as long as you don’t need complex orchestration. As the CF folks point out, complex orchestration is hard. If you can remove the need to orchestrate and build a system that needs only a scheduler it is generally much simpler and easier to scale.

The problem I have is that stampede focuses heavily on real world application loads and boring practical issues that exist in crufty old applications that exist in the wild. These apps have requirements that necessitate complex orchestration. As such, with stampede I tackle orchestration head on. I try to find a sane and scalable approach to it. Which is really quite difficult, but it is my area of expertise. I feel if I have a platform that can excel at both orchestration (from the native capabilities of cattle) and scheduling (by leveraging a mature scheduler framework) I’ll have an extremely capable base to build the next generation of infrastructure.

Creator of cattle.io here. There are far too many topics to address here, but I’ll give you a brief overview of how cattle.io works. The high level orchestration system’s role is to manage the state of resources and their state changes. When states are changed events are fired that may or may not be required to be handled to ensure that that state transition can be completed. The important thing here is that the high level orchestrator does not actually perform the key logic to complete an operation. That logic is delegated to an agent or microservice. The scheduling of which agent or microservice handles each event is specific to the nature of the operation (long running, targeted to hypervisor, etc).

You have to pick either kernel or user space, not both. Either implement it purely in the kernel or purely in user space. In reality pure user space is faster, just look at Snabb switch https://github.com/SnabbCo/snabbswitch/wiki

Hi, I'm Darren Shepherd, creator of Stampede. https://www.linkedin.com/in/darrensshepherd I currently work at Citrix with my primary responsibility being an architect of Apache CloudStack. In the past I've deployed clouds based on CloudStack and OpenStack, and written two proprietary IaaS systems from scratch. Stampede is now my third IaaS system I've written from scratch and I'm quite proud that this time it's all open source. For whatever reason, I love infrastructure orchestration and writing these systems is what I've done full time for about the last 5 years.

From an end user perspective, you can basically look at it as OpenStack + Kubernetes.

That's something I just came up with. How the containers are setup for the management stack is incredibly complex. The wrapper was created to manage the insanity and hacks. Born out of those hacks was https://github.com/ibuildthecloud/systemd-docker which might be useful to others. It's a wrapper to manage Docker containers under systemd, which is currently quite difficult.

You can install CoreOS on Digital Ocean with the following script. https://github.com/ibuildthecloud/coreos-on-do

This scam is particarily annoying on the iPhone. They call and hang up so it shows as a missed call on the lock screen. If you are not careful when you unlock the phone and you swipe where the phone number is, it immediately dials back. I absolutely hate that functionality of iOS 7.

Not enabling swap is extremely common in the hosting business. Even in EC2, a lot of the AMIs have no swap. This is to prevent users from thrashing your server hard drives. It's often better to have the customer run out of memory and realize they have gotten too small of a server then for them to start thrashing your HD and then just think your hosting is slow.

I feel so many articles on hn have a myopic view of software architecture. You see this with "full stack" engineer job postings. The desired skills are usually something like RoR, ember, and backbone. I'm sorry, but from my perspective, that is all frontend development. This article refers to backend developers as "sending only a HTML document as a result to the browser." Again, in my world, if your sending HTML, mostl likely that is frontend.

Backend has nothing to do with HTML or any presentation logic. Backend is services.

I know this is a rather unfair judgement but so many articles seem to indicate RoR+JS/CSS+DB is the "full" picture of software architecture. But really, that's frontend. There is a whole beautiful world of backend distributed services missing.