9 ms·

There is a lot of talk about monoliths vs microservices lately.. I just want to throw into the ring that you can do both at the same time. easily. And noone is

There is a lot of talk about monoliths vs microservices lately.. I just want to throw into the ring that you can do both at the same time. easily. And noone is going to kill you for it either. maybe we are getting caught up in sematics because its christmas, but "monorepo/monolith/microservices/etc" is -just- the way you organize your code. Developing a montolith for years but now you have written a 15 line golang http api that converts pdfs to stardust and put it into on a dedicted server in your office? welp thats a microservice. Did you write a 150 repo application that can not be deployed seperatly anyway? welp thats a monolith. You can also build a microservice ecosystem without kubernetes on your local network. We have done it for years with virtual machines. Software defined networking just makes things more elegant. So dont stop using microservices because its "hard" or start writing monoliths because its "easy", because none of that is true in the long run. What is true is that you have a group of people trying to code for a common goal. The way you reach that goal together defines how you organize your code.

victor106 5y ago
>monorepo/monolith/microservices/etc" is -just- the way you organize your code. It’s also about how you deploy your code. If you have 1000 micro services do you have 1000 deployment pipelines? If so how do you manage those pipelines? If not, you sacrifice independent deployment of each micro service.
- VBprogrammer 5y ago
  I don't even think the deployment pipelines are the problem. If you have 1000 microservices you have 2^1000 possible states of your application based on any of those services being up or down (reality is much more complex). It is genuinely hard to keep that number of services up and running so you then need to be extraordinarily diligent about how you handle failures.
- jhoelzel 5y ago
  yes and no. i totally get what you are saying but this problem has been solved lately in my opinion. Also deployment is part of code organistaion no? i like to point out the fact that i explicitly mentioned you do not need to decide, you can use both at the same time but i would like to try to answer your point anyway: Maybe I am just spoiled with go and github, but those deployment pipelines can be directly integrated into your repository. The same way I can counter argue that your build ci and deployment phase will take significantly more time too and if you change a variable from uppercase to lowercase you will wait for minutes too. I come from a c# background a long time ago and this has been true with it for eons: https://xkcd.com/303/ https://xkcd.com/303/ Another thing that I have noticed is that its easily scriptable too. What I end up doing is to provide a makefile into my repository too. This way i can define the build process amongst other things eaisly. In the end: We have a predefined spec that will create the desired state on a host of our chosing. Ansible really does not care if you deploy 1 or 1000 "services" for instance! Tools Like ArgoCD will also deploy stuff when you commit to your master. There is tooling for everyone available, but what happnes quite often is that the people in charge of the company expected the developers to be all knowing entities that need to define everything end to end. The Kubernetes Space is vast because we are still defining and communication its future. But recently? I am trying to think of something that would not be completly automateable in 2021
  - victor106 5y ago
    > totally get what you are saying but this problem has been solved lately in my opinion. How? Can you provide any examples?
- AtNightWeCode 5y ago
  If you have that many services you could define a set of generic pipeline versions that you maintain. Then you can tag each service with which type of pipeline to use. The rest is solved with automation.
Pamar 5y ago
Maybe it is just me, but I always understood that properly designed microservices have their own specific datastore, which is not shared with other microservices even if these all collaborate to the same process. If this is actually (still) true, that means that "the way you organize your code" is a bit simplistic. Your example of an "http api that converts pdfs to ..." is surely a valid example of a microservice, but most business products have to handle much more "state" than those, and this will create further complications which go far beyond "how to organize your code" (and make monoliths more appealing).
- pibi 5y ago
  Well, it's all about the data responsibility: who is the owner of the data, how others can access the data. Once you have defined these, you see that you can "share the access" with other microservices (for example read only mode on a view), as long as the ownership and the access rules are preserved.
  - Pamar 5y ago
    Yes, a view would be exactly how I would address the problem I described in my other answer above ("What happens if I need to change zip code representation in a data source that is read by multiple microservices?"). But this also means that we are now back into "YesSQL" territory, and specifically that we have to use a RDBMS which allows us to create Views. Goodbye NoSQL, goodbye Key+Valus datastore. (Or maybe you will just create an extra "newZipCode" and mantain it in parallel with "ZipCode" allowing every other consumer to adapt at their leisure...?). So it is another step back to "more traditional ways" to design a system... or a recipe for a disaster as soon as you start dealing with significant quantities of "state".
- VBprogrammer 5y ago
  IMHO Microservices done well should actually cut a whole vertical through your applications feature space. So not only should it be responsible completely for its own storage of data but it should be responsible for how that data is shown on the front end (or as close to that as you can realistically achieve). A microservice should ideally be reviews or left navigation not customer authentication or order processing.
