7 ms·

I've never understood all this drama. In my experience, monoliths are universally bad in every imaginable way. A huge part of my career has been splitting monol

by bedobi 6y ago

I've never understood all this drama. In my experience, monoliths are universally bad in every imaginable way. A huge part of my career has been splitting monoliths into cohesive smaller codebases which could be called microservices. How to split them has never really been a problem, you tend to develop an intuition and the monolith kind of splits itself. Eg, currently we have user profiles (user id > the users names, email etc) in one microservice, relationships between users (user id > other user ids) in another. Each has its own datastore, deployment, scaling etc. It works great and while there is a small overhead cost to pay for splitting things it's vastly preferable to the monolith we used to have, which contained lots of things that had very little to do with each other, took ages to test and deploy, if it went down it was game over etc etc etc.

nicoburns 6y ago
> currently we have user profiles (user id > the users names, email etc) in one microservice, relationships between users (user id > other user ids) in another. What do you do when you need to query data across these boundaries?
- bedobi 6y ago
  If most of the callers did need both pieces of data it would have made sense to combine them into a single service. But, overwhelmingly, callers are interested in one piece of data or the other, and the load profile, tolerance for staleness in caching etc etc for each of the two services are vastly, vastly different. This is why we chose to split the two into different services. The few callers that do need to obtain both pieces of data just make concurrent calls to both and them zip them into a single result.
  - lowtech 6y ago
    Sounds like you have a simple system, in which case the separation have few drawbacks. It's not uncommon for a customer to ask for a report that to be generated needs to span dozens of tables. Or to save a DTO object that will trigger multiple microservices (and a lot of validations, transactions, rollback, etc). Business rules can be very complex and entangled in some shops.
    - yakshaving_jgt 6y ago
      I'd say it sounds like they have a distributed monolith :)
    - nine_k 6y ago
      Good thing if your data fit into a single database; sometimes they do not, because they are too big. OTOH you can often export the data in different, more appropriate ways to make your joins more efficient.
    - bedobi 6y ago
      It's not a simple system, we have all those things and more. But when we make a service that contains partner user profiles data we optimize for that (=millions of partners accessing their profiles, has to respond immediately and scale infinitely, has to be easy and quick to capture new details like eg mfa preference app vs sms etc), not peripheral things like reports etc - such things have to live life being harder for them than they would be if we had a monolith.
recursive 6y ago
> In my experience, monoliths are universally bad in every imaginable way. I just imagined a different way. Monoliths can do transactionally consistent stuff.
- bedobi 6y ago
  For sure, that's a factor that should be taken into account when deciding what to split and how. But monoliths always have completely unrelated things bunched up in a single codebase, storage etc etc etc. Eg, in our case, there's simply no reason why we should have a single monolith service that has both our b2b partners user profiles and, I don't know, internal staff vacation hours? They have nothing to do with each other, have vastly different load profiles, tolerance for failure etc etc.
- nine_k 6y ago
  Now you have a good rule of thumb for splitting services: stuff that must belong to a single transaction should live in the same service. This is how you e.g. can split a bank transaction service from a bank balance-telling service, with different requirements for scaling, latency, SLAs, deployment schedules, etc. You can deploy a change to the balance-telling service and then roll it back if it exhibits a problem, all without touching transaction proceeding in any way. These abilities are worth something if you're a big enough. But this is not a starting point for a new side project. You start with a monolith.
  - tluyben2 6y ago
    > You start with a monolith. I think that is the HN syndrome; people start projects like they will be larger than facebook even though the project will probably never launch and if it does, get more than 10 users. Yet it runs all services aws has to offer and has 100 microservices and the little company(‘s investors) are paying through the nose in both dev time and hosting while a raw php script on a $1/mo vps would’ve been sufficient to validate the idea and get to ramen profitability and (far) beyond. Like someone said in another thread; focus on your market and acquisition channels first, build great stuff (much) later.
