News for hackers. Stuff that matters.
Re:Google admits Kubernetes container tech is too complex by aroman on Friday February 26, 2021 @01:21AM (#26271849)
Mind blowing to me that "Heroku but with docker images" doesn't seem to exist. Would love to be corrected!
Re:Google admits Kubernetes container tech is too complex by mateuszf on Friday February 26, 2021 @01:46AM (#26271979)
Heroku does allow building / deploying Docker images - https://devcenter.heroku.com/categories/deploying-with-docke...
Re:Google admits Kubernetes container tech is too complex by vyrotek on Friday February 26, 2021 @01:53AM (#26272012)
Azure AppService has some pretty good support for that.

https://azure.microsoft.com/en-us/services/app-service/conta...

Re:Google admits Kubernetes container tech is too complex by Clewza313 on Friday February 26, 2021 @01:23AM (#26271866)
That's pretty much Cloud Run, no?

https://cloud.google.com/run/

Re:Google admits Kubernetes container tech is too complex by monsieurbanana on Friday February 26, 2021 @01:34AM (#26271925)
I'm looking for something like that, but I'm afraid of using any google developer services, such as GCP, for personal projects. What if I breach their TOS somehow and get banned, or what if I didn't breach their TOS and still get banned?

Can't afford to test my luck until I've finished migrating all my accounts off my gmail.

Re:Google admits Kubernetes container tech is too complex by dontblink on Friday February 26, 2021 @01:41AM (#26271964)
Why don't you just create a new Google Account specifically for this?
Re:Google admits Kubernetes container tech is too complex by wsgeorge on Friday February 26, 2021 @02:24AM (#26272177)
Associated account bans are a thing in the Android world. I don't know if this extends to other Google platforms.
Re:Google admits Kubernetes container tech is too complex by monsieurbanana on Monday March 01, 2021 @11:52PM (#26312013)
I'd also need a new credit card, I'm pretty sure they link accounts via shared CC. And even then, I'm pretty sure they still link accounts via other means. Did I link my gcp email in my android gmail app? Did I use the same IP address for both accounts? Or any of the thousand ways google has to know two accounts belong to the same person.

Honestly, creating a second google account might itself increase the chances of getting banned. Nobody knows with Google, and that's the problem.

Re:Google admits Kubernetes container tech is too complex by mkl on Friday February 26, 2021 @03:24AM (#26272520)
Doesn't that require another active SIM card?
Re:Google admits Kubernetes container tech is too complex by ZephyrBlu on Friday February 26, 2021 @02:27AM (#26272191)
I'm using my main google account on GCP and just yesterday started to take precautions about this.

I created a new google account with no relation to my main one and added it as an owner to my GCP project, so hopefully in the event of either account being banned I can still access everything.

Re:Google admits Kubernetes container tech is too complex by AbhyudayaSharma on Friday February 26, 2021 @01:54AM (#26272022)
Cloud run is great. I'm using an Nginx image to serve my static website. However, if I remember correctly, you can only respond to HTTP(S). So though it may be enough for most usecases, it is not essentially equal to running any container on the cloud.
Re:Google admits Kubernetes container tech is too complex by jillesvangurp on Friday February 26, 2021 @03:36AM (#26272601)
Websockets now work on cloud run. We implemented that last month. Cloud run does have a few limitations: no service discovery built in, no docker compose support, limited set options for CPU/memory, no persistent disk, etc. But it's great for things like a simple Spring Boot server or any kind of stateless service. But you won't be running redis or a database there. It's just not designed to do that. It's also not great for running batch jobs; we tried and our jobs kept getting killed/throttled. Use a vm for that.

Luckily, there are lots of other Google services for that that you can plugin for that sort of stuff. Cloudrun is great if you are planning to use those things.

Kubernetes is what you use when you want to mix stateful and stateless stuff so you can avoid depending on those services. That makes sense if you need to support multiple clouds or on premise installations. But otherwise, it's a lot of extra complexity and devops even before you consider the overhead of managing the kubernetes cluster. There are lots of companies that talk themselves into needing this where the need is arguably a bit aspirational. I've been on more than one expensive project where we served absolutely no traffic at all with hundreds of dollars worth of kubernetes clusters idling for months on end that had no realistic hopes of ever getting more than a very modest amount of traffic even if everything worked out as they planned.

Re:Google admits Kubernetes container tech is too complex by je42 on Friday February 26, 2021 @05:48AM (#26273455)
websocket support: awesome ! have been waiting for that ! :)
Re:Google admits Kubernetes container tech is too complex by Clewza313 on Friday February 26, 2021 @02:20AM (#26272157)
gRPC and WebSockets are in preview. Doesn't look like you can use arbitrary ports though.

https://cloud.google.com/run/docs/triggering/grpc

Re:Google admits Kubernetes container tech is too complex by jillesvangurp on Friday February 26, 2021 @03:39AM (#26272628)
You can open just 1 https port but you can map whatever port in your docker container to that. Some websocket implementations work with a second port and that just doesn't work. But you should probably split those services into two. But if you use something that can mix websockets and normal https traffic over 1 port, it works great.
Re:Google admits Kubernetes container tech is too complex by aroman on Friday February 26, 2021 @12:25PM (#26277272)
For my usage (lightweight game servers), I need WebSockets, which are still in beta and they currently force WS connections to close after 1 hour, which is a dealbreaker for me.
Re:Google admits Kubernetes container tech is too complex by mfontani on Friday February 26, 2021 @01:50AM (#26272004)
Dokku is "it" for me, but I'm sure there are others. Works pretty well, but it's (to the best of my knowledge) for one node only.
Re:Google admits Kubernetes container tech is too complex by kkapelon on Friday February 26, 2021 @04:18AM (#26272857)
It is coming. Check https://www.qovery.com/ and https://www.hyscale.io/

(Not affiliated with either)

Re:Google admits Kubernetes container tech is too complex by TruffleMuffin on Friday February 26, 2021 @02:15AM (#26272117)
Think thats AWS Fargate, but admittedly i don't do a lot with Heroku.
Re:Google admits Kubernetes container tech is too complex by machiaweliczny on Friday February 26, 2021 @05:49AM (#26273461)
CloudFoundry has ability to host your own docker images easily AFAIK.

Edit: fixed name

Re:Google admits Kubernetes container tech is too complex by pgm8705 on Friday February 26, 2021 @09:39AM (#26275197)
Digital Ocean's App Platform can work this way.
Re:Google admits Kubernetes container tech is too complex by gobengo on Friday February 26, 2021 @01:34AM (#26271929)
Re:Google admits Kubernetes container tech is too complex by aroman on Friday February 26, 2021 @01:48AM (#26271993)
Dokku looks super cool but it's still a lot more involved than Heroku. Heroku doesn't make you think about provisioning servers, updating infrastructure, or manually setting up common integrations like backups and logging.

Just to illustrate the point, dokku's docs[0] for logging say "Warning: The default docker-local scheduler will "store" these until the next deploy or until the old containers are garbage collected - whichever runs first. If you require the logs beyond this point in time, please ship the logs to a centralized log server."

Alright, well, that's gonna be a whole lot more work than two click in Heroku to send all my logs to any logging provider of my choice.

[0] https://dokku.com/docs/deployment/logs/

Re:Google admits Kubernetes container tech is too complex by opsunit on Friday February 26, 2021 @03:55AM (#26272718)
render.com