101–110 of 154 posts
Earlier quoted context omitted.
You are not getting more reusability from a bunch of microservices, compared to one big service, I don't see where you got that?
I also don't see how microservices are more reusable. However, the replacability is usually much better due to being forced to define sharp boundaries with clear interfaces.
Luckily, I've had to redo one logical part of the monolith anyway, because of some changing business requirements. So I made it a separate independent project, that had used all the modern currently-stable tech (rather than few-years-old one + accumulated baggage of the past architectural mistakes) and it all went quite nicely.
It took me 1.5 weeks (quite busy ones, but meh) to extract all the old code pieces that I've needed, clean them up, update with the new logic, and get the freshly-minted project ready, tested, packaged up and running in production. The only thing I've lost is ability to run cross-db queries (we just have a folder of read-only SQL query snippets to fetch some useful statistics once a week or so), because I put the data in a separate database. I hope, postgres_fdw would work when I'll need it.
Would I've tried to update the whole monolith, it would've taken me months.
So, the next time I'll work on some large-enough part, I'll probably extract it into a fresh project as well. As I see it, I'll end up with a remains of legacy project surrounded by a few small(er) monoliths. And then the legacy piece would be small enough to get cleaned up.
(I don't know about micro- scale and putting every tiny thing into a different microservice, though. I have an impression it requires a lot of extra unwanted cognitive load to manage so seems like an overkill to me.)
So, my point is: software (code) rots over time. Multiple projects (services) allow to update pieces at different pace, which is less stressful on developers.
My experience with microservices has been pretty painful. My analogy of microservices is it's a bit like building a car factory on two sides of the Danube. And there's no phone line in between. You've got a factory building cars up to a certain point, but then they have to stop work and pack it all up onto a barge, figure out how to fit everything on the barge and send it away across the river for the other side to spend time unpacking & figure out how it all fits together...
As a django guy, I've tended to follow the pattern of spending time making my models nice and rich, with useful traits which will be helpful at all levels of the app down to the views. To then have to pack this all up and deliver some "dumb" json to the other side feels like a massive waste of time. With microservices I spend my life marshalling data around.
And the number of times I've realized I've just spent an hour discussing the philosophical implications of how a particular bit of the rest interface should be designed, all for an interface that we're the only consumers of and doesn't need to exist in the first place... I've found depressing.
The ramifications on testing are a further story. Do you have to test all kinds of ways you can receive your rest requests malformed if you're the only consumer and know exactly how you're going to use it? Good use of developer time?
Equating "Microservices" with "Information Superhighway" really shows the tech bubble that this article is written in. "Information Superhighway" was a vacuous but mainstream term used by politicians and public figures. "Microservices" is a tech hype train led by expensive consultants and pickaxe companies thriving off the current tech boom. Don't get me wrong, a service-oriented architecture is the only thing that s…
Speaking as a young engineer, I can tell you many are already looking past microservices towards things like AWS Lambda, AMQs, and BaaS, which make a great deal more sense. Why? Because it helps reduce dev effort down to purely the logic you'd have to write no matter what, with better guarantees about reliability and scalability, and less maintenance. I hesitate to say 'serverless' because that still feels somewhat o…
Has local dev/testing been solved for that yet, and different environments, etc?
Earlier quoted context omitted.
You say it as if it's a bad thing... Compared to the alternative, fiefdoms really are a wonderful thing! I once work for a giant fortune 500 corporation. Our department had a good 300 developers, and had been writing code for years. They had built the whose system using the classic, box-box-cylinder architecture. There were hundreds of little top tier 'services', but in practice, they all shared the same database, ha…
I really value your contribution, thanks for sharing. I give the proponents/consultants credit for proposing a practical and incremental solution to these people instead of just insulting them or saying "you're doing it wrong". That being said, the issue I have with microservices is the fact that the below is repeatedly used as a core technical argument : > They had built the whose system using the classic, box-box-c…
Earlier quoted context omitted.
> This. What happened to "make it work then make it scale" ? The fact that it is wrong (or rather, incomplete) It should be "make it work with a clear path to scaling, then make it scale" - that's true with respect to both software engineering and business plans. It's the same with "premature optimization is [the|a root of [all]] evil" - Premature optimization is a waste of time and often paints you into a corner. Ho…
Not my experience at all. Systems that were designed as simply as possible can be unpicked and made scalable - it takes time and effort but it's doable. Systems that were designed to be scalable are much worse, because you have to undo all of that work first before you can start actually making them scalable.
And, honestly, sometimes you've done variants of the same problem enough that you know where some of the bottlenecks are inevitably going to be - so why not design them out right at the start?
Equating "Microservices" with "Information Superhighway" really shows the tech bubble that this article is written in. "Information Superhighway" was a vacuous but mainstream term used by politicians and public figures. "Microservices" is a tech hype train led by expensive consultants and pickaxe companies thriving off the current tech boom. Don't get me wrong, a service-oriented architecture is the only thing that s…
Speaking as a young engineer, I can tell you many are already looking past microservices towards things like AWS Lambda, AMQs, and BaaS, which make a great deal more sense. Why? Because it helps reduce dev effort down to purely the logic you'd have to write no matter what, with better guarantees about reliability and scalability, and less maintenance. I hesitate to say 'serverless' because that still feels somewhat o…
In this case, they really pay off if they are separated well which sometimes is hard. But executed well, it allows to keep moving quickly as the requirements grow. Of course, this is not an excuse to avoid refactoring monolithic application, improving testing, etc.
I've worked in such a setting in companies, and both times it was a win and helped to build important to the business features really quickly and reliably.
But is it worth to write an application from scratch in a service oriented architecture? Probably not, most of the time. Especially if 'product to market time', 'MVP' and similar concepts are very important for you.
I'll tell you the real reason behind microservices: developer fiefdoms. "Faux-Specialization". It allows developers to feel like they have control over certain pieces of infrastructure and run the gambit on their strategy for getting ever more increasing pieces of the pie. It has nothing to do with building reliable software. You could just as easily build and deploy a single networked application (so called "monolit…
Any organization that designs a system ... will inevitably produce a design whose structure is a copy of the organization's communication structure — M. Conway
I'll tell you the real reason behind microservices: developer fiefdoms. "Faux-Specialization". It allows developers to feel like they have control over certain pieces of infrastructure and run the gambit on their strategy for getting ever more increasing pieces of the pie. It has nothing to do with building reliable software. You could just as easily build and deploy a single networked application (so called "monolit…