pibi 5y ago
Clarify the microservice architecture concept with "how you are going to deploy your system", as per your example, is exactly what I'm trying to explain to my teams since the microservice architecture inception. There are too many concepts conflating into the "microservice" term: code architecture(separation of concerns), source code organization, deployment, etc. This is very confusing, which is the reason why it's now common to say that microservices are "hard".
sdevonoes 5y ago
> Developing a montolith for years but now you have written a 15 line golang http api that converts pdfs to stardust and put it into on a dedicted server in your office? welp thats a microservice. But the 15 lines of Golang are not just 15 lines of Golang in production. You need: - auth? Who can talk to your service? Perhaps ip whitelisting? - monitoring? How do you know if you service is up and running? If it's down, you need alerts as well. What if there is a memory problem (because code is not optimal)? - how do you deploy the service? Plain ansible or perhaps k8s? Just scp? Depending on your solution, how do you implement rollbacks? - what about security regarding outdated packages the Go app is using? You need to monitor it as well. And so on. The moment you need to store data that somehow needs to be in sycn with the monolith's data, everything gets more complicated. Production stuff is not just about lines of code.
- jhoelzel 5y ago
  no why? The task of the Microservice is to convert the pdf to stardust and to return it to its sender. so no auth. Furthermore its most likely only reachable through the local network, or at least should be if you want some stranger not to be able to also make stardust from pdfs. Monitoring: are you trying to say that its a lot esaier to pick up one logfile thant lets say 15? because they should be aggregated somewhere anyway no? Deployment: Depending on anything you listed how do i do anything? Of course if have to define it but if you want a fancy example: k8s argocd canary deployments done. I literally set it up once. security? Really? Please dont get this wrong but this feels to me like whataboutism but well here i go: i implement security just the same way as i would in the monorepo. The thing/person/entity just has to look into more repositories ;) It comes down do one sentence i think: State is not shared, state is communicated.
  - comradesmith 5y ago
    For monitoring I’d also say the alerting side of things can be done via the older monolith. That is, catch exceptions and log/re-raise them as “PdfServiceException”.
  - rich_sasha 5y ago
yakshaving_jgt 5y ago
> "monorepo/monolith/microservices/etc" is -just- the way you organize your code I don't think this is true. I think — at least as far as I've observed — microservices in practice means replacing various functions calls with slow and error-prone network requests. This is a big and meaningful difference.
GrumpyNl 5y ago
You need at least two teams for that.
- jhoelzel 5y ago
  optimally yes. The application dev does not need acces to production whatever and the devops person does not need to know how the application works. But then again these to people also need to communicate ;)
arthur_sav 5y ago
Exactly, it doesn't have to be one or the other. So far, i've been using a monolith for core functionality and microservices for independent processing tasks. That way, i can attach as much functionality as i want without bloating the main app and processing scales with demand.
baskethead 5y ago
> There is a lot of talk about monoliths vs microservices lately. Actually it's been going on for years, and it's always the same argument. People think they're thought leaders for saying "Start with monoliths and only move to microservices if you absolutely need to!" It's a pretty obvious conclusion to anyone who has worked in both environments, or have had to migrate from one to the other, so it's not particularly insightful. And yet here were are, 5+ years later saying the same thing over and over again.
- hnzix 5y ago
  > It's a pretty obvious conclusion to anyone who has worked in both environments, or have had to migrate from one to the other, so it's not particularly insightful. It should be obvious, but apparently it's not. So many architecture astronauts drinking the kool-aid and making a mess. Premature microservices can easily kill a product.

victor106 5y ago

>monorepo/monolith/microservices/etc" is -just- the way you organize your code. It’s also about how you deploy your code. If you have 1000 micro services do you have 1000 deployment pipelines? If so how do you manage those pipelines? If not, you sacrifice independent deployment of each micro service.

VBprogrammer 5y ago
I don't even think the deployment pipelines are the problem. If you have 1000 microservices you have 2^1000 possible states of your application based on any of those services being up or down (reality is much more complex). It is genuinely hard to keep that number of services up and running so you then need to be extraordinarily diligent about how you handle failures.
jhoelzel 5y ago
yes and no. i totally get what you are saying but this problem has been solved lately in my opinion. Also deployment is part of code organistaion no? i like to point out the fact that i explicitly mentioned you do not need to decide, you can use both at the same time but i would like to try to answer your point anyway: Maybe I am just spoiled with go and github, but those deployment pipelines can be directly integrated into your repository. The same way I can counter argue that your build ci and deployment phase will take significantly more time too and if you change a variable from uppercase to lowercase you will wait for minutes too. I come from a c# background a long time ago and this has been true with it for eons: https://xkcd.com/303/ https://xkcd.com/303/ Another thing that I have noticed is that its easily scriptable too. What I end up doing is to provide a makefile into my repository too. This way i can define the build process amongst other things eaisly. In the end: We have a predefined spec that will create the desired state on a host of our chosing. Ansible really does not care if you deploy 1 or 1000 "services" for instance! Tools Like ArgoCD will also deploy stuff when you commit to your master. There is tooling for everyone available, but what happnes quite often is that the people in charge of the company expected the developers to be all knowing entities that need to define everything end to end. The Kubernetes Space is vast because we are still defining and communication its future. But recently? I am trying to think of something that would not be completly automateable in 2021
- victor106 5y ago
  > totally get what you are saying but this problem has been solved lately in my opinion. How? Can you provide any examples?
AtNightWeCode 5y ago
If you have that many services you could define a set of generic pipeline versions that you maintain. Then you can tag each service with which type of pipeline to use. The rest is solved with automation.

