The main problem with microservice architecture is around orchestration. People tend to downplay the complexity involved in making sure all the services are running and talking to each other. On top of that, you have a lot of overhead in having to make endpoints and client calls along with all the security concerns where it would just be a simple function call otherwise. Finally, services often end up talking to the same database, and then you just end up with your shared state in the db which largely defeats the point.
This approach has some benefits to it. You can write different services in different languages. Different teams can be responsible for maintaining each service. The scope of the code can be kept contained reducing mental overhead. However, that has to be weighed against the downsides as well. At the end of the day, whether this is the right architecture really depends on the problem being solved, and the team solving it.
I’ve worked on projects where microservices resulted in a complete disaster and that ended up being rewritten as monoliths, and ones where splitting things up worked fairly well.
What I’ve found works best is having services that encapsulate some particular functionality that’s context free. For example, a service that can generate PDFs for reports that can be reused by a bunch of apps that can send it some Markdown and get a PDF back. Having a service bus of such services gives you a bunch of reusable components, and since they don’t have any business logic in them, you don’t have to touch them often. However, any code that deals with a particular business workflow is much better to keep all in one place.
If you have to deploy your service to test features instead of being able to test them locally while developing them then you have a really poor dev workflow.
If you don’t have a staging environment for doing integration testing of your feature in a non dev environment, you have a poor dev workflow. I never said I don’t test locally. And even then, I don’t want to run a huge monolith in my local environment if I don’t work with 90% of it.
Nowhere did I say you shouldn’t have a staging environment. However, if you can develop and test changes locally then by the time it goes to staging, the code should already be in good shape most of the time. Staging is like your guardrail, it shouldn’t be part of your main dev loop.
Meanwhile, not sure what the issue is with running a monolith locally. The reality is that even large applications aren’t actually that big in absolute terms. Having to run a bunch of services locally to test things end to end is certainly not any easier either.
The main problem with microservice architecture is around orchestration. People tend to downplay the complexity involved in making sure all the services are running and talking to each other. On top of that, you have a lot of overhead in having to make endpoints and client calls along with all the security concerns where it would just be a simple function call otherwise. Finally, services often end up talking to the same database, and then you just end up with your shared state in the db which largely defeats the point.
This approach has some benefits to it. You can write different services in different languages. Different teams can be responsible for maintaining each service. The scope of the code can be kept contained reducing mental overhead. However, that has to be weighed against the downsides as well. At the end of the day, whether this is the right architecture really depends on the problem being solved, and the team solving it.
I’ve worked on projects where microservices resulted in a complete disaster and that ended up being rewritten as monoliths, and ones where splitting things up worked fairly well.
What I’ve found works best is having services that encapsulate some particular functionality that’s context free. For example, a service that can generate PDFs for reports that can be reused by a bunch of apps that can send it some Markdown and get a PDF back. Having a service bus of such services gives you a bunch of reusable components, and since they don’t have any business logic in them, you don’t have to touch them often. However, any code that deals with a particular business workflow is much better to keep all in one place.
And the dev experience IMO is much better. I don’t have to deploy a huge ass service to test a tiny feature.
If you have to deploy your service to test features instead of being able to test them locally while developing them then you have a really poor dev workflow.
If you don’t have a staging environment for doing integration testing of your feature in a non dev environment, you have a poor dev workflow. I never said I don’t test locally. And even then, I don’t want to run a huge monolith in my local environment if I don’t work with 90% of it.
Nowhere did I say you shouldn’t have a staging environment. However, if you can develop and test changes locally then by the time it goes to staging, the code should already be in good shape most of the time. Staging is like your guardrail, it shouldn’t be part of your main dev loop.
Meanwhile, not sure what the issue is with running a monolith locally. The reality is that even large applications aren’t actually that big in absolute terms. Having to run a bunch of services locally to test things end to end is certainly not any easier either.
If you need to run a bunch of services locally manually, then you’re doing it wrong
Do tell how you do end to end testing without running services locally.