jeremyjh 6y ago
> A huge part of my career has been splitting monoliths into cohesive smaller codebases Did that ... create business value for your company? > Eg, currently we have user profiles (user id > the users names, email etc) in one microservice, relationships between users (user id > other user ids) in another. This sounds like a parody of microservices.
- bedobi 6y ago
  Yes, it did create business value. * our enterprise db was bursting at the seams containing Literally Everything. Now, every part of the split up monolith has it's own self contained data store tailored to what is appropriate for that particular thing. (some use MariaDB, others Redis etc etc) * developing, building, testing and deploying took ages. Eg if I only needed to capture some new detail about a business partner user (eg their mfa preference app vs sms) I would still have to do deal with the unwieldy monolith. Now, I can do it in the dedicated business partner user service, which is much easier and faster. * the whole monolith, including business partner facing operations, could go down because of issues to do with completely unrelated, non critical things like eg internal staff vacation hours. I could go on. As for the different services I described, if most of the callers did need both pieces of data it would have made sense to combine them into a single service. But, overwhelmingly, callers are interested in one piece of data or the other, and the load profile, tolerance for staleness in caching etc etc for each of the two services are vastly, vastly different. This is why we chose to split the two into different services. The few callers that do need to obtain both pieces of data just make concurrent calls to both and them zip them into a single result.
  - candiddevmike 6y ago
    > * our enterprise db was bursting at the seams containing Literally Everything. Now, every part of the split up monolith has it's own self contained data store tailored to what is appropriate for that particular thing. (some use MariaDB, others Redis etc etc) Why do you consider an enterprise DB "bursting at the seams" to be a bad thing? Isn't that what enterprise DBs are built for? Seems like you traded having everything in one large database to having everything scattered in different databases. You probably sacrificed some referential integrity in the process. > * developing, building, testing and deploying took ages. Eg if I only needed to capture some new detail about a business partner user (eg their mfa preference app vs sms) I would still have to do deal with the unwieldy monolith. Now, I can do it in the dedicated business partner user service, which is much easier and faster. You traded a clean codebase with a solid toolchain for probably a template repository that you hope your users use or everyone is reinventing some kind of linting/testing/deployment toolchain for every microservice > * the whole monolith, including business partner facing operations, could go down because of issues to do with completely unrelated, non critical things like eg internal staff vacation hours. This could apply to any software. Sure, a monolith can have a large blast radius, but I can guarantee one of your microservices is critical path and would cause the same outage if it goes offline. > The few callers that do need to obtain both pieces of data just make concurrent calls to both and them zip them into a single result. Almost like a database join?
gajjanag 6y ago
The issue (for me at least) is not the idea of microservices itself, it is the granularity at which services get defined/split off. What usually happens is that companies go all-in on the microservices idea, and force it upon all teams regardless of their size/head count. It is far easier for a 10 person team to maintain a microservice than it is for a 3 person team. Microservices impart some fixed costs to every team managing a service and thus make very little sense for small teams. On the other hand, a 3 person team can much more productively contribute to a monolith. From my experience in the industry so far, taking into account the current quality of tooling, I would say it starts to make sense for teams above the 10 person mark to own their own service.
- mcny 6y ago
  Maybe I don't understand microservices but what is to stop a team from declaring the whole monolith to be just one microservice? I have interviewed at a few places over the last year and not one interviewer has given me a hundred percent guarantee that we will never have to allow access to the backing store (database) that isn't through our service. Of course, microservice will fail in such environments. That's not a microservice fault. That's a defect in management.
sokoloff 6y ago
> monoliths are universally bad in every imaginable way In my experience, monoliths are simpler and often faster to ship a working v1.0. When that matters (which seems like it would be “quite often”), they are a short-term winner. You have to survive the short-term in order to face the problem of the long-term.
jturpin 6y ago
If it were up to Hackernews commenters, no software created after 1998 would be used - everything would run on a single monolith, use Postgresql, run with System V and written in, I don't know, Perl with CGI. It worked fine back then, why do we need to change it and make it all fancy and complicated? I don't know the career histories of these kinds of people, I'm sure its varied, but I just can't imagine them working in very large public facing dynamic sites that update multiple times a day with monoliths thinking "this sure can't be improved! We have reached the peak of computing!" I've seen microservices go really badly of course - I worked in a place where the devs insisted that two microservices need to go out "at the same time," as if such a concept existed, because they depended on each other. At the end of me working there, there were around 40 microservices, all Java so they needed at least 2GB of memory each, some 8GB, and at least 3 replicas for high availability. Cost a small fortune in servers for what really could have been like, 5 microservices, written in Go or Node and run on a handful of normal servers. But microservices, like Kubernetes, are not _hype_, they are not a flash in the pan and they're here to stay because they are a good idea conceptually, even if they often aren't executed very well.
- collyw 6y ago
  Having worked on both types of systems, old school way was far simpler, and bugs were faster to fix. Sure there are advantages to kubernetes, it will scale easily, but that is a problem that I have seen solved far more times than it has actually been needed.
ramraj07 6y ago
If you're like facebook, it makes sense to split user profiles and relationships to two microservices, but if you handle a few tens of thousands of users it does not, so you're doing yourself a disservice by using a poor example to drive the point
danmaz74 6y ago
From your following comments I see that you consider a monolith a software that does "everything", from managing staff holidays to giving services to customers. But this isn't what monolithic architecture Vs microservices is about; if you have independent business processes, it's been completely normal forever to have independent "monoliths" to manage them. Many proponents of microservices though request that you split your software into small independent services even when they manage the same business process, and this is where the complications come.
branko_d 6y ago
> we have user profiles (user id > the users names, email etc) in one microservice, relationships between users (user id > other user ids) in another. > Each has its own datastore How do you maintain referential integrity between datastores? For example, when a user is deleted, how do you update the relationships between users in a concurrency-safe way?
tatersolid 6y ago
You’ve given up on data consistency entirely, which is a significant problem with micro-services in general. Do you run DR tests? I bet $TEXAS you will have orphaned relationships as your data stores will be restored from different points in time.

