51–60 of 80 posts
We're moving away from Kubernetes because managing even a simple implementation is a full-time job. Obviously Kubernetes is meant for enterprises, but I've seen seed round/series A startups with a small engineering team using it. We were at a crossroad. Either we hire an SRE that has extensive kubernetes experience for $130K/year or we move to a managed platform until we actually need those capabilities. We're happy…
Earlier quoted context omitted.
> Kubernetes is meant for enterprises Actually it's meant for virtually no one, because very few people have the problems it solves. Like AutoScaling Groups, Serverless, and Cloud its self, it's a tool that solves a pain point in a specific domain. About 0.001% of the business world have that problem. > We're happy with the move and the pressure relief is tremendous. I'll bet it was. I've convinced businesses to go i…
The "Kubernetes is only for Google-scale companies" meme needs to die. Kubernetes is a useful tool even if you have a single node . As a case in point: I just set up a small new app on GKE. Because I'm experienced with Kubernetes, within a few minutes I had my app (a React front-end written in TypeScript and a backend written in Go) running and receiving HTTPS traffic. I entered just a handful of shell commands to ge…
Earlier quoted context omitted.
> The holy grail (for some companies) is really something like Azure AKS + Azure Container Instances. No instances to manage... Google Cloud have been having that since before it's being called Google Cloud -- I mean Google App Engine. It has all those features, and with its "Standard" environment you don't even need to build docker image.
Cloud Run is even closer. App Engine Standard requires you to use the sandbox, App Engine Flex is tied to VMs, but Cloud Run makes containers serverless: https://cloud.google.com/run/ ...and since it's based on Knative, it's portable-ish.
that owl looks pissed
Earlier quoted context omitted.
> Kubernetes is meant for enterprises Actually it's meant for virtually no one, because very few people have the problems it solves. Like AutoScaling Groups, Serverless, and Cloud its self, it's a tool that solves a pain point in a specific domain. About 0.001% of the business world have that problem. > We're happy with the move and the pressure relief is tremendous. I'll bet it was. I've convinced businesses to go i…
The "Kubernetes is only for Google-scale companies" meme needs to die. Kubernetes is a useful tool even if you have a single node . As a case in point: I just set up a small new app on GKE. Because I'm experienced with Kubernetes, within a few minutes I had my app (a React front-end written in TypeScript and a backend written in Go) running and receiving HTTPS traffic. I entered just a handful of shell commands to ge…
It just takes some experience. I mostly disable SSH for example. You bake your images once, not install everything on each boot.
I wish their tech writers would give us more English and less jargon. I pondered these release notes and the documentation earlier today and I still can't puzzle out why "custom resource" is initialized as "CRD". And the rest of this gibberish is just meaningless. """A resource is an endpoint in the Kubernetes API that stores a collection of API objects of a certain kind.""" OK, almost completely free of meaning ...…
Earlier quoted context omitted.
It's not gibberish, though. A resource has an endpoint, i.e. a URL that represents its configuration and state. But a resource and its endpoint can be thought of as the same thing, in that the endpoint is the resource's canonical URI. Think REST/HATEOAS. A resource is any object that Kubernetes can track. They include objects like services, pods, nodes, ingresses and so on. Together resources form an API. A CRD is a…
"But a resource and its endpoint can be thought of as the same thing, in that the endpoint is the resource's canonical URI." After reading your description, "a resource is an endpoint" still seems wrong. Perhaps just lazy, but laziness in technical docs gets confusing fast.
We're moving away from Kubernetes because managing even a simple implementation is a full-time job. Obviously Kubernetes is meant for enterprises, but I've seen seed round/series A startups with a small engineering team using it. We were at a crossroad. Either we hire an SRE that has extensive kubernetes experience for $130K/year or we move to a managed platform until we actually need those capabilities. We're happy…
In my experience, Kubernetes is a lot of work to install and maintain. However, I've found managed offerings—especially ones like Azure that actually abstract away the complexity (Amazon exposes all the nitty-gritty, in my experience)—make it easy to use for even smaller shops. Of course, not every workload benefits from the features k8s provides.
We're moving away from Kubernetes because managing even a simple implementation is a full-time job. Obviously Kubernetes is meant for enterprises, but I've seen seed round/series A startups with a small engineering team using it. We were at a crossroad. Either we hire an SRE that has extensive kubernetes experience for $130K/year or we move to a managed platform until we actually need those capabilities. We're happy…
We're moving away from Kubernetes because managing even a simple implementation is a full-time job. Obviously Kubernetes is meant for enterprises, but I've seen seed round/series A startups with a small engineering team using it. We were at a crossroad. Either we hire an SRE that has extensive kubernetes experience for $130K/year or we move to a managed platform until we actually need those capabilities. We're happy…
> Kubernetes is meant for enterprises Actually it's meant for virtually no one, because very few people have the problems it solves. Like AutoScaling Groups, Serverless, and Cloud its self, it's a tool that solves a pain point in a specific domain. About 0.001% of the business world have that problem. > We're happy with the move and the pressure relief is tremendous. I'll bet it was. I've convinced businesses to go i…