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

371–380 of 567 posts

Re: Monoliths Are the Future

#371

Post by dvirsky »

Clear boundaries and contracts are just a side effect of working in a service architecture, I've found. If this is your reason for doing it - just define a style guide on how to isolate code and make sure people (or procedures) keep it.

But there are many other valid reasons for services - different deployment cycles, better resource utilization, faster and safe deploys, etc. It's just about using the right tool and thinking about implications.

I don't know if such a framework exists, but I really want a system that abstracts this to a certain degree - while the contracts between parts of the system are defined, whether any module works as a service with its own deployment policy over network or as part of a monolith is not expressed in application code but as a configuration, and code generation handles the underlying logic. So you can write your app as a modular monolith, but when you think that for operational reasons there is a reason to spin off some part of it as a service, you reconfigure your build rules instead of your code.

Re: Monoliths Are the Future

#372

Post by default-kramer »

projektfu wrote: post #130
BrentOzar wrote: post #8

I'm a database guy, so the question I get from clients is, "We're thinking about breaking up our monolith into a bunch of microservices, and we want to use best-of-breed persistence layers for each microservice. Some data belongs in Postgres, some in DynamoDB, some in JSON files. Now, how do we do reporting?" Analysts expect to be able to connect to one system, see their data, and write queries for it. They were neve…

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 pretty terrible (compared to popular languages like C#, Python, etc...) But why has no one written a great DB language yet?

Re: Monoliths Are the Future

#373

Post by marsdepinski »

90% couldn't write a good monolith. 90% can't write good micro-services. Both share the same problem of modularity and separation of concerns. One comes with much lower development and operational costs for the competent. The other hides and creates new problems. I've developed on both architectures and there are use cases for each. It's never all or nothing. I can't even imagine how many engineers would be needed now to maintain the solid money making monoliths I've worked on with teams up to 8 over a decade ago. When the money dries up we'll be back on the monolith train.

Re: Monoliths Are the Future

#374

Post by yes_man »

rubyn00bie wrote: post #347

I couldn't agree more with an article. Most people think a micro-service architecture is a panacea because "look at how simple X is," but it's not that simple. It's now a distributed system, and very likely, it's a the worst-of-the-worst a distributed monolith. Distributed system are hard, I know, I do it. Three signs you have a distributed monolith: 1. You're duplicating the tables (information), without transformin…

I don't want advocate one way or another (micro vs. monoliths) because tomato tomato. However here are a few arguments in defense of microservices regarding these three signs you commented:

1. Microservices do not have some inherent property of having to duplicate data. You can have data in single source and deliver that data to anyone who needs it through an API. There are infinitely many caching solutions if you are worried about this becoming a bottleneck

2 and 2.5. There are tools for microservice architectures that counter these problems to a degree, mainstream example being containers and container orchestration (e.g. Docker and Kubernetes). One can even make an argument that microservices force you to build your systems so they are more robust than your monolith would be. If the argument for monoliths is that it's easier to maintain reliability when every egg is in one basket then you are putting all your bets into that basket and it becomes a black hole for developer and operations resources, as well as making operations evolution very slow

3. There are again tools for handling data and "syncing" (although I don't like the idea of having to "sync") the services, for example message queues / streaming processing platforms (e.g. Kafka). If some data or information might be of interest to multiple services, you should then push such data to a message queue and consume it from services that need it. The "syncing" problem sounds like something that arises when you start duplicating your data across services which shouldn't happen (see my argument on 1.)

Again not to say microservices are somehow universally better. Just coming into defense of their core concepts when they get unfairly accused

Re: Monoliths Are the Future

#375

Post by closeparen »

notJim wrote: post #211
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…

Wouldn't continuous deployment and rolling forward be better than switching your entire application architecture? In this scenario, you deploy ~30 times a day. If there's a bad commit, you revert it, and then do another deploy. So there's no rollbacks, you don't lose as much velocity, and since deploys are safe and a reverted commit is just a new commit, the revert is safe too.

It took at least 4 hours to deploy if everything went well; not sure if that was policy or an infrastructure limitation, but in any case more than 2 deploys per workday would have been impossible.

Re: Monoliths Are the Future

#376

Post by ar_lan »

rumanator wrote: post #366
rubyn00bie wrote: post #347

I couldn't agree more with an article. Most people think a micro-service architecture is a panacea because "look at how simple X is," but it's not that simple. It's now a distributed system, and very likely, it's a the worst-of-the-worst a distributed monolith. Distributed system are hard, I know, I do it. Three signs you have a distributed monolith: 1. You're duplicating the tables (information), without transformin…

> Most people think a micro-service architecture is a panacea because "look at how simple X is," but it's not that simple. It's now a distributed system, and very likely, it's a the worst-of-the-worst a distributed monolith. Distributed system are hard, I know, I do it. This line of argument fails to take into consideration any of the reasons why in general microservices are the right tool for the right job. Yes, it'…

I'm completely in your camp, and I'm surprised by the lack of nuance HN seems to show (especially regarding micro-services & Kubernetes).

There are many benefits to having microservices that people seem to forget because they think that everyone interested in microservices is interested in splitting their personal blog into 4 different services.

They take coordination, good CICD, and a lot of forethought to ensure each service is cooperating in the ecosystem properly, but once established, it can do wonders to dev productivity.

Re: Monoliths Are the Future

#377

Post by closeparen »

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…

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

Re: Monoliths Are the Future

#378

Post by no_wizard »

jonahbenton wrote: post #271
MadWombat wrote: post #131

Earlier quoted context omitted.

> Some data belongs in Postgres, some in DynamoDB, some in JSON files. Now, how do we do reporting? One of the key concepts in microservice architecture is data sovereignity. It doesn't matter how/where the data is stored. The only thing that cares about the details of the data storage is the service itself. If you need some data the service operates on for reporting purposes, make an API that gets you this data and…

Sorry, but "making an API that gets you this data" is the wrong answer. Most APIs are glorified wrappers around individual record-level operations like- get me this user- or constrained searches that return a portion of the data, maybe paginated. Reporting needs to see all the data. This is a completely different query and service delivery pattern. What happens to your API service written in a memory managed/garbage-…

Real question:

Why pull it into memory like that? Why not just pump it through a stream?

Re: Monoliths Are the Future

#379

Post by 0x445442 »

davnicwil wrote: post #199
eternalny1 wrote: post #35

What is old is new again. I've been a software engineer for over 30 years and have dealt with companies always trying to jump on the next bandwagon. One company I worked with tried to move our entire monolith application, which was well architected and worked fine, over to a microservices-based architecture and the result was an unstable, complex mess. Sometimes, if it's not broke, don't try to "fix" it. I can say th…

> people are trying to replicate stuff that works fine in other languages in JavaScript. Mostly because they are only familiar with JavaScript and don't realize this stuff already exists and doesn't need to be in JavaScript. Do you have a concrete example to illustate this, and what issues it causes? On the surface I'm not sure I agree, if what you're saying is people wanting a certain feature should switch languages…

What new problem was Nodejs trying to solve and why does it exist?

Re: Monoliths Are the Future

#380

Post by dabeeeenster »

edoloughlin wrote: post #356
simonw wrote: post #331

Earlier quoted context omitted.

A co-worker had a smart solution for this: your service's representation in a reporting system (a data warehouse for example) is part of its API. Your team should document it, and should ensure that when that representation changes information about the changes is available to the people who need to know it. This really makes sense to me. I love the idea that part of a microservice team's responsibility is ensuring t…

your service's representation in a reporting system At what point in time?

At the beginning: https://docs.pact.io/
Post reply on HN