Live data from Hacker News

I am building a cloud

crawshaw.io

531–540 of 589 posts

Re: I am building a cloud

#531
post #339

Earlier quoted context omitted.

If you spin up Kubernetes for "a couple of containers to run your web app", I think you're doing something wrong in the first place, also coupled with your comment about adding SDN to Kubernetes. People use Kubernetes for way too small things, and it sounds like you don't have the scale for actually running Kubernetes.

Doing Kubernetes like doing Agile is mandatory nowadays. I've been asked to package a 20 line worth of bash script as docker image so it can be delivered via CI/CD pipeline via Kubernetes pods in cloud. Value is not that I got job done at a day's notice. It is black mark that I couldn't package it as per industry best practices. Not doing would mean out of job/work. Whether it is happening correctly is not something…

In my 20+ years in the industry, I've been at one company which really did Agile, and that was the one I started with.

Everyone else is communicating they are doing Agile while being very far away from it ;)

Re: I am building a cloud

#532
post #339

Earlier quoted context omitted.

Doing Kubernetes like doing Agile is mandatory nowadays. I've been asked to package a 20 line worth of bash script as docker image so it can be delivered via CI/CD pipeline via Kubernetes pods in cloud. Value is not that I got job done at a day's notice. It is black mark that I couldn't package it as per industry best practices. Not doing would mean out of job/work. Whether it is happening correctly is not something…

In my 20+ years in the industry, I've been at one company which really did Agile, and that was the one I started with. Everyone else is communicating they are doing Agile while being very far away from it ;)

if anyone knew what agile is maybe more would have a chance if making it work (it won’t). in my 30* the only “process” that worked and works is “hire the right people and get the F out of the way.”

Re: I am building a cloud

#533
post #465
post #445

Earlier quoted context omitted.

Running a Kubernetes deployment requires running many additional orchestration services that bare-metal deployments (whether running on-prem or in the cloud) do not.

"bare metal" "cloud" - pick one. Also, those simpler deployments usually burn more money per utilized compute, or involve reinventing 80% of kids, often badly

Many cloud providers offer bare-metal servers: https://en.wikipedia.org/wiki/Bare-metal_server#Bare-metal_c...

Re: I am building a cloud

#534

Earlier quoted context omitted.

I thought we collectively learned this with stack overflows engineering blog years ago. Scale vertically until you can't because you're unlikely to hit a limit and if you do you'll have enough money to pay someone else to solve it. Docker is amazing development tooling but it makes for horrible production infrastructure.

Docker is great development tooling (still some rough edges, of course). Docker Compose is good for running things on a single server as well. Docker Swarm and Hashicorp Nomad are good for multi-server setups. Kubernetes is... enterprise and I guess there's a scale where it makes sense. K3s and similar sort of fill the gap, but I guess it's a matter of what you know and prefer at that point. Throw on Portainer on a s…

> Docker is great development tooling (still some rough edges, of course).

Show me a Docker in use where build caching was solved optimally for development builds (like eg. make did for C 40 or 50 years ago)?

Perhaps you consider Docker layers one of the "rough edges", but I believe instant, iterative development builds are a minimum required for "great development tooling".

I did have great fun optimizing Docker build times, but more in the "it's a great engineering challenge to make this shitty thing build fast" sense.

Re: I am building a cloud

#535
post #339

Earlier quoted context omitted.

If you spin up Kubernetes for "a couple of containers to run your web app", I think you're doing something wrong in the first place, also coupled with your comment about adding SDN to Kubernetes. People use Kubernetes for way too small things, and it sounds like you don't have the scale for actually running Kubernetes.

Doing Kubernetes like doing Agile is mandatory nowadays. I've been asked to package a 20 line worth of bash script as docker image so it can be delivered via CI/CD pipeline via Kubernetes pods in cloud. Value is not that I got job done at a day's notice. It is black mark that I couldn't package it as per industry best practices. Not doing would mean out of job/work. Whether it is happening correctly is not something…

It depends on your situation of course, but there are a lot of good reasons to package up that bash script and run it through the pipeline. If everyone does some backdoor deployment of their snowflake shell script that's not great. It doesn't matter if it's 20 lines or 2 lines.

Re: I am building a cloud

#536
post #171

Earlier quoted context omitted.

Except that list originally had one item, and that item was Visicalc. Times change, but that list is going to stop being relevant before Excel gets knocked off the list. If you're doing anything complicated, Excel just doesn't make sense anymore. it'll still the be data exchange format (at least, something more advanced than csv), but it's no longer the only frontend. "No one uses" is no longer the insult it once was…

> "No one uses" is no longer the insult it once was. It certainly is for lots of businesses, otherwise they go out of business . There is something called 'revenue' which they need to make from customers which are their 'users', and that revenue pays for the 'operating costs' which includes payroll, office rent, infrastructure etc. This just means that it is important than ever to know what to build just as how it is…

Oh is that how it works? This "user" concept. Is that like a "customer"? Do they enjoy being talked down to? Are they excited to give money to people who treat them like that? I suspect you're not as good as you think you are at this business thing.

Re: I am building a cloud

#538

Earlier quoted context omitted.

> I'd argue the k8s APIs and interfaces are better than trying to do this on AWS I think Amazon ECS is within striking distance, at least. It does less than K8S, but if it fits your needs, I find it an easier deployment target than K8S. There's just a lot less going on.

I ran renderapp in ECS before I ran it in k8s. The deployment files / structure were mostly equivalent with the main differences being I can't shell into ECS and I lose kubectl in favour of looking at the AWS GUI ( which for me is a loss, for others maybe not ). The main difference is k8s has a lot of optionality, and folks get analysis paralysis with all the potential there. You quickly hit this in k8s when you have…

> I can't shell into ECS

Is there a specific reason why you can't shell into ECS? IIRC, I was able to do so by following the guide [0].

[0] https://aws.amazon.com/blogs/containers/new-using-amazon-ecs...

Re: I am building a cloud

#539

Earlier quoted context omitted.

I ran renderapp in ECS before I ran it in k8s. The deployment files / structure were mostly equivalent with the main differences being I can't shell into ECS and I lose kubectl in favour of looking at the AWS GUI ( which for me is a loss, for others maybe not ). The main difference is k8s has a lot of optionality, and folks get analysis paralysis with all the potential there. You quickly hit this in k8s when you have…

> I can't shell into ECS Is there a specific reason why you can't shell into ECS? IIRC, I was able to do so by following the guide [0]. [0] https://aws.amazon.com/blogs/containers/new-using-amazon-ecs...

if you use Kubernetes, shelling into an instance from k9s cli is pressing "s" with the instance highlighted in the TUI. it's great. haven't found a shrink-wrapped tool like that for ECS thats as good/easy as k9s for Kubernetes.

Re: I am building a cloud

#540

From the linked blog post: > The standard price for a GB of egress from a cloud provider is 10x what you pay racking a server in a normal data center. From the exe.dev pricing page: > additional data transfer $0.07/GB/month So at least on the network price promise they don't seem to deliver, still costs an arm and a leg like your neighbourhood hyperscaler. Overall service looks interesting, I like simplicity with con…

If it was anyone else, I'd have totally lost trust after seeing such a cynically diabolical take. I do eventually expect the co-founders at exe.dev, David & Josh, to workout someway to meet the promises laid out in TFA.
Post reply on HN