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

Monoliths Are the Future

changelog.com

Post reply on HN
Print view View original

541–550 of 567 posts

Re: Monoliths Are the Future

#541

Post by smoyer »

zamalek wrote: post #539
smoyer wrote: post #406

Earlier quoted context omitted.

We've moved a lot of services into Kubernetes and broken things up into smaller and smaller micro-services. It definitely eliminates a lot of the complexity for developers ... but you trade it for operational complexity (e.g. routing, security, mis-matched client/server versions, resiliency when dependency isn't responding). I still believe that overall software quality is higher with micro-services (our Swagger docu…

> It definitely eliminates a lot of the complexity for developers We're currently translating a 20 year old ~50MLOC codebase into a distributed monolith (using a variety of approaches that all approximate strangler). I have far less motivation to go to work if I know that I will be buried in the old monorepo. I can change, build and get a service changed in less than an hour. Touching the monorepo is easily 1.5 days…

Sorry ... I should have said "don't kid yourself that you'll save time" instead of developer time. We do indeed have a faster change cycle on every service which is a win even if we're still burning (in general) the same number of hours over the whole system.

I also should have mentioned that it's definitely more pleasant for those in purely development roles. Troubleshooting, resiliency and system effects don't impact everyone (and I actually like those types of hard problems). I'd also suggest that integrating tracing, metrics, and logging in a consistent way is imperative. If you're on Kubernetes, using a proxy like Istio (Envoy) or LinkerD is a great way to get retries, backoff, etc established without changing coded.

Finally, implementing a healthcheck end-point on every service and having the impact of any failures properly degrade dependent services is really helpful both in troubleshooting and ultimately in creating a UI with graceful degradation (toasts with messages related to what's not currently available are great). I have great hopes for the healthcheck RFC that's being developed at https://github.com/inadarei/rfc-healthcheck.

Re: Monoliths Are the Future

#542

Post by mbrodersen »

If you can’t write well functioning monoliths, then you most definitely will fail implementing the same system using micro-services. Micro-services have all the complexity of the monolith plus the complexity of a distributed system added on top.

Re: Monoliths Are the Future

#543

Post by tartrate »

IggleSniggle wrote: post #483
galaxyLogic wrote: post #443

Earlier quoted context omitted.

Micro-services are just connected things which work together to accomplish something. But where are those connections described? In some tables somewhere. Maybe. Whereas if you write a single monolithic program its connections are described in code, preferably type-checked by a compiler. I think that gives you at least theoretically a better chance of understanding what are the things that connect, and how they conne…

There is such a language, and it is Erlang.

I have never tried Erlang, but I have read that it doesn't have static type checking. How does it guarantee that different services are following protocols?

Re: Monoliths Are the Future

#544

Post by TomMarius »

tartrate wrote: post #543
IggleSniggle wrote: post #483

Earlier quoted context omitted.

There is such a language, and it is Erlang.

I have never tried Erlang, but I have read that it doesn't have static type checking. How does it guarantee that different services are following protocols?

This is the relevant chapter in the manual: https://erlang.org/doc/reference_manual/typespec.html

Re: Monoliths Are the Future

#545

Post by peteforde »

bastardson wrote: post #520
peteforde wrote: post #508

Earlier quoted context omitted.

I didn't declare their argument won, lost or invalid. I did suggest that they consider the bona fides of the person whose opinion they were tossing off as uneducated. Thanks for the downvote, though.

> I did suggest that they consider the bona fides of the person whose opinion they were tossing off as uneducated. It would be more constructive to give reasons why one argument is better than another though, rather than resorting to status, and you did not reference any of the commenter’s points. > Thanks for the downvote, though. I don’t have the karma required to give a downvote. I’m not sure who you should thank.

Honestly, you're missing or avoiding my point: I'm not deferring to the author because he's respected or has a popular blog.

I am suggesting that the OP has little business writing off a legitimate expert's opinion in a domain where they are highly qualified to comment. This isn't controversial.

If you had the karma to downvote, would you give a hard time to the OP who started with "The author does not seem to understand when to correctly apply microservices."?

Re: Monoliths Are the Future

#546

Post by projektfu »

default-kramer wrote: post #372
projektfu wrote: post #130

Earlier quoted context omitted.

It's a little sad because originally, people thought there would be a shared data base (now one word) for the whole organization. Data administrators would write rules for the data as a whole and keep applications in line so that they operated on that data base appropriately. A lot of DBMS features are meant to support this concept of shared use by diverse applications. What ended up happening is each application use…

Do you know why the shared database vision didn't work out? Because I still think it would be the best approach for many companies. Most companies are small enough that they could spend less than $10k/month for an extremely powerful cloud DB. Then you could replace most microservices with views or stored procs. What could be simpler? I think one reason to avoid this approach is because SQL and other DB languages are…

Probably for the same reasons that waterfall development doesn't work out. This approach requires up-front specification of the data before the application domain is well understood. Any application desiring a migration to a different schema would need to work with the others to do it. Finally, developers bristle at the idea that they have to wait for another team to get their job done. In the absence of a strong company policy, it will inevitably drift toward shipping an application rather than keeping everything together.

Perhaps refactoring, had it been better understood around 1970, could have gone a long way toward harmonizing diverse schemas, allowing experimentation with eventual refactoring into the common database.

Our current environment makes this impossible. There's no way that Salesforce is going to ship a version that works with your company's database schema. You're going to have to supply that replication yourself. Same for Quickbooks. To get that kind of customization you need to be spending hundreds of thousands for enterprise software.

Re: Monoliths Are the Future

#547

Post by takeda »

tootie wrote: post #220
closeparen wrote: post #57

My employer adopted microservices for a very specific reason: it became nearly impossible to deploy the monolith. With hundreds of commits trying to go out every day, probability that at least one would break something approached 1. Then everything had to be rolled back. Getting unrelated concerns into separate deployable artifacts rescued our velocity. It came with many of its own challenges, too! A great deal of in…

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 r…

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.

Re: Monoliths Are the Future

#548

Post by projektfu »

zerd wrote: post #463
default-kramer wrote: post #372

Earlier quoted context omitted.

Do you know why the shared database vision didn't work out? Because I still think it would be the best approach for many companies. Most companies are small enough that they could spend less than $10k/month for an extremely powerful cloud DB. Then you could replace most microservices with views or stored procs. What could be simpler? I think one reason to avoid this approach is because SQL and other DB languages are…

I've worked on a service like this. 800k lines of PL/SQL and Java stored procesures (running inside the database, so you could call Java from PL/SQL and vice versa), powered by triggers. * Testing is god-awful. To test a simple thing you had to know how the whole application worked, because there's validation in triggers, which triggers other triggers, which require things to be in a certain state. This made refactor…

I think they go too crazy with the stored procedures. I would rather see constraints and views to make the data work. Triggers are useful for simple behind-the-scenes things like logging, or creating updateable views, but their behavior should be kept simple. If they're sending e-mails and launching missiles, it's probably too much.

Debugging PL/SQL without the PL/SQL debugger is nearly impossible. Unfortunately a lot of shops cheap out on developer tools after they buy the server licenses. I never liked the idea of Java on the database. The good thing about PL/SQL is that nobody wants to write it so it has a tendency to not be overused by most developers.

The performance ceiling probably wouldn't be too low if there weren't too much extra activity with each update. As with all databases, sharding and replication are your friend.

Re: Monoliths Are the Future

#549

Post by dcwca »

peteforde wrote: post #82
dcwca wrote: post #10

The author does not seem to understand when to correctly apply microservices. There are two basic use cases: 1) Different parts of your solution have different load patterns and it is economically beneficial to scale them at different rates and 2) Different teams need to be able to work & ship autonomously. It's not at all about technical merits or architectural beauty. It's about people and costs.

The author is a Kubernetes expert, so perhaps you are the student and not the master? https://github.com/kelseyhightower/kubernetes-the-hard-way

Different dimensions of analysis, I guess. I’m not surprised the author isn’t talking about business drivers.

Re: Monoliths Are the Future

#550

Post by takeda »

mr_tristan wrote: post #396
nitwit005 wrote: post #290

Earlier quoted context omitted.

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 conflict…

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…

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