Hacker News Reader

Comment by tootie | Hacker News Reader

The solution to this is just writing modular code and using an artifact repository. It's a model I've rarely seen attempted even though it's much easier than microservices and serves the same purpose.

You can have individual dev teams, with their own repo ,backlogs, own stakeholders, etc all working at their own paces. They build modules (jars, nuget packages, npm modules) and deploy semver versioned artifacts to a repo like Nexus or JFrog. Any frontend/consumer applications can build towards versions of those modules and upgrade on their own schedule. Only the consumers need to worry about deployment.

This gives you the organizational flexibility but not the infrastructure overhead.

The discriminating factor that makes microservices necessary if these individual services have divergent hardware needs.

View on HN

My favorite project to work on was a modular monolith. It was a single deployable but each component (vertical) had its own maven-module.

When developers complain about being verbose and not a great language for coders, I counter that it doesn't exist to solve programming problems, but rather organizational problems. The killer feature that launched Java wasn't crap like checked exceptions, it was javadoc. Strict, self-documenting APIs are 10X more valuable than any intrinsic language feature.

i dont care about it not being great. its good enough as a language. but maven... but websphere... java is a hellish platform that ordinarily would not win from interpreted languages or those which focus on fast compilation. But it runs literally everywhere, including your toaster, but more importantly on mainframes which also run the real mvp aka Cobol. run once, run anywhere remains a killer feature no other platform has replicated as well.

Good old websphere. Good old maven.

Yeah. Not my favorite things either. Luckily there are alternatives in the Java world.

Maven is great. Better than any competitor I've seen. WebSphere is long dead and was crappy even when it was new.

I think you are putting Java in the pillory today, for the worst aspects of its ecosystem a decade ago.

Outside of perhaps stodgy banks, technical folks are not choosing to run their JVM projects today on Websphere. Gradle is pretty darn nice.

It's what my employer uses, they dont really have much choice because they're running on IBM hardware.

How does that solve the deployment-rollback problem?

You can still deploy a new version of the monolith with a downgraded module.

Interesting. Ie, just the way the larger community (ie open source) ecosystem works, but just inside your company instead.

That makes an obvious kind of sense, when your number of contributors have grown too large to operate like a monolith... why not operate using models well-established for very large inter-entity communities?

I wonder why more very large companies don't do this, if they don't.

I work at a very large company where each team builds and deploys its own production artifacts, but we always build everything off of head rather than choosing versions of each dependency and upgrading on our own schedule. The choose-your-own-adventure approach seems like it might be nice until you write (e.g) a critical security patch and you have to go nag N teams to upgrade their version of your library. With our system it goes out in everyone's daily or weekly release.

The system only works because of very good integration testing infrastructure and a culture of being able to roll back almost any change that broke you.

Absolutely, "go nag N teams" is a huge problem in a microservices environment. It's mitigated somewhat by building all the services from a monorepo.

That makes sense.

If for some reason the more traditional versioned release dependency approach made more sense for other reasons (as the GP suggested they were using it) -- it shouldn't be too hard to write automated tooling to go tell everyone to upgrade for a security release, or even make PR's dependabot-style; if an org already has "very good integration testing infrastructure", adding that tooling for security updates of dependencies is perhaps within the capacities.

My previous company went this direction. I wouldn't recommend it.

Say you version each module and pull in specified versions. It'll work fine, right up until two modules both try to pull different versions of a third module. In practice, you have to update multiple modules at once to avoid conflicts, which, in turn, can require updating other team's code.

It also turns out some tools like Maven don't prevent conflicts by default. You can end up exploring pom.xml files in Eclipse, trying to add exclusions, or figure out which repo is dragging them in.

That's what semver is for, right? Breaking changes go in a major, same major means that the latest is always compatible. You'll have the same issue with microservices if you introduce breaking changes.

Yeah, but even with semver library owners have problems. If you need to make a critical change (e.g. a security update), you can either (a) wait until everyone does a version bump on their own schedule, or (b) do the version bump yourself, which means you're deploying every app that relies on your library. (a) might not be feasible for critical things, and (b) means that you might be deploying changes that the app isn't ready for yet.

For example, if master is v1.5.0, and I'm an app that uses v1.1.0, then if the library owner bumps to 1.5.1 for a critical update, I need to go from 1.1.0 -> 1.5.1, which might involve changes I'm not ready for yet. I better have phenomenal integration testing to make sure the update is safe to do.

> For example, if master is v1.5.0, and I'm an app that uses v1.1.0, then if the library owner bumps to 1.5.1 for a critical update, I need to go from 1.1.0 -> 1.5.1, which might involve changes I'm not ready for yet. I better have phenomenal integration testing to make sure the update is safe to do.

That could be solved by backporting security fixes to version 1.1.

Of course at a certain point you should deprecate older versions of your package. At which point it's the client's responsibility to upgrade (like for any third party library they would be using).

That would have let you know when to expect the impact, but not eliminate the impact itself.

Occasionally people versioned their module's APIs, which seemed like a cleaner way to handle the module update, as you don't have to update everything at once. They only went to that effort when they realized they'd have to update thousands of callers.

Yeah, it sure seems like Maven, by design, tries to avoid dependency locking and version resolution configuration, but in turn, becomes kind of a bear to manage once you get fairly large.

I've switched to Gradle, and one of the first things I do is usually flip on dependency locking, and then even go so far to reject and/or flag anything that doesn't have a clear semantic version scheme.

Gradle's documentation can be a little overwhelming, but there's a lot more to these topics that developers usually overlook:

https://docs.gradle.org/current/userguide/dependency_locking... https://docs.gradle.org/current/userguide/resolution_rules.h...

Many companies would benefit from real dependency locking, and making sure they have reproducible builds. It's tricky, but, it can be a lot easier than "containerization", which I've often heard touted as a solution. (Containers are useful, but you should fix your CI separately.)

Also the way I see containerization being implemented (just Dockerfile) instead of relying on deploying the same image essentially kills the reproducibility part.

My company does this in a sense. We build a (mostly) open-source eCommerce platform with almost 100 public repos and a lot more proprietary ones for larger retailers. It's not "microservices", but it's definitely a lot of packages to manage, and we have frequently had trouble keeping them all organized and in sync with the latest changes to the core platform. The core platform is designed internally with a modular, domain-driven architecture, and the applications made with the platforms are monoliths, but the features of the platform are distributed amongst a couple hundred RubyGems. It's a lot to keep track of, but it's still a great compromise between a modular, plug-and-play architecture, and a monolithic application with all those features installed at once (which would be really hard to maintain). We're looking for ways to reduce our workload in that sense, because our team is rather small (about 6 people) and as I was saying, it's a little difficult to manage all those repos. So we've been thinking about keeping the modular architecture but keeping everything in a monorepo, so it's easier to release new versions and figure out what's changed (or what needs to change).

Yep, that approach works best. I think microservices can still be introduced for things that are quite separate and don't require internal communication (the biggest thing that people underestimate when going with micro services is that communication between services is not an easy problem) between components. Although not every business will have such situations.

Try again with a lower dependency version is not that different from try again with the offending commit reverted.

Yes it is, because service A can depend on service B v2.3.4, while service C, at the same time, depends on service B v2.1.7.

Reply on news.ycombinator.com