Pamar 5y ago

Maybe it is just me, but I always understood that properly designed microservices have their own specific datastore, which is not shared with other microservices even if these all collaborate to the same process. If this is actually (still) true, that means that "the way you organize your code" is a bit simplistic. Your example of an "http api that converts pdfs to ..." is surely a valid example of a microservice, but most business products have to handle much more "state" than those, and this will create further complications which go far beyond "how to organize your code" (and make monoliths more appealing).

pibi 5y ago
Well, it's all about the data responsibility: who is the owner of the data, how others can access the data. Once you have defined these, you see that you can "share the access" with other microservices (for example read only mode on a view), as long as the ownership and the access rules are preserved.
- Pamar 5y ago
  Yes, a view would be exactly how I would address the problem I described in my other answer above ("What happens if I need to change zip code representation in a data source that is read by multiple microservices?"). But this also means that we are now back into "YesSQL" territory, and specifically that we have to use a RDBMS which allows us to create Views. Goodbye NoSQL, goodbye Key+Valus datastore. (Or maybe you will just create an extra "newZipCode" and mantain it in parallel with "ZipCode" allowing every other consumer to adapt at their leisure...?). So it is another step back to "more traditional ways" to design a system... or a recipe for a disaster as soon as you start dealing with significant quantities of "state".
VBprogrammer 5y ago
IMHO Microservices done well should actually cut a whole vertical through your applications feature space. So not only should it be responsible completely for its own storage of data but it should be responsible for how that data is shown on the front end (or as close to that as you can realistically achieve). A microservice should ideally be reviews or left navigation not customer authentication or order processing.

pibi 5y ago

Clarify the microservice architecture concept with "how you are going to deploy your system", as per your example, is exactly what I'm trying to explain to my teams since the microservice architecture inception. There are too many concepts conflating into the "microservice" term: code architecture(separation of concerns), source code organization, deployment, etc. This is very confusing, which is the reason why it's now common to say that microservices are "hard".

sdevonoes 5y ago

> Developing a montolith for years but now you have written a 15 line golang http api that converts pdfs to stardust and put it into on a dedicted server in your office? welp thats a microservice. But the 15 lines of Golang are not just 15 lines of Golang in production. You need: - auth? Who can talk to your service? Perhaps ip whitelisting? - monitoring? How do you know if you service is up and running? If it's down, you need alerts as well. What if there is a memory problem (because code is not optimal)? - how do you deploy the service? Plain ansible or perhaps k8s? Just scp? Depending on your solution, how do you implement rollbacks? - what about security regarding outdated packages the Go app is using? You need to monitor it as well. And so on. The moment you need to store data that somehow needs to be in sycn with the monolith's data, everything gets more complicated. Production stuff is not just about lines of code.

jhoelzel 5y ago
no why? The task of the Microservice is to convert the pdf to stardust and to return it to its sender. so no auth. Furthermore its most likely only reachable through the local network, or at least should be if you want some stranger not to be able to also make stardust from pdfs. Monitoring: are you trying to say that its a lot esaier to pick up one logfile thant lets say 15? because they should be aggregated somewhere anyway no? Deployment: Depending on anything you listed how do i do anything? Of course if have to define it but if you want a fancy example: k8s argocd canary deployments done. I literally set it up once. security? Really? Please dont get this wrong but this feels to me like whataboutism but well here i go: i implement security just the same way as i would in the monorepo. The thing/person/entity just has to look into more repositories ;) It comes down do one sentence i think: State is not shared, state is communicated.
- comradesmith 5y ago
  For monitoring I’d also say the alerting side of things can be done via the older monolith. That is, catch exceptions and log/re-raise them as “PdfServiceException”.
- rich_sasha 5y ago

yakshaving_jgt 5y ago

> "monorepo/monolith/microservices/etc" is -just- the way you organize your code I don't think this is true. I think — at least as far as I've observed — microservices in practice means replacing various functions calls with slow and error-prone network requests. This is a big and meaningful difference.

GrumpyNl 5y ago

You need at least two teams for that.

jhoelzel 5y ago
optimally yes. The application dev does not need acces to production whatever and the devops person does not need to know how the application works. But then again these to people also need to communicate ;)

arthur_sav 5y ago

Exactly, it doesn't have to be one or the other. So far, i've been using a monolith for core functionality and microservices for independent processing tasks. That way, i can attach as much functionality as i want without bloating the main app and processing scales with demand.

baskethead 5y ago

> There is a lot of talk about monoliths vs microservices lately. Actually it's been going on for years, and it's always the same argument. People think they're thought leaders for saying "Start with monoliths and only move to microservices if you absolutely need to!" It's a pretty obvious conclusion to anyone who has worked in both environments, or have had to migrate from one to the other, so it's not particularly insightful. And yet here were are, 5+ years later saying the same thing over and over again.

hnzix 5y ago
> It's a pretty obvious conclusion to anyone who has worked in both environments, or have had to migrate from one to the other, so it's not particularly insightful. It should be obvious, but apparently it's not. So many architecture astronauts drinking the kool-aid and making a mess. Premature microservices can easily kill a product.