61–70 of 356 posts
Requirements should dictate architecture. Data should dictate the model. Avoid unnecessary work. Be mindful of over-engineering.
I worked on a project that was a monolith. A team was placed to rewrite it to microservices and shortly after I quit that job. About a year after that I ate lunch with a ex-colleague that told me they were still working on that rewrite. Looking at the page now it looks like the monolith is still running as far as I can see, about 5 years later. I guess they gave up. :)
A more common scenario I see is that people start with a monolith that ends up inheriting all the conceptual debt that accumulates as a project evolves. All this debt builds up a great desire for change in the maintaining team. A champion will rise with a clean architecture and design in microservice form that addresses all high visibility pain points, attributing forecasted benefits to the perceived strengths of mic…
There is one approach Fowler suggested is SacrificialArchitecture. You build your monolith quickly, get to market fit and once you understand service boundaries you move to microservices. Personally I would like to try Umbrella Projects[1]. You can design it as microservices but deploy and build as monolith. Overhead is lower, and it is easier to figure out right services when in one codebase. It can be easy implemen…
Earlier quoted context omitted.
Here is the thing, whatever you write doesn't work without linking, so no we never moved away from it.
But is linking the right way to couple business logic from two different organisational units? That is the question being discussed.
I think it's not, but I would like to hear other opinions.
Earlier quoted context omitted.
You can still build a "monolith" but in a very modular way. Can't scale independently like microservices, but what if you don't need scale! Compile times are higher but what if you don't need to compile that much code! One error can bring down all "monolith services" but what if your app is not that big! I'd wager, something like 90% of software projects in companies can just get by with monoliths. You know...there a…
>Can't scale independently like microservices, but what if you don't need scale! What do you mean? Aside from deployed codebase, I don't quite see it - if you need memory, allocate - start small/empty for any datastructure. If managed/gc setup delallocating is inherent, so no special case about freeing memory. Don't create unnecessary threads - but even then dormant threads are very cheap nowadays. There you go - it…
If you imagine a monolith as a service that: takes a request -> deserializes it/unpacks it to a function call -> sets up the context of the function call (is the user logged in etc) -> calls the business logic function with the appropriate context and request parameters -> eventually sends requests to downstream servers/data stores to manipulate state -> handles errors/success -> formats a response and returns it The…
This just seems like a poorly (or not at all?) designed monolith, if there's no standard way of doing things, of concerns or responsibilities of various application layers? I mean I've been there too in organizations, but it just seems like we're skirting around the obvious: the system should've had a better architect (or team) in charge?
A more common scenario I see is that people start with a monolith that ends up inheriting all the conceptual debt that accumulates as a project evolves. All this debt builds up a great desire for change in the maintaining team. A champion will rise with a clean architecture and design in microservice form that addresses all high visibility pain points, attributing forecasted benefits to the perceived strengths of mic…
There is one approach Fowler suggested is SacrificialArchitecture. You build your monolith quickly, get to market fit and once you understand service boundaries you move to microservices. Personally I would like to try Umbrella Projects[1]. You can design it as microservices but deploy and build as monolith. Overhead is lower, and it is easier to figure out right services when in one codebase. It can be easy implemen…
AFAIK, we haven't actually split out anything yet after all these years. All of our scale issues have been related to rather lackadaisical DB design within services (such as too much data and using a single table for far too many different purposes), something an arbitrary HTTP barrier erected between services would not have helped with at all.
Earlier quoted context omitted.
There is one approach Fowler suggested is SacrificialArchitecture. You build your monolith quickly, get to market fit and once you understand service boundaries you move to microservices. Personally I would like to try Umbrella Projects[1]. You can design it as microservices but deploy and build as monolith. Overhead is lower, and it is easier to figure out right services when in one codebase. It can be easy implemen…
That's what my company has done. We have a microservice-like architecture, but discourage dependencies on other services. If we need to use one service in another, we use dependency injection (which allows us to switch out the communication protocol later if need be) or talk over a message bus instead. The idea was that we would figure out later which sub-services actually need to be split out based on usage. AFAIK,…
You start out as technically a monolith, but that is prepared at all times to be decomposed into services, if and when the need arises.
It's nothing too fancy - can be simply another name for Hexagonal Architecture, functional-core-imperative-shell, etc.