Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What the hell have you built

wthhyb.sacha.house

Post reply on HN
Print view View original

181–190 of 239 posts

Re: What the hell have you built

#181

Post by pjmlp »

torben-friis wrote: post #164
benterix wrote: post #154

Earlier quoted context omitted.

With time, I discovered something interesting: for us, techies, using container orchestration is about reliability, zero-downtime deployments, limiting blast radius etc. But for management, it's completely different. It's all about managing complexity on an organizational level. It's so much easier to think in terms "Team 1 is in charge of microservice A". And I know from experience that it works decently enough, at…

It’s not a management thing. I’m an engineer and I think it’s THE main advantage micro services actually provide: they split your code hard and allow a team to actually get ownership of the domain. No crossing domain boundaries, no in between shared code, etc. I know: it’s ridiculous to have an architectural barrier for an organizational reason, and the cost of a bad slice multiplies. I still think in some situations…

Libraries do exist, unfortunely too many developers apparently never learn about code modularity.

Re: What the hell have you built

#182

Post by noir_lord »

whilenot-dev wrote: post #120
omnicognate wrote: post #93

Earlier quoted context omitted.

Conway's Law: > Organizations which design systems... are constrained to produce designs which are copies of the communication structures of these organizations.

Tell this to a company of 4 engineers that created a system with 40 microservices, deployed as one VM image, to be running on 1 machine.

They wouldn't have time to hear it because they'd be trying to fix their local dev environment.

I worked for a company that had done pretty much that - not fun at all (for extra fun half the microservices where in a language only half the dev team had even passing familiarity with).

You need someone in charge with "taste" enough to not allow that to happen or it can happen.

Re: What the hell have you built

#183

Post by torben-friis »

strken wrote: post #175
torben-friis wrote: post #164

Earlier quoted context omitted.

It’s not a management thing. I’m an engineer and I think it’s THE main advantage micro services actually provide: they split your code hard and allow a team to actually get ownership of the domain. No crossing domain boundaries, no in between shared code, etc. I know: it’s ridiculous to have an architectural barrier for an organizational reason, and the cost of a bad slice multiplies. I still think in some situations…

I don't see why it's ridiculous to have an architectural barrier for org reasons. Requiring every component to be behind a network call seems like overkill in nearly all cases, but encapsulating complexity into a library where domain experts can maintain it is how most software gets built. You've got to lock those demons away where they can't affect the rest of the users.

>Requiring every component to be behind a network call seems like overkill in nearly all cases

That’s what I was referring to, sorry for the inaccurate adjective.

Most people try to split a monolith in domains, move code as libraries, or stuff like that - but IMO you rarely avoid a shared space importing the subdomains, with blurry/leaky boundaries, and with ownership falling between the cracks.

Micro services predispose better to avoid that shared space, as there is less expectation of an orchestrating common space. But as you say the cost is ridiculous.

I think there’s an unfilled space for an architectural design that somehow enforces boundaries and avoids common spaces as strongly as microservices do, without the physical separation.

Re: What the hell have you built

#184

Post by pjmlp »

vbezhenar wrote: post #176
strken wrote: post #175

Earlier quoted context omitted.

I don't see why it's ridiculous to have an architectural barrier for org reasons. Requiring every component to be behind a network call seems like overkill in nearly all cases, but encapsulating complexity into a library where domain experts can maintain it is how most software gets built. You've got to lock those demons away where they can't affect the rest of the users.

The problem is, that library usually does not provide good enough boundaries. C library can just shit over your process memory. Java library can cause all the hell over your objects with reflection, can just call System.exit(LOL). Minimal boundary to keep demons at bay is process boundary and you need some way for processes to talk to each other. If you're separating components into processes, it's very natural to pu…

And then we're back to 1980's UNIX process model before wide adoption of dynamic loading, but because we need to be cool we call them microservices.

Re: What the hell have you built

#185

Post by isodev »

zelphirkalt wrote: post #171
isodev wrote: post #115

Earlier quoted context omitted.

I'm not sure why your architecture needs to be complex to support CI pipelines and proper workflow for change management. And some of these guidelines have grown into satus quo common recipes. Take your starting database for example, the guideline is always "sqlite only for testing, but for production you want Postgres" - it's misleading and absolutely unnecessary. These defaults have also become embedded into PaaS s…

Having recently built a Django app, I feel like I need to highlight the issues coming with using sqlite. Once you get into many to many relationships in your model, suddenly all kinds of things are not supported by sqlite, while they are when you use postgres. This also shows, that you actually cannot (!) use sqlite for testing, because it behaves significantly differently from postgres. So I think now: Unless you ha…

My comment is that this is a choice that should be made for each project depending on what you’re building - does your model require features not supported by SQLite or Postgres etc.

> Unless you have a really really simple model and app

