I have long running ruby and java apps that I use for this purpose. They have build scripts, test frameworks, etc. When I get an idea for something new I add them to one of these existing projects, but I do it in a way that I can easily excise it in the future.
Build the Modular Monolith First
21–30 of 90 posts
Re: Build the Modular Monolith First
#22And then on it because you most likely part of a project that will never have any requirement that needs anything else.
Re: Build the Modular Monolith First
#23This is written like it's a novel take bucking the trend, but I feel like most things I have seen on this topic for at least several years now have the same observations and conclusions? If anyone wants to actually speak up for microservices, I feel like that's what needs a defense at this point!
Microservices to me are solving two problems: an organizational problem and a technical problem. The organizational problem is more obvious: well-factored monolithic codebases go poorly with large, interdependent groups of teams. The technical problem is that while it’s true that you can write a monolith in a modular style, in my experience enforcing the single responsibility principle in a monolith demands a level o…
Wholeheartedly agree, I also feel like people are overestimating how much discipline you can collectively have in an organization. And if you create a monolith with hard-enough boundaries to enforce modularization then you might as well create multiple services (and not necessarily the one-microservice-per-entity kind of architectures, just as many as the modules)
Re: Build the Modular Monolith First
#24Any team starting with microservices on an unvalidated concept likely hasn't built a big project from the ground up before If it's a small engineering team there is nothing more optimal than working on a big scappy vertical codebase in the early stages In the fortunate situation you need to start scaling -- breaking that out into MS later is usually low effort and fun If you break it up to early you often end up with…
> breaking that out into MS later is usually low effort and fun
In my experience, breaking down 5+ year old / multiteam monoliths has always been painful, frustrating, and required huge efforts, especially when nobody remembers why certain things are the way they are. In addition, getting enough support for business to do it was hard. I really find it quite surprising to hear someone share the opposite opinion and wonder what kind of environment and the size of the project you were in.
Re: Build the Modular Monolith First
#25The issue is not microservice is complicated. It's about CI/CD complexity.
Re: Build the Modular Monolith First
#26I have long running ruby and java apps that I use for this purpose. They have build scripts, test frameworks, etc. When I get an idea for something new I add them to one of these existing projects, but I do it in a way that I can easily excise it in the future.
Megalith!
Re: Build the Modular Monolith First
#27I have long running ruby and java apps that I use for this purpose. They have build scripts, test frameworks, etc. When I get an idea for something new I add them to one of these existing projects, but I do it in a way that I can easily excise it in the future.
Curious to hear more. Are these personal projects or serving users? What are some examples of unrelated ideas you’ve tacked on to existing app servers?
Re: Build the Modular Monolith First
#28Any team starting with microservices on an unvalidated concept likely hasn't built a big project from the ground up before If it's a small engineering team there is nothing more optimal than working on a big scappy vertical codebase in the early stages In the fortunate situation you need to start scaling -- breaking that out into MS later is usually low effort and fun If you break it up to early you often end up with…
> breaking that out into MS later is usually low effort and fun In my experience, breaking down 5+ year old / multiteam monoliths has always been painful, frustrating, and required huge efforts, especially when nobody remembers why certain things are the way they are. In addition, getting enough support for business to do it was hard. I really find it quite surprising to hear someone share the opposite opinion and wo…
100% agreed there. I've never seen this go smoothly, and usually the monolith lives forever, slowly shedding functionality but never quite disappearing.
Re: Build the Modular Monolith First
#29The whole monolith vs microservice discussion revolves around a false dichotomy and higly subjective and context-dependend definitions. For example, what if a monolith is integrated into a larger system landscape (e.g. due to an enterprise merger). Is it still a monolith?
Re: Build the Modular Monolith First
#30This is written like it's a novel take bucking the trend, but I feel like most things I have seen on this topic for at least several years now have the same observations and conclusions? If anyone wants to actually speak up for microservices, I feel like that's what needs a defense at this point!
I think anyone who has taken a large monolith through a significant platform version upgrade or change, like .NET 2 to .NET 4, or Python2 to Python3, or Angular to React, would need a very persuasive argument to make them believe that starting a new project with a monolithic design was a good idea.