Monoliths Are the Future
changelog.com
Monoliths Are the Future
1–10 of 567 posts
Re: Monoliths Are the Future
#2It's okay to ship a bunch of services together, if you can be serious about keeping hard boundaries between subsystems. Microservices force you to do this (e.g., your microservices might have to communicate via REST APIs, but they can't access eachother's internal implementation details).
Your customers do not care about your monolith. They don't see a monolith; all they see is features. Untangling it may or may not be the right choice.
In a certain set of situations, the path forward, instead of trying to untangle your monolith is --if you so desire-- create new services actually be true microservices, and keep your monolith as-is.
Re: Monoliths Are the Future
#3Designing an application from scratch where pure microservices is implemented is in my opinion the same as over
engineering possible future performance issues.
Splitting up your application in many services requires a lot of thinking and designing. Challenges with syncing, communication etc are not always easy to deal with.
That's why I agree to start as a monolith but with architectural principles to still have multi modules/components. But I would for example never split up the database in multiple.
Re: Monoliths Are the Future
#4One thing a microservice architecture does really well is enforce bounded contexts. Oh you want to access that data? Well you need to go through the public API because it exists in a separate process. In a monolith it's all too easy to just 'call this piece of code and grab what I need' (no one will ever know). Project isolation can help but it's not a silver bullet.
The author makes good points though, there are many places doing microservices because it's the hip thing to do and a monolith would easily suffice. But if you have independent software teams in your org that should be able to deploy code independently, then microservices makes a lot of sense.
As in all things engineering - it depends :)
Re: Monoliths Are the Future
#5If you’re choosing to hop the network as a means of decoupling code that’s absurd because you can decouple much more cheaply with PL and build facilities — without introducing a network hop.
But there are problems that justify a service. Decoupling code is just not one of those problems.
Re: Monoliths Are the Future
#6I think the underlying point, as expressed by the author, is that trendy new architecture patterns will never be a panacea for bad engineering, though that's often how they're implicitly sold as ideas.
Re: Monoliths Are the Future
#7Obligatory mention that services are mostly an enabler for organizational scaling and, in my opinion, shouldn't generally be something considered for only technical reasons. Having hundreds of engineers working on a monolith is at least as challenging as having ten engineers working on ten separate services.
There is also a clear distinction, in my mind, between microservices philosophy and 'macroservices', as I call it. Buying into a system with more services running than engineers is very different than having a number of teams, each working on their own single or handful of services.
I would argue that the organizational scaling derived from microservices resembles diminishing returns somewhere in the domain between a single service (monolith) and more services than engineers (microservices).
Re: Monoliths Are the Future
#8I'm a database guy, so the question I get from clients is, "We're thinking about breaking up our monolith into a bunch of microservices, and we want to use best-of-breed persistence layers for each microservice. Some data belongs in Postgres, some in DynamoDB, some in JSON files. Now, how do we do reporting?"
Analysts expect to be able to connect to one system, see their data, and write queries for it. They were never brought into the microservices strategy, and now they're stumped as to how they're supposed to quickly get data out to answer business questions or show customers stuff on a dashboard.
The only answers I've seen so far are either to build really complex/expensive reporting systems that pull data from every source in real time, or do extract/transform/load (ETL) processes like data warehouses do (in which the reporting data lags behind the source systems and doesn't have all the tables), or try to build real time replication to a central database - at which point, you're right back to a monolith.
Reporting on a bunch of different databases is a hard nut to crack.
Re: Monoliths Are the Future
#9Maybe the title should be “Bad Engineering is the Future”.
Re: Monoliths Are the Future
#10The author does not seem to understand when to correctly apply microservices. There are two basic use cases: 1) Different parts of your solution have different load patterns and it is economically beneficial to scale them at different rates and 2) Different teams need to be able to work & ship autonomously. It's not at all about technical merits or architectural beauty. It's about people and costs.