by bedobi 6y ago

nicoburns 6y ago

> currently we have user profiles (user id > the users names, email etc) in one microservice, relationships between users (user id > other user ids) in another. What do you do when you need to query data across these boundaries?

bedobi 6y ago
If most of the callers did need both pieces of data it would have made sense to combine them into a single service. But, overwhelmingly, callers are interested in one piece of data or the other, and the load profile, tolerance for staleness in caching etc etc for each of the two services are vastly, vastly different. This is why we chose to split the two into different services. The few callers that do need to obtain both pieces of data just make concurrent calls to both and them zip them into a single result.
- lowtech 6y ago
  Sounds like you have a simple system, in which case the separation have few drawbacks. It's not uncommon for a customer to ask for a report that to be generated needs to span dozens of tables. Or to save a DTO object that will trigger multiple microservices (and a lot of validations, transactions, rollback, etc). Business rules can be very complex and entangled in some shops.
  - yakshaving_jgt 6y ago
    I'd say it sounds like they have a distributed monolith :)
  - nine_k 6y ago
    Good thing if your data fit into a single database; sometimes they do not, because they are too big. OTOH you can often export the data in different, more appropriate ways to make your joins more efficient.
  - bedobi 6y ago
    It's not a simple system, we have all those things and more. But when we make a service that contains partner user profiles data we optimize for that (=millions of partners accessing their profiles, has to respond immediately and scale infinitely, has to be easy and quick to capture new details like eg mfa preference app vs sms etc), not peripheral things like reports etc - such things have to live life being harder for them than they would be if we had a monolith.

recursive 6y ago

> In my experience, monoliths are universally bad in every imaginable way. I just imagined a different way. Monoliths can do transactionally consistent stuff.

bedobi 6y ago
For sure, that's a factor that should be taken into account when deciding what to split and how. But monoliths always have completely unrelated things bunched up in a single codebase, storage etc etc etc. Eg, in our case, there's simply no reason why we should have a single monolith service that has both our b2b partners user profiles and, I don't know, internal staff vacation hours? They have nothing to do with each other, have vastly different load profiles, tolerance for failure etc etc.
nine_k 6y ago
Now you have a good rule of thumb for splitting services: stuff that must belong to a single transaction should live in the same service. This is how you e.g. can split a bank transaction service from a bank balance-telling service, with different requirements for scaling, latency, SLAs, deployment schedules, etc. You can deploy a change to the balance-telling service and then roll it back if it exhibits a problem, all without touching transaction proceeding in any way. These abilities are worth something if you're a big enough. But this is not a starting point for a new side project. You start with a monolith.
- tluyben2 6y ago
  > You start with a monolith. I think that is the HN syndrome; people start projects like they will be larger than facebook even though the project will probably never launch and if it does, get more than 10 users. Yet it runs all services aws has to offer and has 100 microservices and the little company(‘s investors) are paying through the nose in both dev time and hosting while a raw php script on a $1/mo vps would’ve been sufficient to validate the idea and get to ramen profitability and (far) beyond. Like someone said in another thread; focus on your market and acquisition channels first, build great stuff (much) later.

jeremyjh 6y ago

> A huge part of my career has been splitting monoliths into cohesive smaller codebases Did that ... create business value for your company? > Eg, currently we have user profiles (user id > the users names, email etc) in one microservice, relationships between users (user id > other user ids) in another. This sounds like a parody of microservices.

