I want to like this, but I can't figure out what it actually does. The intro just says it provides "an API" without saying what functionality it provides, and there seems to be zero usage documentation.
Maybe someone who's looked at the code could explain what this is for and what value it adds to the existing Kubernetes API?
(Protip: if you have six projects with six identical README files, the README probably isn't adding any value.)
I feel similarly to the GP. I'm interested in PaaS solutions and have had successes with Keberenetes. If this filled some of the gaps in the PaaS space for me, then I'd be really interested.
There are conveniences that a proper PaaS could provide on top of Kubernetes, e.g. Heroku's deploy-on-Git-push feature. I just don't know if that's the kind of thing this project is targeted at.
Lots of services, easy to try (just one command: https://github.com/tsuru/tsuru-bootstrap), support docker clusters(pools), auto scale, metrics, in production using docker since the beginning (about 2 years).
i.e.: if you have some bored operations engineers just twiddling their thumbs, you can totally self host a complicated solution. Assuming you have a very common, boring problem like web service hosting or object storage.
Operations loves flavor of the month tools under active development, right?
Cloud Foundry can run Heroku buildpacks out of the box. Several of the bundled buildpacks in a CF release (Ruby, Python, Node, and I think Golang) are wrapped versions soft-forked from Heroku's.
The others (Java, PHP, Staticfile, Binary) were written specifically for Cloud Foundry.
Source: I worked on the CF Buildpacks team for a while.
I wish these kind of shops would get an outsider to write their landing page spiel. It is incredibly hard for insiders to get that right, sea they swim in, woods for the trees kind of thing. Try to remember that the world you live in is yours only, and if if you try to entice someone standing at the gate to get in you really need to up the spruik.
Reading the page tells me little about whats actually going on inside, apart from the fact that its "Awesome, great, etc." and a bunch of irrelevant implementation details. And I'm not picking on Kel or Gondor here, its par for the course.
Techs take note: You need to up your ken on spruiking your shit. We are all special little snowflakes. Aquire customer empathy.
The docs are a little sparse but reading between the lines it's a set of tools for configuring k8s clusters at a higher level of abstraction than gcloud and kubectl. If you've built out automation to deploy k8s services then you know that there is still quite a bit of manual configuration needed to define the clusters, repl controllers, services, ingress, persistent disks, etc. If you wanted to build a PAAS on top of k8s then you'd begin pretty much as these guys have, I think.
I'm very heavily working with k8s and while what you say is definitely true, I'm not too bothered by what I have to configure (aka stuff I can control directly). What I really dislike is stuff on which I have no direct control and that's the main problem with k8s. Lot of stuff "just works", with little-to-no documentation on what are the pieces concurring to make it work nor how it is configured.
The 'it just works' approach might be great with simple scenarios, but it's horrible for complex use cases where you need to have detailed control over the pieces that will run in production and - once they are properly setup -, you would anyway automate accordingly your specific usecase.
Hence my: "Additional hidden complexity doesn't seem to be a good thing in this case".
Beside that, I really have no idea about what they specifically mean with "Kubernetes-based PaaS". What is it? Abstracting kubernetes cluster setup? If this is the case, i remark that I need more fine-grained access on the internals rather than additional abstractions that internally do "god-knows-what".
Serious question, why would you use Kel/Kubernetes over DC/OS https://dcos.io? DC/OS is feature mature, the web interface looks rich and beautiful, and it has a track record of scaling.
For Kubernetes vs Mesos vs Swarm vs other container schedulers you should pick the one that has the maturity, reliability and operational overhead that your team is comfortable taking on.
An important dimension is the data store. These all depend on a HA consensus based database:
Etcd, Consul, Zookeeper. Set up, automation, monitoring and scaling is different with each.
Aside from this schedulers are undifferentiated technology. Tell it what you want to run and trust it'll fulfil your request.
User Interface is generally going to be a matter of taste. A beautiful web app doesn't matter if your team wants a CLI tool or a fully automated CD flow.
I don't have first hand experience by my research shows that Mesos is the most mature but is pretty heavy to set up and manage. And that DC/OS is a very polished interface.
He is obviously saying this project only supports GCE. K8s supports other environments, yes, but this project could use K8s in a way specific to GCE (e.g. managing machines with gcloud ssh related apis)
"Kel helps DevOps professionals manage their application infrastructure through a layer of tools and components that make Kubernetes accessible and easier to use."
I'm not sure if the OP is a project member but it would be helpful to see more details in the docs covering how exactly the project aims to or already makes Kuberenetes easier to use.
From what I can tell it looks more like continuous delivery on top of kubernetes.
Mesos on the other hand is a data center management. You actually can run Kubernetes on top of it as you can run chronos (distributed cron), marathon (containers such as docker) etc.
Do you know of any sites actually running kerbernetes-on-mesos? I've been using that as a talking point for a while too, but have yet to hear of it actually being used anywhere. Not trolling here, I just don't know.
I know about it, because my company is currently evaluating it. Running it on Mesos, gives us ability to also use other Mesos applications such as Chronos.
cool - I'm interested in hearing how it works out for you. We're running mesos (not DCOS, but still mesos) with a couple of other frameworks, but I haven't had any time to try running kubernetes on it.
"Crusty" is just another way of saying, "I've actually used it for a real application before, or at least know someone first-hand who's used it in production".
When something is early in the HN hype cycle, all anyone knows is blog posts and "hello world" experiments. So it's awesome. Once you use something for a real project, you inevitably run into real-world issues or limitations. So it sucks. And you chase the dragon toward the next newly-hyped thing.
In all seriousness, though... sheesh. Django isn't even a decade old yet. Rails is older, and Sinatra and its clones are barely any younger. There really haven't been any revolutionary ideas in MVC frameworks this decade.
It's coming from an era of browsers not capable of rendering dynamic websites. Use of that essentially creates huge technical debt from the beginning. There is now a lot of better ways to create web clients etc.
Not every web application is well-suited to be a SPA. Frankly, only a minority are.
Even if you ARE putting most logic on the client-side, you will always need endpoints to provide server-side functionality.
By the time you've finished writing interceptor middleware, proper CSRF protections, and other things you'll need in a real-world application... you will have written your own MVC framework. And probably done a far more lousy job than the people who focus on that full-time.
A fairly basic server-side framework is only "huge technical debt" if you're an unemployed college student tinkering with "TodoMVC" examples.
Considering I spend $5 a month on my digitalocean droplet that runs docker 1.11 and a bunch of containers (nothing consequential though), and Gondor wants $100 for their entry-level "dev" tier...
Of course. But you may also correctly presume that I'll question why this would cost US$100/m for a "dev" offering. Considering what I can get for that from the other incumbents.
Some more background info here regarding Kel and it's relation to Gondor by Brian Rosner, the main dev of both Gondor and Kel as far as I can tell: https://brosner.com/blog/2016/05/05/kel/
Maybe someone who's looked at the code could explain what this is for and what value it adds to the existing Kubernetes API?
(Protip: if you have six projects with six identical README files, the README probably isn't adding any value.)