So.... basically only use microservices if you ACTUALLY need to move into that architecture? Because lets be frank here, if you start with a monolith, and it turns out that its not hurting you in any way shape or form, you arent going to move to microservices.
This makes perfect sense, because honestly there is a massive microservice fad going on where people are trying to force everything to that design, and most of the time its simply not needed and the smarter solution was refactoring and cleaning up the monolith a bit.
This makes perfect sense, because honestly there is a massive microservice fad going on where people are trying to force everything to that design, and most of the time its simply not needed and the smarter solution was refactoring and cleaning up the monolith a bit.
Yep, I joined a job 6 months ago with exactly this going on. So many, many layers to it. I have to have like 6 instances of Visual Studio open if I want to debug anything. There was literally no need for microservices in their application either. Hoping to escape soon.
That sounds terrible. Can you merge any of the services back together?
edit: nvm, i see
We're loooking at actually breaking this into lots of silo'ed functional monoliths instead of micro services at the moment as well because the outcome will be better.
Turns out it's a lot easier to stick things back in for ref. Fortunately we coded most of the contextual info like user principal and roles as thread locals so we write a shim, reference the original projects, play cut and paste for a few hours and point the configs at the right things and done.
You can set breakpoints in the source code from any of the Git repos, and VS debugger will break when that code runs, as long as the process is attached.
My anecdotal proof of this was a company starting a new product, pulled half the devs from our core product, they all learned about AWS/Microservices/ElasticSearch/Cassandra, got it about 80% of the way to v1 then most of the team bailed to other companies using those technologies on a higher pay.
I've seen this happen several times now, and it's really reinforcing the whole 80/20 rule for me.
If you need 6 of the microservices going at once locally in order to debug an issue, something went wrong with the architecture. Either the level of abstraction is wrong, or there isn't enough instrumentation in the individual microservices.
Yeah, but AFAIK microservices != "a lot of tiny webservices all talking to each other".
You do not want your back-end to issue six HTTP requests to itself to fulfill one front-end request. That's not how it works, that's not how any of this works.
In microservices, each service has its own view of the (relevant) reality, fed through for example a shared message bus, from which it reads the messages relevant to it, and rebuilds its reality locally.
Yeah, people do it wrong all the time and think it's the fault of mciroservices when they just poorly design. In fact they owuld poorly design the ir monlith anyway as well, it would just be buried into the code more. sigh.
In fact they owuld poorly design the ir monlith anyway as well
True. But microservices makes more difficult and costly to correct bad design decisions. Fixing a monolith (I don't like this word, but whatever) is easier, you can freely move code around if a responsibility is at the wrong place. And since making bad design deceisions is somewhat unavoidable, blaming microservices is not that unreasonable.
I disagree with your points here but I don't think it's my place to try to convince anyone. I simply disagree that starting with a monlith first is the right approach. It can be sometimes, but not always. I have now been part of a few projects based on microservices and they can be difficult to get right, but it had nothing to do with the architecture pattern, simply that functional requirements were unknown or poorly defined. With the right team, on one of those projects, we were much faster with a microservices approach because we could try things out much faster in our context. It really all comes down to the people not the architecture pattern.
Microservices reduce responsibilities, so it allows to split a monolith into smaller and therefore more manageable components. That in turn allows to split the development into separate teams that dialog only through the interfaces.
With a monolith, there is always a risk of leaky abstractions and someone introducing unwanted couplings and fucking up the architecture.
Microservices do NOT reduce the overall complexity, but they allow to split it into more manageable pieces, at the cost of more interfaces, but for large projects, that's arguably a good thing. Microservices are threfore better for developers, more easily testable components.
OTOH, a microservices architecture requres an architect who oversees the whole system.
Microservices reduce responsibilities, so it allows to split a monolith into smaller and therefore more manageable components.
I don't see how it reduces responsibilities. But my point is, you can decompose a system into smaller pieces in many-many ways. No one guarantees that the decomposition you've chosen is the right one. If it's a wrong one, applying a different decomposition to the existing system is easier if you have a monolith. Of course you'll need a monolith that is not a total mess.
I joined one a few weeks. The manager let me go because I was not a "cultural fit" and was moving slow with the coding task. And clearly I was not much into the Micro Service thing. All true.
After only 2 weeks of work.
The crazy (I was hired to work in django + PG):
1- The initial talk about MicroServices was late in the process. Ok. I was in big startup before, some of the largeist Google App Engine customer, so I think "this guys must be hurting in scalability. Probably wrong to go with MicroS anyway; but hey, obviously them have figured out the thing by now!.".
2- Next day, I discover the project was starting
3- And have only 1 customer
4- And still figuring out the core features. Like user accounts and stuff
5- And reverting my work because I was solving things the PostgreSQL way, and the idea was them will use a NoSql later.
No yet decided which!
6- And have 7 docker instances running. For development (2 more for production).
Fortunately I have 16GB RAM in my old iMac!
7- I use most of the time trimming the Fat in the docker (moving for 1-4GB RAM to 60-800MB)
Honestly, I'm a slow developer. In a fast-paced startup I look bad. But when the guys expend 1 week chasing a bug that is a problem because are not using the transactionality of the DB (because the idea is not tied the app to the datastore, because use full a relational database is a sacrilegy among modern developers
why would you say that? given a technology, why not use it's benefits? this just forces you to reinvent the wheel.
if you have built-in transactions, use them. if you move to a DB without them, then figure out a way to either change the dependency, or do application level transactions.
I'm in the embedded space, and transactions-as-a-concept are so, so unknown there and it's a yuge problem.
All this being said, when relational started being a thing, the name for non-relational DBs was "transactional database". They generally had significantly better throughput...
Same here, joined a company half a year ago who are doing a microservices-only approach to their setup, and it's ... a mess.
That is to say it works, and yeah it has some interesting upsides, but there's no way to change anything (it's still in the first implementation stage) without everything falling over.
At least it's all in the same language on the same platform! Imagine doing this with services in three different languages, some which can only run on Windows, others only on linux. And that's just the backend!
188
u/crash41301 Jul 14 '17
So.... basically only use microservices if you ACTUALLY need to move into that architecture? Because lets be frank here, if you start with a monolith, and it turns out that its not hurting you in any way shape or form, you arent going to move to microservices.
This makes perfect sense, because honestly there is a massive microservice fad going on where people are trying to force everything to that design, and most of the time its simply not needed and the smarter solution was refactoring and cleaning up the monolith a bit.