My two cents would be that tooling makes all the difference with microservices, especially in terms of developer productivity. Having tooling which allows me to test changes to a microservice locally and easily is a huge win, and without that tooling microservice development becomes much more difficult. Making it easy to test a service locally -- including its network interactions -- lets me be more confident that my code will work in production and reduces a lot of the cognitive overhead of developing one component among thousands.
The Death of Microservice Madness in 2018
201–210 of 469 posts
Re: The Death of Microservice Madness in 2018
#202I think "microservices" is so appealing because so many Developers love the idea of tearing down the "old" (written >12 months ago), "crusty" (using a language they don't like/isn't in vogue) and "bloated" (using a pattern/model they don't agree with) "monolith" and turning it into a swarm of microservices. As an Infrastructure guy, the pattern I've seen time and time again is Developers thinking the previous generat…
To put it in an even less flattening way, the real problem are developers, not the paradigm. Your company's code will be as good as your developers are regardless of the paradigm. Microservices will not help you if your developers have the same level of skill and foresight as whoever wrote the monolith, which is probably true if those devs were selected by the same hiring process that your company has today, subject…
"Your company's code will be as good as your developers" as good as your companies nn% of worst developers
Re: The Death of Microservice Madness in 2018
#203Earlier quoted context omitted.
Those of us who have been around since the 80s-90s are astonished by the low productivity of today's programmers. If it takes 1 person to run 1 microservice, we are all doomed.
You really think that the productivity of today's programmers is less? What evidence and data do you have for that?
Warning: all anecdotes. While I don't think that productivity has decreased, what was notepad, a compiler, some dlls and a debugger before turned into a thousand little packages, several configuration files, a bunch of servers you have to run on your dev. computer, which is also 10x more capable, yet everything feels so sluggish.
I also feel that ceteris paribus, the meetings got longer, project management tools now consume a lot of input from programmers, and I need to communicate with a lot more people to get something done.
Re: The Death of Microservice Madness in 2018
#204Microservices (in practice) are like polyglot: throwing away type safety for no good reason. This shit needs to stop.
You don't have to use JSON-over-HTTP. You can use something like Thrift or Protobuf which gives you statically-typed inter-process communication.
Re: The Death of Microservice Madness in 2018
#205I think "microservices" is so appealing because so many Developers love the idea of tearing down the "old" (written >12 months ago), "crusty" (using a language they don't like/isn't in vogue) and "bloated" (using a pattern/model they don't agree with) "monolith" and turning it into a swarm of microservices. As an Infrastructure guy, the pattern I've seen time and time again is Developers thinking the previous generat…
I call this the painting problem. Painting the walls of a room seems easy to an amateur: You just buy a few gallons at Home Depot and slap it on. But a professional knows that prep, trim, and cleanup are 80% of the job and they take skill. Anybody can slap paint onto the middle of a wall. What's difficult and time-consuming are making the edges sharp and keeping paint off the damn carpet.
So you are saying edge and corner cases are the most difficult?
Re: The Death of Microservice Madness in 2018
#206Earlier quoted context omitted.
I downvoted because without context this just seems like the typical know-it-all statement from someone who has yet to realize how little they really know. There's no attempt to even try to appreciate how their situation may be different, just the default disdain so typical from some professionals incapable of thinking outside of their own perspective.
I think he is literally asking for the other perspective? "I run 8 services myself" can be read as arrogant, OR it can be read as "I do things very differently", which is how I read it initially.
That’s how I meant it, that the advantage of microservices is bite size pieces of work, so 10 people on the same service sounds like they’d step on each other’s toes. I run a bunch of services but they’re each debugged enough to be fairly low maintenance and small enough that the edges are well defined.
It’s 8 or so but it’s possible for me to handle it all. If we add features they’re going to be new services, so adding big features to the services I manage is unlikely. It is more likely that I get a new service on my plate in 6 months time than getting additional members of the engineering team to work on already completed services.
I’m obviously not entirely alone... I’ll ask for help if I need it, and I help out with other people’s stuff too, but I am primarily in charge of them and I am responsible for keeping everything working well.
Re: The Death of Microservice Madness in 2018
#207Earlier quoted context omitted.
You really think that the productivity of today's programmers is less? What evidence and data do you have for that?
Warning: all anecdotes. While I don't think that productivity has decreased, what was notepad, a compiler, some dlls and a debugger before turned into a thousand little packages, several configuration files, a bunch of servers you have to run on your dev. computer, which is also 10x more capable, yet everything feels so sluggish. I also feel that ceteris paribus, the meetings got longer, project management tools now…
Sounds for me like productivity went down...
Re: The Death of Microservice Madness in 2018
#208Earlier quoted context omitted.
I call this the painting problem. Painting the walls of a room seems easy to an amateur: You just buy a few gallons at Home Depot and slap it on. But a professional knows that prep, trim, and cleanup are 80% of the job and they take skill. Anybody can slap paint onto the middle of a wall. What's difficult and time-consuming are making the edges sharp and keeping paint off the damn carpet.
So you are saying edge and corner cases are the most difficult?
In fault-tolerant distributed systems, yes; undoubtedly.
Re: The Death of Microservice Madness in 2018
#209I think "microservices" is so appealing because so many Developers love the idea of tearing down the "old" (written >12 months ago), "crusty" (using a language they don't like/isn't in vogue) and "bloated" (using a pattern/model they don't agree with) "monolith" and turning it into a swarm of microservices. As an Infrastructure guy, the pattern I've seen time and time again is Developers thinking the previous generat…
Do you legit think that people are all just doing this as a fad? There's legitimate arguments for looking at these patterns, the big one being "isolation of concerns". The biggest counterargument is that the ops cost is much higher than assumed, of course. The idea that the existing code base could have problems shouldn't be a surprise to anyone. Amazon almost fell over because of their code base. Twitter too. And it…
The ops cost of not using microservices is a lot higher than you'd think, too. At some point, when you have hundreds of engineers and your monolith is compiled together from libraries written by a dozen different teams and you have to try and make one heroic release per week, except half the time it fails and you have to go back and fix it, and absolutely no one in the company can ship a new feature because you're blocked.
Re: The Death of Microservice Madness in 2018
#210Earlier quoted context omitted.
I call this the painting problem. Painting the walls of a room seems easy to an amateur: You just buy a few gallons at Home Depot and slap it on. But a professional knows that prep, trim, and cleanup are 80% of the job and they take skill. Anybody can slap paint onto the middle of a wall. What's difficult and time-consuming are making the edges sharp and keeping paint off the damn carpet.
So you are saying edge and corner cases are the most difficult?
Great pun!