Hacker News

Top stories

Live mirror
30 storiesupdated just nowView source snapshot
  1. Hacking OpenAI(hacktron.ai ↗)
    68comments
  2. Waymo in Singapore(waymo.com ↗)
    53comments
  3. Astra for Law(openai.com ↗)
    458comments
  4. Bonsai 2 27B: Near-Lossless Compression in a 9x Smaller Footprint(prismml.com ↗)
    114comments
  5. Jemalloc 5.4.0(github.com/jemalloc ↗)
    5comments
  6. The scourge of x86 emulation(fex-emu.com ↗)
    1comments
  7. Bend – A language that blocks AI mistakes via proof, on CPU and GPU(bend-lang.com ↗)
    194comments
  8. Pre-Greek: The lost language hidden within Ancient Greek(linguisticdiscovery.com ↗)
    10comments
  9. Hister: A private search engine for the pages you visit and the files you keep(github.com/asciimoo ↗)
    146comments
  10. Qwen 3.8 Omni Flash(qwen.ai ↗)
    39comments
  11. Wax motor(wikipedia.org ↗)
    62comments
  12. Fujitsu launches made-in-Japan next-generation CPU FUJITSU-MONAKA(global.fujitsu ↗)
    209comments
  13. Apple detectives solved mystery of ancient tree and rewrote the history of fruit(scientificamerican.com ↗)
    3comments
  14. Shapelearn Qwen 3.8 27B (13.1 GB VRAM)(byteshape.com ↗)
    4comments
  15. Telstra outage: The night a network decided the year was 2006(netnod.se ↗)
    13comments
  16. How to Write with an LLM(sockpuppet.org ↗)
    69comments
  17. Flet 1.0 – Build cross-platform apps in Python(flet.dev ↗)
    42comments
  18. Sex, AI, and the Apocalypse(iankduncan.com ↗)
    187comments
  19. Ask A Monk – A digital wilderness for thoughts with no immediate answer(askamonk.online ↗)
    16comments
  20. Diplodocus, Long Thought Exclusively American, Turns Up in Spain(sci.news ↗)
    32comments
  21. Khipu (Quipu) Field Guide(khipufieldguide.com ↗)
    1comments
  22. The most important product decision is what you don't build(liamnugent.me ↗)
    27comments
  23. How Uber Protects Against Retry Storms(uber.com ↗)
    33comments
  24. Why I didn’t sign the Fields medallists’ letter(gowers.wordpress.com ↗)
    339comments
  25. CrowdSec Source Code Leak(crowdsec.net ↗)
    43comments
  26. How do we prevent mathemathics from devolving into the Medieval Era of secrecy?(mathoverflow.net ↗)
    84comments
  27. Code Scans(devin.ai ↗)
    4comments
  28. Infinite-Parameter LLMs: Generating and Adapting Weights from Live Data(arxiv.org ↗)
    38comments
  29. The American Religion of Self-Storage Facilities(newyorker.com ↗)
    368comments
  30. Speeding up gearhash on ARM64(sam.dev ↗)
    discuss

Ask HN: Why DevOps is still complicated in 2021?

12 pointsby 5y ago
13 comments
Please point to my dark spot, because I really want to understand something.

Aren't like ~90% of all web infra deployment usecases eventually come down to just "run N instances of my M apps on these L nodes, and make X of them available for incoming traffic (+ optionally create me few overlay networks inside cluster)"?

With lower level details resolved on per container/app level.

Why then k8s and all those tools make even simplest cases look so complicated?

Why then tools following "simplify things" ideology (like Swarm) are barely surviving in the shadow of monsters like k8s and alike?

Why aren't there widely popular tools that compete for simplicity with heroku?

Do I miss some big point somewhere or people just really love to play with complicated solutions of "not so complicated" problems?

5y agoHN ↗

I wouldn't say Swarm is much easier. You have to caveat 'easier' too. K8s is easier to do complicated things that were basically impossible before. It's the same with everything in software engineering. As we move up the ladder in abstractions, what's possible becomes more complicated, so it doesn't get any easier.

Graphics are good example. As people developed abstractions the ability to make more and more complicated graphics became possible. Now A+ games are more expensive and take longer to make then ever before, but they are also doing things that could of never happened before.

Our company is trying to make K8s much simpler to get into for the avg company, so another abstraction, but specifically done to make it simpler. This all feels very normal to me as someone that started back in the day managing 1000s of blade servers, now it's just containers. Was hard then and is hard now.

5y agoHN ↗

But now you can just run app in your desktop with one click, you dont have to build appstore app from sources right?

Im talking about dumb task of running software, not developing new software where I totally agree with your point.

5y agoHN ↗

What would you feel a simple solution be? Maybe you know something that others don't... or maybe it is just really hard to have a standard across millions of different ways of deploying and running software systems.

5y agoHN ↗

Heroku is a perfect example of simplicity in this area (devx/ux wise, putting aside proprietariness).

Why is it so hard to cover 90% of same ubuntus running same docker containers, communicating over same standard protocols?

5y agoHN ↗

I really like Heroku too and I think it does solve the problem particularly well for simple web apps. The world of devops isn't entirely simple web apps. Nor does it necessarily run (or can run) in the cloud.

There's an OSS heroku implementation, dokku I think? If it solves the problem well for what you need then you could just embrace it!

The challenge in some of the companies I've been is that the code base is 20~40 years old, there's a mix of languages, patterns, approaches and OSes generating value to the business.

Standardizing that across 100s of developers across 10s of departments isn't an easy task. Refactoring the deployment/code to whatever was the best practice of the last year isn't a good use of time either. People who wrote some of it left, there's no resources, etc.

The world of startups is quite straight forward, the world of enterprise software or companies that have a decent number of developers and have been around for a while, not so much...

5y agoHN ↗

Isnt all this legacy burden solved on container level?

Once you got a container - how complicated should it be to just run it?

5y agoHN ↗

It’s funny that your questions all imply that this should be a „solved“ problem while you can’t even grasp the complexity of reliably serving arbitrary software applications to arbitrary consumers. All that „legacy burden“ isn’t so legacy and for every layer of abstraction that makes all of this look less complicated, many highly skilled people put in a lot of effort.

5y agoHN ↗

Sure this thing can't be solved 100%, just as a problem of running consumer software.

But still we have good enough desktop apps, that even a kid can setup and run.

Nobody yet clarified what's the fundamental difference between those and apps running in the cloud.

many highly skilled people put in a lot of effort

Without good "product" guys supervision they tend to get systems only other highly skilled people can comprehend, btw.

5y agoHN ↗

Doing one thing once is easy.

Do it ten times. That’s harder.

Do it ten times each for ten people at once. That’s a lot harder.

Do it ten times each for ten people each across ten different cities in ten different states in ten different countries. That’s much, much harder.

It’s the “Wheat and Chessboard” problem all over again (see https://en.wikipedia.org/wiki/Wheat_and_chessboard_problem ).

The fundamental problem here is one of scale.

5y agoHN ↗

It's because it's a complicated problem, and kubernetes is not good to simplify it.

5y agoHN ↗

There's generally always a trade off between customisability vs simplicity, and time efficiency vs price. If it was possible for something to be customisable, simple, time efficient and cheap with no vendor lock-in, everyone would be using it.

Heroku is great for example because it's simple and saves time, but it can be expensive, there's areas you cannot customise, and their hosting tools aren't open source.

5y agoHN ↗

It looks like it, unfortunately. Like a hidden unemployment thing )