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

The costs of microservices (2020)

robertovitillo.com

Post reply on HN
Print view View original

391–400 of 410 posts

Re: The costs of microservices (2020)

#391

Post by buster »

sazz wrote: post #369
buster wrote: post #364

Earlier quoted context omitted.

There are many valid reasons (and many wrong reasons). I would say: If you have multiple stakeholders, evoling business needs and many ( > 10) developers, there might be a good reason to have independent deployable, testable and releaseable units. Having few developers with a well defined context working on multiple microservices is a pain, though. Regarding "Everything else is just shifting complexity from software…

"There might be a good reason to have independent deployable, testable and releaseable units" Of course this is the bottom line. But everything you define in the sentence can be achieved with a proper pipeline and repository architecture based on a monolith as well. For example teams could use a branch setup where they own their own team branches capable of merging to master and deploying. Each team could then define…

First, you offer technical solutions (pipelines, branching...).. The cost of having multiple teams branching and merging the same code base can be significant. It's often not as easy as you make it sound.

Re: The costs of microservices (2020)

#392

Post by Capricorn2481 »

manicennui wrote: post #196
Capricorn2481 wrote: post #150

Earlier quoted context omitted.

What are you replying to? The article is about how Dry shouldn't be over applied. Dry is literally "Don't Repeat Yourself" and is definitely pushed for cleaning up redundant code, so it's not unreasonable for people to think that's what about. It's only recently that people have pointed out that there's a difference between Duplicated code and Repeated code.

Redundant code is not code that looks the same. It's only reasonable for people to believe it is about code that looks the same if they have never bothered to learn what it means.

That's what I said, yes. There's a difference between duplicated logic and redundant code. And it's clear the Grug article agrees with that.

Re: The costs of microservices (2020)

#393

Post by lmm »

pjmlp wrote: post #371
lmm wrote: post #301

Earlier quoted context omitted.

> OSGi and Java Modules would like a word. OSGi is the one that's deprecated and Java Modules is the one that can't actually provide that functionality yet, right? Or is it the other way round? Either way you get the point.

Java modules are doing alright since Java 9, are the foundation for Java's linker and code stripping on AOT, while Eclipse keeps using OSGi just fine.

> Java modules are doing alright since Java 9

Can you actually use them to use two different versions of library C in the same application yet though?

> Eclipse keeps using OSGi just fine

Wasn't the impression I had the last time I tried to fix a bug in an eclipse plugin that touched on the OSGi parts. The codebase felt like a ghost town and I couldn't find any documentation for how it all worked or anyone who knew about it.

Re: The costs of microservices (2020)

#394

Post by davidalayachew »

slowmovintarget wrote: post #221
voxic11 wrote: post #76

Earlier quoted context omitted.

Because of dependency issues like he mentioned. If I am using Library A which depends on version 1 of Library C and I need to start using Library B which depends on version 2 of Library C then I have a clear problem because most popular programming languages don't support referencing multiple different versions of the same library.

OSGi and Java Modules would like a word. Too few developers use the facilities available for that kind of in-process isolation, even when it is possible. (Don't tell me Java isn't popular... It may be the new COBOL, but it's still mainstream.)

> OSGi and Java Modules would like a word.

Hold on - the way you are phrasing this implies that Java Modules allow you to solve the version problem mentioned above. As in, your comment implies that Java Modules have a concept of version, and thus, allow you to pick the correct version of a dependency when defining relationships.

Java Modules explicitly DO NOT have that ability. In fact, the creators of modules went out of their way to discourage the idea of using modules this way. They literally introduced a warning that flags your module if you add a number at the end of it - specifically so that they can discourage the concept of introducing versions into the module system.

The way Java Modules (and Java Classpath before it) works is like this - if you have a module ABC, then that is the only version of ABC as far as Java is concerned. The correct version should be decided upon and provided, but once you hand that version over to Java and press compile/link/run/etc, the concept of version is not existent anymore, as far as Java is concerned.

To better explain this, every Java class has a unique identifier -- the module name + the package name + the class name. That's it. So, if I have version 1 of ModuleName.PackageName.ABC and version 2 of ModuleName.PackageName.ABC, there is no way for Java to disambiguate them, and thus, will throw a compilation/linking/runtime error, saying that you have 2 versions of ABC.

And to further expand on the warning point above, some clever developers tried to work around this by putting the version number in the name somehow (for example, module name = ModuleName1). To firmly discourage this behaviour, the Java developers who made modules released the abovementioned warning, so that this problem could be nipped in the bud.

To summarize, dependency versioning is a problem that Java (currently) does not attempt to solve. It's considered an extra-linguistic concern that is left to the ecosystem to solve (which you should interpret it to mean, they're letting Maven/Gradle/etc deal with this problem (for now)).

Finally, a few members of the Java team are giving some thought to maybe dealing with this problem in the language, maybe with a build tool. There is absolutely 0 confirmation that this will even be given serious effort, let alone released as a feature/tool. But the problem is definitely being considered by some members of the Java Team. In fact, a user on this site (pron) may be able to give some helpful context on this. This is my first comment on this site, and I don't know how to use it, so someone else can try and link him.

Re: The costs of microservices (2020)

#395

Post by davidalayachew »

lmm wrote: post #301
slowmovintarget wrote: post #221

Earlier quoted context omitted.