And this is the wrong conclusion. I have a really really complex model that works just fine with SQlite. So it’s not about how complex the model is, it’s about what you need. In the same way in the original post there were so many storage types, no doubt because of such “common knowledge guidelines”

Re: What the hell have you built

#186

Post by noir_lord »

hinkley wrote: post #128
omnicognate wrote: post #93

Earlier quoted context omitted.

Conway's Law: > Organizations which design systems... are constrained to produce designs which are copies of the communication structures of these organizations.

Lesser known trick: reorganize your teams so the code isn’t batshit.

That does imply that the people in the business with the authority to do that know how to do that and they in my experience don't - they can't solve a problem they don't understand and are unwilling to delegate it to someone who can understand it.

The same pattern repeats across multiple companies - it comes down to trust and delegation, if the people with the power are unwilling to delegate bad things happen.

Re: What the hell have you built

#187

Post by pjmlp »

9dev wrote: post #145
macspoofing wrote: post #127

Earlier quoted context omitted.

>It's sure a corny stance to hold if you're navigating an infrastructure nightmare daily, but in my opinion, much of the complexity addresses not technical, but organisational issues: You want straightforward, self-contained deployments for one, instead of uploading files onto your single server ... You can get all that with a monolith server and a Postgres backend.

You don't. When your server crashes, your availability is zero. It might crash because of a myriad of reasons; at some times, you might need to update the kernel to patch a security issue for example, and are forced to take your app down yourself. If your business can afford irregular downtime, by all means, go for it. Otherwise, you'll need to take precautions, and that will invariably make the system more complex t…

Well, load balancers are an option.

Re: What the hell have you built

#188

Post by hshdhdhehd »

1718627440 wrote: post #27
hshdhdhehd wrote: post #18

Earlier quoted context omitted.

Postgres is simpler. Get your cloud to manage it. Click to create instance, get failover with zero setup. Click button 2 to get guaranteed backups and snapshot point in time.

When you use sqlite, you can distribute your program by distributing a single executable file. That's what I call simple.

Yes that is simple, especially for a desktop app.

I would argue it is not resilient enough for a web app.

No one wrote the rules in stone, but I assume server side you want the host to manage data recovery and availability. Client side it is the laptop owners problem. On a laptop, availability is almost entirely correlated with "has power source" and "works" and data recovery "made a backup somehow".

So I think we are both right?

Re: What the hell have you built

#189

Post by jwr »

r0x0r007 wrote: post #108
jwr wrote: post #98

While I agree with most of this rant, I have a problem with the common "just use postgres" trope, often repeated here. I recently had to work with SQL again after many years, and was appalled at the incidental complexity and ridiculous limitations. Who in this century would still voluntarily do in-band database commands mixed with user-supplied data? Also, the restrictions on column naming mean that you pretty much h…

"just use postgres" is an excellent advice. How about incidental complexity and ridiculous limitations of an ORM? Time spent learning how to use an ORM can better be spent 'refreshing' your SQL knowledge. Also, when you learn how an ORM works, you still don't know proper SQL nor how do databases works, so when you switch language now what, you quickly take a course on another ORM? SQL is a language, ORM is not,it's j…

It is rather clear that I am the only one in this discussion who recently had to write code that synchronizes data that I do not control with an SQL database. Everything is easy in toy applications, where you have your USERS table with First_Name and Last_Name.

Re: What the hell have you built

#190

Post by zelphirkalt »

isodev wrote: post #185
zelphirkalt wrote: post #171

Earlier quoted context omitted.

Having recently built a Django app, I feel like I need to highlight the issues coming with using sqlite. Once you get into many to many relationships in your model, suddenly all kinds of things are not supported by sqlite, while they are when you use postgres. This also shows, that you actually cannot (!) use sqlite for testing, because it behaves significantly differently from postgres. So I think now: Unless you ha…

My comment is that this is a choice that should be made for each project depending on what you’re building - does your model require features not supported by SQLite or Postgres etc. > Unless you have a really really simple model and app And this is the wrong conclusion. I have a really really complex model that works just fine with SQlite. So it’s not about how complex the model is, it’s about what you need. In the…

OK, well, you don't always know all requirements ahead of time. When I do find out about them later on, I don't want to have to switch database backend then. For example initially I thought I would avoid those many to many relationships all together ... But turned out to be the most fitting way to do what I needed to do in Django.

I guess you could say "use sqlite as long as it lends itself well to what you are doing", sure. But when do you switch? At the first inconvenience? Or do you wait a while, until N inconveniences have been put into the codebase? And not to forget, the organizational resistance to things like changing the database. People not in the know (mangement usually) might question your plan to switch the database, because this workaround for this small little inconvenience _right now_ seems much less work and less risky for production ... Before you know it, you will have 10 workarounds in there, and sunken cost fallacy.

I may be exaggerating a little bit, but it's not like this is a crazy to imagine picture I am painting here.

Post reply on HN