HN Explorer

Ask HN: What are the gaps in current infrastructure software?

30 points by what_to_build ↗ HN
There's a lot of open infrastructure software out there, but it wasn't until recently that some problems got decent solutions (like prometheus for monitoring, kubernetes for orchestration, minio for object storage). What problems could do with fresh implementations? What's some internal software you wish had an open implementation?

If you had three months to work solidly on a new piece of open source infrastructure level software, where would you place your effort?

Use this thread to generally complain about infrastructure.

18 comments

[ 4.1 ms ] story [ 49.3 ms ] thread
toomuchtodo
Datadog/New Relic competitor (app telemetry), maybe built on top of ELK/Graylog and Grafana.

Something to wrap around PostgreSQL to replicate RDS on your own infra (monitoring, provisioning, snapshots and transaction log shipping to various object stores).

benologist
The "boilerplate" needed to launch a web application, to make anything people need to sign in to you have to add a bunch of functionality that we see many services get wrong and do poorly, and it just gets worse as you add complex functionality like subscriptions. It's a lot of work and a lot of margin for error rewriting this stuff again and again.

I already started but I would spend 3 more months on this problem, trying to separate the boring stuff into something reusable and better than rewriting: https://userdashboard.github.io/home

jamieweb
Proper version-controlled DNS that is usable by non-developers.

Existing solutions like DnsControl and OctoDNS are great for development/devops teams who are familiar with Git, CI/CD, editing files in-line with a specific syntax and creating a merge request.

However, these can often be foreign concepts to general sysadmins or Windows technicians.

What'd be great would be to have a nice web frontend that implements version control with Git, and uses DnsControl or OctoDNS as the DNS-editing backend, but completely abstracts this complexity away from the users.

A comparable problem would be that non-developers may find Git on the command-line challenging, but the GitHub/GitLab web GUIs make it easy. I want to be able to say: Non-developers find DnsControl and OctoDNS challenging, but [x open-source solution that doesn't exist yet] makes it easy.

otterley
Can you elaborate on the business case here? Why would a business want to make it easier for non-developers to implement infrastructure as code, when they can give the task to the developers they already have, or hire more developers who will also be able to do other things that add business value?
jamieweb
This is for organisations that either do not have skilled developers, or for organisations where the development team doesn't look after core infrastructure.

The target audience for this is traditional sysadmin roles and Windows technicians - in other words, people who are not used to non-GUI stuff.

fillskills
DevSecOps automation/management system - Way to instrument, monitor, manage and visualize DevSecOps
didip
Real multi cloud. I want to be able to spread my app all over the 3 public cloud infrastructure.
BjoernKW
Usability. Just recently I went down a particularly deep rabbit hole when I tried to run Angular unit tests with a headless Chromium browser on a Jenkins CI server.

Suddenly I found myself having to debug various Docker images, Jenkins files and Kubernetes pods.

Not only are these tools often used indiscriminately, regardless of whether they're actually needed for the use case at hand but there frequently also seems to be an apparent disregard for the non-functional requirements of the people using them.

Sure, I can launch "kubectl" or "docker exec -it" to see what's going on but as someone who merely wants to run unit tests I shouldn't have to.

javcasas
> Angular unit tests

Talking as experienced front-end developer, currently working in an angular project, I must indicate that there are no Angular unit tests in existence. A unit test that requires a full browser to run is not a unit test, but a full e2e test. Exactly the same as the endpoint tests that require opening a server and binding to a port.

BjoernKW
With Jasmine tests running with "ng test" (i.e. with Karma test runner rather than Protractor) the system-under-test usually is a single component, directive or service.

Therefore, conceptually these indeed are unit tests.

You could argue that because a browser environment is required for running these units the tests are integration tests.

Still, they're commonly referred to as unit tests (including the official Angular documentation).

kodebrew
Yep usability. Some sort of common patterns for all of these tools.
dlahoda
my yamls have hackful types system, dynamic type systems, and no OR(type x = a of string| b of int) types, lack of language definitions (BNF).
dlahoda
and it is not clear at all how updates are merged on cluster and which will definately fail, not proper math applied
kodebrew
I've found deploying to all these new infrastructure tools is a big gap. I've been open sourcing a tool https://deliverybot.dev that I built internally at my current org.
ux4
Breaking down monolithic databases into microservices.

Containerism and modern devops practices become borderline impossible when you're working with a monolithic database that's encumbered in complex business processes. Ideally you're working with independent, decoupled microservices, but that's far from the reality that most admins face.