Don’t use Kubernetes or Microservices. Solves most problems. Not even being sarcastic.
In your opinion what's wrong with Kubernetes or microservices?
Ask HN: What are some architectural decisions that improved your codebase?
31–40 of 78 posts
Re: Ask HN: What are some architectural decisions that improved your codebase?
#32Re: Ask HN: What are some architectural decisions that improved your codebase?
#33Eliminate “broken windows” https://en.m.wikipedia.org/wiki/Broken_windows_theory
Re: Ask HN: What are some architectural decisions that improved your codebase?
#34Re: Ask HN: What are some architectural decisions that improved your codebase?
#35Eliminate threads, queues, locks, buffer allocate & free, copying, system calls, synchronous logging, file ops, dynamic memory allocation. Replace with huge-page mapped ring buffers, independent processes, kernel-bypass set-and-forget, buffer lap checks, file-mapped self-describing binary-formatted stats, direct-mode disk block writes, caller-provided memory.
>Replace with huge-page mapped ring buffers, independent processes, kernel-bypass set-and-forget, buffer lap checks, file-mapped self-describing binary-formatted stats, direct-mode disk block writes, caller-provided memory
Please elaborate.
Re: Ask HN: What are some architectural decisions that improved your codebase?
#36Inversion of control (pass in your dependencies), keep your architecture orthogonal (make it composeable and really think if you need to inherit things rather than delegate them), code-generation of a transport api via gRPC and only focus on the business logic implementation.
Re: Ask HN: What are some architectural decisions that improved your codebase?
#37One controversial opinion: monorep which is ideal for small teams iterating really fast. The other one was figuring out 12 factor app by serendipity as we were focussing on keeping our operations simple.
Re: Ask HN: What are some architectural decisions that improved your codebase?
#38Earlier quoted context omitted.
In your opinion what's wrong with Kubernetes or microservices?
Not the OP, but I'd say use only Kubernetes if you have the time to dedicate for the team to learn that technology and it's mental model.
Re: Ask HN: What are some architectural decisions that improved your codebase?
#39Eliminate “broken windows” https://en.m.wikipedia.org/wiki/Broken_windows_theory
What, were people swearing in the comments and putting Easter Eggs in the releases?
Re: Ask HN: What are some architectural decisions that improved your codebase?
#40Earlier quoted context omitted.
A much easier way than this is to append a hash of the file instead of 'versioning' it. Some people add it as a query string, some add it into the filename. Been doing this for years with infinite (well, practically) cache settings. These days it's built into most js compression tools afaik.
That doesn't work, because no one file exists in isolation. If you're using version 32.14 of this, you want version 32.14 of that, and this other thing. Versioned directories make this kind of grouping natural and easy, co-mingled hashes do not (and you could do both but you have the downsides of both and no real upsides). Plus semantic versioning can help cross-team communication, there's no human understanding of r…
So as long as your entrypoint and it's references are versioning, everything follows from that. So if I load version A of index.html, it also points to version A of the scripts/styles. If you load version B, you get version B of the scripts/styles, since everything is versioned the same way.