Live data from Hacker News

As Kubernetes grows, a startup ecosystem develops in its wake

techcrunch.com

101–110 of 156 posts

Re: As Kubernetes grows, a startup ecosystem develops in its wake

#101
post #22

Earlier quoted context omitted.

The portability is not as attractive as a fully integrated solution though, for types of people that are not already attracted to Kubernetes. Where I work, we use AWS and say that "we love vendor lock-in." The more integration with the rest of the vendor's cloud platform, the better. I think it's a great example to say it is idiosyncratic that I can create a PD by creating a PV, but I can't reciprocally enumerate PDs…

I think I'm missing something. K8s needs a role with the correct IAM permissions to create the resources on the AWS side, it can't do it magically. Which means that someone granted these permissions before. If anything, your InfoSec department should love that. IAM is pretty fine-grained, so they can control what gets created. Types of resources, and whatnot. Just don't grant star permissions to all of EC2.

(Spoiler alert: you got me, InfoSec typically does love this stuff. If it was just up to InfoSec, these types of things would be approved because they are so well organized and easy to understand. The alternative being, to deal with another vendor that has another completely different security model, which InfoSec actually has to do all the time.)

Fact is InfoSec is not at liberty to set priorities for new technology development. I have to either drag the whole group with me at an institutional pace, or get someone at a higher pay grade "who will stake their career on it," in order to help me meet my goals, which really may or may not be achievable simply by means of adopting this advancement. On the other hand, lots of people who are not InfoSec like to "help" with the ostensible jobs of InfoSec, ...

which is often seen as simply delaying progress until the problem can be fully understood and the solution agreed to by a quorum? Man I can't wait that long

I'm a bit salty can you tell

Re: As Kubernetes grows, a startup ecosystem develops in its wake

#102

Earlier quoted context omitted.

I don't think that's true. If you believe the team that designed Kubernetes, Kubernetes is an attempt to improve on Borg. Borg is an accumulation of a decade's work with containers at Google, and has been described by googlers as a rich but a little messy, having been designed incrementally over many years as needs have surfaced. Borg could never be open-sourced because it's so specific to Google; for example, it use…

All of the things you described as improvements are more complexity and layers of indirection. Kubernetes may be an attempt to improve on Borg but adding on a bunch of features and plugin architectures to solve more use cases isn't necessarily an improvement.

Is your assertion that k8s suffers from "second system syndrome" when compared to Borg?

Re: As Kubernetes grows, a startup ecosystem develops in its wake

#103

Kubernetes is one of those rare cases where the industry is rallying around a technologically sound platform that emerged from the trenches, and not something that was designed to create jobs for consultants. It's great. Right now, there's a bunch of fairly traditional players such as Red Hat, but none of them are in a position to mess it up. What I'm waiting for, though, is for a big player to do a modern, clean "Ku…

>> Whoever wants to compete in this space have to compete not just with GKE, but with the technical awesomeness of GCP. After years of using all the major clouds - Google Cloud has the best performance and primitives, but the worst support and operational/business features. If you want the fastest VMs/storage/networking, and are fine with non-standard APIs and beta SDKs, then it's a great platform and has super simpl…

Funny, I had the exact opposite experience when it comes to APIs. Doesn't AWS have a PM for every product with different API each time? Tried to build something like a terraform using boto only to give up after dealing with inconsistent APIs for about 2 weeks.

Re: As Kubernetes grows, a startup ecosystem develops in its wake

#104

Kubernetes is one of those rare cases where the industry is rallying around a technologically sound platform that emerged from the trenches, and not something that was designed to create jobs for consultants. It's great. Right now, there's a bunch of fairly traditional players such as Red Hat, but none of them are in a position to mess it up. What I'm waiting for, though, is for a big player to do a modern, clean "Ku…

> What I'm waiting for, though, is for a big player to do a modern, clean "Kubernetes first" cloud offering.

As someone who is feeling burned over picking swarm over k8s, I'm not super into the idea of trusting a 3rd party to do k8s first.

Anything anyone implements well will be ported to gke in due time, no?

Re: As Kubernetes grows, a startup ecosystem develops in its wake

#105

Earlier quoted context omitted.

That's not what I meant, though. A Kubernetes PV is an abstraction that causes a controller allocate a GCE disk (which of course is another abstraction), but if you create a GCE disk through the CLI/UI/API, then you don't get a PV.

Why would you expect that? Or use it that way? The clouds are IaaS, and Kubernetes is like a virtual human that creates resources using the same APIs you would. It's on K8S to keep track of what it's creating.

That's what I mean by "Kubernetes first".

Why not use Kubernetes to declaratively define nodes, disks, load balancers, firewall rules, DNS rules...? If you look at Terraform, for example, it's just an "object store" (the state file) that you modify in order to "converge" your infrastructure.

