There’s also a product-related argument here as well. In order to start, most products require a lot of scaffolding—-modeling of business entities, general rw apis etc. These are well represented by the big “monolithic” frameworks like Rails or Django. There’s not a lot of value in developing a proprietary distributed paradigm for these. Having this core taken care of and flexible, then allows It’s devs to build more proprietary functionalities as distributed proprietary services. Building this core backbone for access to basic funtionalities, and then distributing the high-value technologies has been the recipe for many things I’ve built.
Don't start with microservices – monoliths are your friend
231–240 of 468 posts
Re: Don't start with microservices – monoliths are your friend
#232Monolith and Micro-services at different times during the progression of a business can have their places. I have experienced the pains of having to work with both within the same company over 9+ years and here is what I think are forces that can pull you in either direction. A monolith makes developing initially a lot easier. Over 15 years though, you are bound to have developers of various calibre leave their mark…
> Eventually, your team will flip the table and start thinking how to avoid the problems they are having with the monolith and decide to do down the micro-services way.
So, yet another comment saying that modularity requires a distributed system.
Re: Don't start with microservices – monoliths are your friend
#233I wonder why no one ever talks about architectures in the middle between those two - modular monoliths. The point in time where you're splitting your codebase up in modules (or maybe are a proponent of hexagonal architecture and have designed it that way from the beginning), leading to being able to put functionality behind feature flags. That way, you can still run it either as a single instance monolith, or a set o…
> I wonder why no one ever talks about architectures in the middle between those two - modular monoliths.
I'm sure that if you look at the source code of existing monoliths, you will find heavy use of modules.
Re: Don't start with microservices – monoliths are your friend
#234Unless you have a strong technical or organizational reason to use microservices, using microservices is just more work to achieve the same results. Organizational reason would be multiple people/teams who don't want or can't talk much to each other, so they develop pieces of a larger system as relatively independent projects, with clear API and responsibility boundaries. Frontend/backend style web development is an…
> no good reason How about deployment speed? If I’ve got a microservice collecting events off a queue and writing a csv out to S3 on a schedule, it’s really nice to be able to add a column and deploy in minutes without having to rebuild and deploy a giant monolith. It also allows for fine grained permissions: that service can only read from that specific queue and write to that specific bucket. People throw around “d…
> deploy in minutes without having to rebuild and deploy a giant monolith
that's a tooling issue not a monolith vs microservice issue.
tooling can allow the exact same speed of deployment for tiny background processing without the need to completely segment your code base.
Re: Don't start with microservices – monoliths are your friend
#235Earlier quoted context omitted.
I would say this is another problem. If an external call to a web service is involved, then you can NEVER have an atomic call in the first place. One always needs to just have a state machine to navigate these cases. Even with a monolith, what if you have a power-off at the wrong moment? What you are describing here is to me pretty much the job description of a backend programmer to me -- think through and prepare fo…
Well that's the thing isn't it. As soon as you move away from the atomicity of a relational database you can't guarantee anything. And then we, like you do to, resort to cleanup jobs everywhere trying to rectify problems. I think that's one of the things people rarely think of when moving to microservices. Just how much effort needs to be made to rectify errors.
> you can't guarantee anything
You can always guarantee atomicity. You will just have to implement it yourself (what is not easy, but always possible, unless there are conflicting requisites of performance and network distribution).
And yes, the cleanup jobs are part of how you implement it. But you shouldn't be "trying to rectify the problems", you should be rectifying the problems, with certainty.
Re: Don't start with microservices – monoliths are your friend
#236Re: Don't start with microservices – monoliths are your friend
#237I think starting with a decently written monolith is a great idea, the two things that I always saw that _make things bad_ (fsu) are auth, encapsulation (with no domain boundaries, typically 1 class with lots of responsibilities that are only useful in specific contexts but depend on common data and are hard to refactor, classic 3k lines of python code for the User class) and ORMs.
Often these things (auth and orm) are pushed by frameworks and don't scale well because of the magic they use to make things work.
I think today if i had to start from scratch would use lambdas as much as possible for all common external facing logic (auth etc) and GET routes (for scalability) and have a monolith (with very simple orm features) that implements business logic on top of a managed db (like a dynamodb or aurora). somewhere in the comment I have seen elixir being mentioned and I really like the approach elixir (and phoenix) have over organizing the domains in a monolith, together with a little reactive approach and of course optimize for deletion https://www.netlify.com/blog/2020/10/28/optimize-for-deletio...
Re: Don't start with microservices – monoliths are your friend
#238I wonder why no one ever talks about architectures in the middle between those two - modular monoliths. The point in time where you're splitting your codebase up in modules (or maybe are a proponent of hexagonal architecture and have designed it that way from the beginning), leading to being able to put functionality behind feature flags. That way, you can still run it either as a single instance monolith, or a set o…
Because there is no newly invented architecture called "modular monolith" - monolith was always supposed to be MODULAR from the start. Micro services were not an answer to monolith being bad. Something somewhere went really wrong with people's understanding and there is bunch of totally wrong ideas. That is also maybe because a lot of people did not knew they were supposed to make modules in their code and loads of m…
> monolith was always supposed to be MODULAR from the start
Well, that certainly is sensible, but I wasn't aware that someone had to invent the monolith and define how far it should go.
Alas, my impression is that the term "monolith" doesn't really refer to a pattern or format someone is deliberately aiming for in most cases, but instead refers to one big execution of a lot of code that is doing far more than it should have the responsibility to handle or is reasonable for one repository to manage.
I wish these sorts of battles would just go away, though, because it's not like micro services are actually bad, or even monoliths depending on the situation. They're just different sides of the same coin. A monolith results from not a lot of care for the future of the code and how it's going to be scaled or reused, and micro services are often written because of too much premature optimization.
Most things should be a "modular monolith". In fact I think most things should start out as modular monoliths inside monorepos, and then anything that needs to be split out into its own separate library or microservice can be made so later on.
Re: Don't start with microservices – monoliths are your friend
#239Unless you have a strong technical or organizational reason to use microservices, using microservices is just more work to achieve the same results. Organizational reason would be multiple people/teams who don't want or can't talk much to each other, so they develop pieces of a larger system as relatively independent projects, with clear API and responsibility boundaries. Frontend/backend style web development is an…
> no good reason How about deployment speed? If I’ve got a microservice collecting events off a queue and writing a csv out to S3 on a schedule, it’s really nice to be able to add a column and deploy in minutes without having to rebuild and deploy a giant monolith. It also allows for fine grained permissions: that service can only read from that specific queue and write to that specific bucket. People throw around “d…
Why not...
> branch from whatever branch is in prod
> implement change on that branch (in this case adding a column), test
> deploy to prod
I realize the build and deployment process may be more complex than that making it hard... but it doesn't have to be.
I agree that a microservice OR even another system (a collection of services) is a good solution if you need to make quick iterative changes, and you can't do so with your current system.
Re: Don't start with microservices – monoliths are your friend
#240Earlier quoted context omitted.
> ...then don't spend hundreds of thousands on infrastructure. I find it curious how we went from doing the basics of software development that would minimize risks and be helpful to almost any project out there to this. To clarify, i agree with the point that you'll need to prioritize different components based on what matters the most, but i don't think that you can't have a common standard set of tools and practic…
There are plenty of solutions to authentication. But really, don't implement a user system if it is not needed. There are plenty of other ways to secure on applications, which are way out of scope for this discussion. The main point is, that one should never spend a "a few days to a week" to implement a feature that at best i useless and at worst is detrimental to the service stood up. Implement auth, if it is needed…
I feel like "spaghetti garbage now, we'll fix it later" is a big part of why startups fail to execute well. Yeah you saved $8000 by launching your thing in a completely unmaintainable way, but now it's both harder to maintain and more likely to need it. Literally the first time it breaks you will probably lose that cost advantage just because it takes so long to debug.
The point you should have made is that dogmatic approaches usually produce a lot of waste, but the example you gave us exactly why teams end up that way. Otherwise people come up with bullshit hacks like you describe and the entire team pays for it.