OSGi and Java Modules would like a word. Too few developers use the facilities available for that kind of in-process isolation, even when it is possible. (Don't tell me Java isn't popular... It may be the new COBOL, but it's still mainstream.)

> OSGi and Java Modules would like a word. OSGi is the one that's deprecated and Java Modules is the one that can't actually provide that functionality yet, right? Or is it the other way round? Either way you get the point.

> Java Modules is the one that can't actually provide that functionality yet, right?

You are correct. As of now, Java Modules have no way to disambiguate versions of the same dependency. This is intentional and by design.

As far as Java is concerned, each class is uniquely identified by ModuleName.PackageName.ClassName. So, if there are 2 versions of the same class that have the same identifier, Java will give you an error at compile/link/run-time.

And if you try to be clever and slap a number at the end of the module name (in hopes of side-stepping this), Java will throw a warning at you, saying that you are likely trying to misuse modules by trying to use them to do dependency management.

Re: The costs of microservices (2020)

#396

Post by davidalayachew »

lmm wrote: post #393
pjmlp wrote: post #371

Earlier quoted context omitted.

Java modules are doing alright since Java 9, are the foundation for Java's linker and code stripping on AOT, while Eclipse keeps using OSGi just fine.

> Java modules are doing alright since Java 9 Can you actually use them to use two different versions of library C in the same application yet though? > Eclipse keeps using OSGi just fine Wasn't the impression I had the last time I tried to fix a bug in an eclipse plugin that touched on the OSGi parts. The codebase felt like a ghost town and I couldn't find any documentation for how it all worked or anyone who knew a…

> Can you actually use them to use two different versions of library C in the same application yet though?

Nope, this is functionality that Java (and thus, the module system) does not (yet) provide.

Re: The costs of microservices (2020)

#397

Post by tubthumper8 »

nijave wrote: post #279
sethammons wrote: post #7

Earlier quoted context omitted.

grug not experience large teams stepping on each other's domains and data models, locking in a given implementation and requiring large, organizational efforts to to get features out at the team level. Team velocity is empowered via microservices and controlling their own data stores. "We want to modernize how we access our FOO_TABLE for SCALE_REASONS by moving it to DynamoDB out of MySQL - unfortunately, 32 of our 5…

Microservices don't magically fix shared schema headaches. Getting abstraction and APIs right is the solution regardless of whether it's in-memory or over the network. Instead of microservices, you could add a static analysis build step that checks if code in packages is calling private or protected interfaces in different packages. That would also help enforce service boundaries without introducing the network as th…

I guess I'm confused by the suggestion - doesn't that static analysis step to check that code isn't calling private interfaces already exist, and is called a "compiler"?

Re: The costs of microservices (2020)

#398

Post by erik_seaberg »

smaudet wrote: post #389
tsss wrote: post #366

Earlier quoted context omitted.

> var queue = new Queue(); // then sometime later... queue.Save(); // or queue.EmplaceAndSave(); ... queue.Pop(); Yeah, no... you'll lose data for sure, you'll have race conditions or no cooperative queuing between multiple instances of the application. This is exactly the kind of half-assery that people resort to when they say monoliths are so much less complex than microservices. A good monolith still requires all…

Eh? Default queue implementations come with co-operating queuing out of the box. I suppose you could use some hand-rolled queue with no internal locking, but this is disingenuous. > you'll have race conditions or no cooperative queuing between multiple instances of the application. You're thinking micro-service again here. There's no need to have multiple "instances" at all. Any concurrency is handled internal to the…

Sure, but even a monolith should store data on redundant hardware before launch, because commodity hardware isn’t completely reliable and neither are datacenters.

Re: The costs of microservices (2020)

#399

Post by cpill »

lemmsjid wrote: post #223
cpill wrote: post #205

Earlier quoted context omitted.

> God forbid you find yourself with a need to rewrite one of these shitpiles. Actually, this is much easier with micro services as you have a clear interface you need to support and the code is not woven into the rest of the monolith like a French plat. The best code is the easiest to throw away and rewrite, because let's face it, the older the code is, the more hands it's been through, the worse it is, but more impo…

If the monolithic application is written in a language with sufficient encapsulation and good tooling around multi-module projects, then you can indeed have well known and encapsulated interfaces within the monolith. Within the monolith itself you can create a DAG of enforced interfaces and dependencies that is logically identical to a set of services from different codebases. There are well known design issues in mo…

> It takes effort to keep a monolithic application set up this way Yeah, this is the problem and _why_ I think microservices are the way forward as it doesn't take effort because the programmer is forced into do the right thing. On project with many different types of coders (and lets face it we are all different) consistency drops off fast. Of course you can do it with monoliths but I'm coming from a "real world" scenario where there are many people with different levels of ability and different levels of giving a cr@p about code quality. Micro services let people who code badly to do it in isolation and let themselves be the only ones who have to suffer under it, and ultimately learn from it (if they are not fired first). Also decoupling in a monolith vs by deployment is really just which git repo the code lives in, which are next to each other in the same directory on your hard drive. If there is shared code factor it out as a library/module and install it into the projects that need it. Its not a big deal

Re: The costs of microservices (2020)

#400

Post by girafffe_i »

andorov wrote: post #154
gedy wrote: post #147

Earlier quoted context omitted.

For some reason, most of the people I've worked with recently are either fully into monoliths or lots of fine grained, interdependent microservices. They don't seem to understand there's a useful middleground of adding fewer, larger data services, etc. It's like SOA isn't a hot topic so people aren't aware of it.

I've been using the term 'macro-services' to describe this middle ground.

Microliths
Post reply on HN