If you're already using Kubernetes via GKE or a similar IaaS, then of course Kubernetes has underlying primitives (GCE disks, GLBCs, etc.) that are exposed. But those primitives are exposed because GKE runs on top of GCP.

What I'm proposing is a "KaaS" where Kubernetes is the control plane, without the baggage of an additional API.

Re: As Kubernetes grows, a startup ecosystem develops in its wake

#106

Kubernetes is one of those rare cases where the industry is rallying around a technologically sound platform that emerged from the trenches, and not something that was designed to create jobs for consultants. It's great. Right now, there's a bunch of fairly traditional players such as Red Hat, but none of them are in a position to mess it up. What I'm waiting for, though, is for a big player to do a modern, clean "Ku…

>> Whoever wants to compete in this space have to compete not just with GKE, but with the technical awesomeness of GCP. After years of using all the major clouds - Google Cloud has the best performance and primitives, but the worst support and operational/business features. If you want the fastest VMs/storage/networking, and are fine with non-standard APIs and beta SDKs, then it's a great platform and has super simpl…

It's probably AWS Fargate, part of the Elastic Container Service. But even then, it's still now a vendor lockin of the past, if you got your services deployable via containers you're 90% there to running your own Kubes cluster to launch them.

Re: As Kubernetes grows, a startup ecosystem develops in its wake

#107

Earlier quoted context omitted.

Maybe. I'm skeptical of Red Hat. The openshift.com web site, which is definitely not geared toward engineers, doesn't give me any confidence that this is what I'm after. Not that Google is better here, but I already know what GCP provides; something that wants to compete with GCP/GKE really needs to explain why they're a viable competitor. (And to people who design these things: If you need to have a "Products" dropd…

I work for Pivotal, we directly compete with Red Hat. Look: they're Red Hat , I mean c'mon now. If you don't think they have great engineers then I'd hate to hear what you think of the rest of us. These websites are not usually intended for you or I. They're intended to get the interest of the cheque-signers. Enterprise software is a very particular world and it has its particular cadences and norms and approaches. R…

Hence my skepticism. Someone who doesn't know how to engage with engineers is someone I don't have any interest in engaging with, either.

Re: As Kubernetes grows, a startup ecosystem develops in its wake

#108

Earlier quoted context omitted.

Kubernetes came out of the engineering team at Google. It was created by engineers for engineers. The fact that it's being exploited by enterprise consulting types doesn't change that premise.

>Kubernetes came out of the engineering team at Google. Attaching the Google name to projects stopped having meaning ~5 years ago. Their hiring process optimizes for fresh graduates who know nothing about engineering. Something coming out of Google means nothing, especially when Google itself doesn't even use it! >It was created by engineers for engineers. So was openstack. Then the feature creep happened.

Google does use GCP/GKE internally. And Google's internal Kubernetes team is basically the GCP team, according to googlers on HN.

Re: As Kubernetes grows, a startup ecosystem develops in its wake

#109
post #106

Earlier quoted context omitted.

>> Whoever wants to compete in this space have to compete not just with GKE, but with the technical awesomeness of GCP. After years of using all the major clouds - Google Cloud has the best performance and primitives, but the worst support and operational/business features. If you want the fastest VMs/storage/networking, and are fine with non-standard APIs and beta SDKs, then it's a great platform and has super simpl…

It's probably AWS Fargate, part of the Elastic Container Service. But even then, it's still now a vendor lockin of the past, if you got your services deployable via containers you're 90% there to running your own Kubes cluster to launch them.

I think you're replying to the wrong comment...

Re: As Kubernetes grows, a startup ecosystem develops in its wake

#110
post #60

Does anyone knows a very good CD for k8s? I found that only bitbucket deployments is a good one in terms of simplicity of managing deployments (just like Heroku). Most vendors forces me to use their crappy CI solution for doing CD. Why they want me to migrate to your (very limited) build system? I can pay you for a fancy dashboard, but please, allow me to use whatever i need to build my software. There are many optio…

We used Drone [1] from a while. It's almost exactly what I want in a CI/CD system, and it runs pretty well on Kubernetes.

On the minus side, the development has been slow, with major breaking changes happening along the way. And in the latest version, the open-source version has been a bit hobbled. In particular, it doesn't support global secrets, so every project to be built has to be created and managed separately. This is not just if it needs build secrets (such as to access private Go packages, NPM modules, Ruby gems, etc.), but it's obviously also required to authenticate with a container registry. We decided to skip that since it means duplicating the same secrets for every single application. We actually reached out to the Drone guys to ask about enterprise pricing, but they didn't respond (!).

(At the moment we're back to building with Semaphore, which is a hosted solution similar to Travis. It's an old-hat CI system that spins up VMs, so it's slow and awkward to work with when it comes to Docker. But it's working okay at the moment.)

I've heard good things about GoCD [2], though. It's next on my list to investigate.

[1] https://drone.io

[2] https://www.gocd.org

Post reply on HN