bedobi 6y ago
Yes, it did create business value. * our enterprise db was bursting at the seams containing Literally Everything. Now, every part of the split up monolith has it's own self contained data store tailored to what is appropriate for that particular thing. (some use MariaDB, others Redis etc etc) * developing, building, testing and deploying took ages. Eg if I only needed to capture some new detail about a business partner user (eg their mfa preference app vs sms) I would still have to do deal with the unwieldy monolith. Now, I can do it in the dedicated business partner user service, which is much easier and faster. * the whole monolith, including business partner facing operations, could go down because of issues to do with completely unrelated, non critical things like eg internal staff vacation hours. I could go on. As for the different services I described, if most of the callers did need both pieces of data it would have made sense to combine them into a single service. But, overwhelmingly, callers are interested in one piece of data or the other, and the load profile, tolerance for staleness in caching etc etc for each of the two services are vastly, vastly different. This is why we chose to split the two into different services. The few callers that do need to obtain both pieces of data just make concurrent calls to both and them zip them into a single result.
- candiddevmike 6y ago
  > * our enterprise db was bursting at the seams containing Literally Everything. Now, every part of the split up monolith has it's own self contained data store tailored to what is appropriate for that particular thing. (some use MariaDB, others Redis etc etc) Why do you consider an enterprise DB "bursting at the seams" to be a bad thing? Isn't that what enterprise DBs are built for? Seems like you traded having everything in one large database to having everything scattered in different databases. You probably sacrificed some referential integrity in the process. > * developing, building, testing and deploying took ages. Eg if I only needed to capture some new detail about a business partner user (eg their mfa preference app vs sms) I would still have to do deal with the unwieldy monolith. Now, I can do it in the dedicated business partner user service, which is much easier and faster. You traded a clean codebase with a solid toolchain for probably a template repository that you hope your users use or everyone is reinventing some kind of linting/testing/deployment toolchain for every microservice > * the whole monolith, including business partner facing operations, could go down because of issues to do with completely unrelated, non critical things like eg internal staff vacation hours. This could apply to any software. Sure, a monolith can have a large blast radius, but I can guarantee one of your microservices is critical path and would cause the same outage if it goes offline. > The few callers that do need to obtain both pieces of data just make concurrent calls to both and them zip them into a single result. Almost like a database join?

gajjanag 6y ago

The issue (for me at least) is not the idea of microservices itself, it is the granularity at which services get defined/split off. What usually happens is that companies go all-in on the microservices idea, and force it upon all teams regardless of their size/head count. It is far easier for a 10 person team to maintain a microservice than it is for a 3 person team. Microservices impart some fixed costs to every team managing a service and thus make very little sense for small teams. On the other hand, a 3 person team can much more productively contribute to a monolith. From my experience in the industry so far, taking into account the current quality of tooling, I would say it starts to make sense for teams above the 10 person mark to own their own service.

mcny 6y ago
Maybe I don't understand microservices but what is to stop a team from declaring the whole monolith to be just one microservice? I have interviewed at a few places over the last year and not one interviewer has given me a hundred percent guarantee that we will never have to allow access to the backing store (database) that isn't through our service. Of course, microservice will fail in such environments. That's not a microservice fault. That's a defect in management.

sokoloff 6y ago

> monoliths are universally bad in every imaginable way In my experience, monoliths are simpler and often faster to ship a working v1.0. When that matters (which seems like it would be “quite often”), they are a short-term winner. You have to survive the short-term in order to face the problem of the long-term.

jturpin 6y ago

If it were up to Hackernews commenters, no software created after 1998 would be used - everything would run on a single monolith, use Postgresql, run with System V and written in, I don't know, Perl with CGI. It worked fine back then, why do we need to change it and make it all fancy and complicated? I don't know the career histories of these kinds of people, I'm sure its varied, but I just can't imagine them working in very large public facing dynamic sites that update multiple times a day with monoliths thinking "this sure can't be improved! We have reached the peak of computing!" I've seen microservices go really badly of course - I worked in a place where the devs insisted that two microservices need to go out "at the same time," as if such a concept existed, because they depended on each other. At the end of me working there, there were around 40 microservices, all Java so they needed at least 2GB of memory each, some 8GB, and at least 3 replicas for high availability. Cost a small fortune in servers for what really could have been like, 5 microservices, written in Go or Node and run on a handful of normal servers. But microservices, like Kubernetes, are not _hype_, they are not a flash in the pan and they're here to stay because they are a good idea conceptually, even if they often aren't executed very well.

collyw 6y ago
Having worked on both types of systems, old school way was far simpler, and bugs were faster to fix. Sure there are advantages to kubernetes, it will scale easily, but that is a problem that I have seen solved far more times than it has actually been needed.

ramraj07 6y ago

If you're like facebook, it makes sense to split user profiles and relationships to two microservices, but if you handle a few tens of thousands of users it does not, so you're doing yourself a disservice by using a poor example to drive the point

danmaz74 6y ago

From your following comments I see that you consider a monolith a software that does "everything", from managing staff holidays to giving services to customers. But this isn't what monolithic architecture Vs microservices is about; if you have independent business processes, it's been completely normal forever to have independent "monoliths" to manage them. Many proponents of microservices though request that you split your software into small independent services even when they manage the same business process, and this is where the complications come.

branko_d 6y ago

> we have user profiles (user id > the users names, email etc) in one microservice, relationships between users (user id > other user ids) in another. > Each has its own datastore How do you maintain referential integrity between datastores? For example, when a user is deleted, how do you update the relationships between users in a concurrency-safe way?

tatersolid 6y ago

You’ve given up on data consistency entirely, which is a significant problem with micro-services in general. Do you run DR tests? I bet $TEXAS you will have orphaned relationships as your data stores will be restored from different points in time.