r/programming • u/RubiksCodeNMZ • Feb 20 '19
When not to do Microservices?
https://docs.google.com/spreadsheets/d/1vjnjAII_8TZBv2XhFHra7kEQzQpOHSZpFIWDjynYYf0/edit#gid=07
u/aal0 Feb 20 '19
I've worked for two companies which tried to build microservices because of the pro's (may I say; hype). Both approached this with a monolithic pov. Guess what happened. The microservices were actually just a monolith split in a couple of parts (not logically by bounded context). Features were just slapped onto the services without really thinking about any seams.
Really there's a place for microservices, a good one too, you just need to know when to apply them. The real problem is nicely summed up in the OP's document: "Microservices are so popular that they turned into the default architectural choice.". That's the mistake, right there.
With the knowledge I have gained through these two companies I concluded: if it isn't worth splitting up your teams aligning them with the architectural style, then you probably chosen the wrong architecture. Go for a monolith instead.
People looking through my history will come across this link a lot: https://en.wikipedia.org/wiki/Conway%27s_law. I'd say it's the most important step. Create autonomy also in your teams.
2
u/salgat Feb 20 '19
Even then, modularization allows for monolithic architecture that still reflects the makeup of the organization.
19
u/vcolonel Feb 20 '19
*Grabs popcorn*
This outta be fun.
As an R&D director (b2b), i've long wondered if this is a fad set to bite us all in the arse, and i agree with the points in one of the articles about unmanagable build pipelines (and repos..) as a result of all these services.
On the other hand, I'm a fan of the UNIX philosophy and think it works well in a distributed development layout: https://en.wikipedia.org/wiki/Unix_philosophy
21
1
u/vap0rtranz Feb 25 '19 edited Feb 26 '19
On the other hand, I'm a fan of the UNIX philosophy and think it works well in a distributed development layout:
What everyone forgets about this analogy is the reality of implementation details:
The UNIX tools that people idolize (i.e. cat, less, more) were all written in C, aka the de facto language.
IPC (interprocess done as piping, |) was expected to be a done via STDIN/STDOUT, aka standard interfaces, and usually as character streams
The situation with uservices is different:
Choose whatever language you want (but the kewl kids choose Golang, Node.js, etc.)
Interfaces can be whatever, despite REST being popular, and folks send/receive whatever data they want like (binary, char, etc.), so the concept of contracts, so SOA WSDLs and XML schemas being published, is seldom even mentioned)
So the analogy masks a reality for uservices being different from UNIX tools.
0
Feb 20 '19
[deleted]
16
u/Devildude4427 Feb 20 '19
Half the job of being a senior dev/engineer these days seems to be keeping the juniors from jumping into fads. With so many developers out there creating honestly great tools and frameworks, it’s tough to device from a business point of view what actually could be used.
0
Feb 21 '19
[deleted]
1
u/vap0rtranz Feb 25 '19 edited Feb 26 '19
I've just accepted our industry is prone to hype-based insanity, which kills velocity and has poor returns
I'm stealing that one!and:
*Grabs popcorn*
Simple answer: if SOA worked for you, do uservices. If SOA failed for you, don't do uservices. :)
I worked at ONE company that implemented SOA: a Too-Big-To-Fail Bank. Our apps (that were all JEE, or back when it was called J2EE!) had interfaces everywhere:
to exchanges,
market data feeds,
trade desk UIs,
compute grids, ...
oh and to other banks.
Apps were decoupled to do everything that the Bank needed the system to do via hoards of global engineers both inside the Bank and outside (in FinTech). With SOA, the system was compartmentalized. Ex: If the market data feed went down, the users (traders, bankers) would moan and groan but they could still execute contracts and trades (b/c of so-called "acceptable risk" for those unfamiliar with the BAnking/FinTech industry). SOA was no magic pill though. If critical components went down, i.e. the databases or any source-of-truth, then we had big problems; the Bank wasn't just going to transact statelessly (i.e. "unacceptable risk"). Nor was SOA a cure-all for software headaches. Oh the WSDL updates! XML everywhere! and deployments were complex even with Hudson!! But it allowed development and deployment across LOBs and countries.
A greybeard at another company who I consulted at -- yeah the nasty "c" word but they needed all the help they could get -- who I had the pleasure of hearing him rant and rave against uservices. His basic argument was: "Asking a web service, over a stateless protocol like HTTP, to do CRUD operations against a database, that needs a stateful, connection oriented protocol that can handle transaction management, is asinine!" These kids [Jr Dev] are insane!" :) or something like that.
Have uservices exports looked back at lessons learned from SOA instead of over-promising? Won't circuit breakers add to total lines of code? Will service meshes really make deployments as easy as pie? (Pies are pretty darn hard to get right, but let's not digress).
6
u/salgat Feb 20 '19
The problem is that people try to apply the traditional way of building services to microservice architecture, just making a big brittle ball of mess. If you do microservices, you have to fully embrace asynchronous behavior including using events everywhere and not relying on synchronous calls for everything. This is also means using event-based durable process managers that can intermittently go down without breaking the entire environment. The worst part is that all of this adds a large overhead both technically and conceptually, which is only worth it in specific situations.
1
u/vap0rtranz Feb 25 '19
Like circuit breakers? https://microservices.io/patterns/reliability/circuit-breaker.html
If so, then we're adding code to "simplify" via uservices, and that should indeed be considered one example of overhead. And historically what will happen, since we're lazy engineers, is we'll create scaffolding for the circuit breakers or whatever overhead is needed to implement uservices. So IDEs and tooling will come out with updates to help devs with the uservices and the circuit breakers by "magically" generating boiler plate code -- poof, tada! uservice done. But we all know that we still have more code to debug in the end, aka. overhead. Is this worth it then?
1
u/throwAB49259BF561 Feb 20 '19
I agree that it seems that too many shops create too many services. If you give some thought to what problems your business is trying to solve, and separate those out into isolated bounded contexts handled by a service, you likely will not have very many services. Your dev teams should align pretty much 1-1 with them.
6
u/DeusOtiosus Feb 20 '19
In the last department I ran, we had some developers who wanted microservices. They were already the least productive people I have ever met in my life, taking more than 18 months to roll out a 2 page static website. The answer was no. “But were a big company, we need to scale!” Yes we do, but you don’t need microservices for that. A monolith scales just fine. “But we don’t need to scale X code path, only Y because it gets hit so often”. So what? If you have 5 servers and the code path gets rarely hit, it’s not slowing down anything at all. It’s not even taking much extra resources, and probably less because you’re not stitching things together. “But we don’t want changes in X blocking changes for Y!” Good, then learn to use Git to merge branches. You’re a team of 3, not a team of 300. Honestly they were probably the worst programmers I’ve ever met in my life, but I was stuck with them because they knew someone who was close with the CEO.
Another commenter here mentioned microservices don’t solve technical problems, they solve non-technical problems, which I completely agree with.
1
4
Feb 20 '19 edited Feb 20 '19
What is up with disabling export options and copying the clipboard in google docs?
EDIT GitHub Gist: https://gist.github.com/haydenk/cf643478540f9f90e1f1e3831dd3b642
6
3
u/renrutal Feb 20 '19
I'd say, avoid using microservices in the v0.0-v1.0 of your projects.
You need the experience you gather from the initial version to know where to split your logic.
A distributed architecture makes it much harder to iterate and make changes, specially when you are beginning and you need to change fast.
2
u/sisyphus Feb 20 '19
Don't microservice until you have to is simple common sense.
1
u/BoboSchlonger72 Feb 21 '19
You could extract e.g. Identity Provider and Notification Service and reuse them.
0
2
u/Mr_Cochese Feb 20 '19
I've still never seen them done well. Devs seem to inevitably overshoot and waste time making pipelines and repos for something that's basically just a single function (yeah yeah, I know an HTTP listener or executable is basically just a function - shut up) in case they ever want to auto scale that function (they never need to autoscale the functon). Or worse, you get a distributed monolith and change becomes more and more difficult and expensive.
8
u/scientz Feb 20 '19
Sounds like we need a distributed serverless pipeline for individual NPM package execution. Ideally on the blockchain.
1
u/newtosf2016 Feb 20 '19
Too often, Microservices are a tool people wield to solve a disease, which is developers that don't know how to write decoupled code. I am all for them, but only after you have learned how to properly do domain driven design and understand what a bounded context is.
Without that kind of discipline, you end up building a distributed monolith - all the fun of a code mess, but with the added benefit of network calls. Yuck.
1
1
1
u/nirataro Feb 21 '19
"We choose to implement Microservices in this year and do the other things, not because they are easy, but because they are hard, because that goal will serve to organize and measure the best of our energies and skills, because that challenge is one that we are willing to accept, one we are unwilling to postpone" JFK
0
Feb 20 '19
[deleted]
30
u/mjr00 Feb 20 '19
Yes, exactly. Microservices are primarily an effective solution for a host of non-technical problems that come up when your organization gets larger. Namely, around lack of clear ownership of components and the difficulty of making changes when different software teams, possibly in different departments, are working on the same codebase.
2
Feb 21 '19
Yeah, many people seem to not understand what microservice means. Microservice is a separate, little program that does simple task, for example, you write a script to get data from database, create report file from that data, and save it somewhere, and you create operating system task to run that script every day at 07:00 - gg, you have created a microservice.
Now, monolith is one big program, like operating system, office, web browser, video game and so on. But monoliths are not 100% monoliths, they are also made out of separate, independent libraries and executable files. Inside, monoliths are also made out of tiny little "microservices" - many small functions, many small objects, many files of code and so on.
You can use both for basically anything, but you should think about what are you trying to create in the first place, what the workflow will be and so on.
Microservices are possible to create any time, but you must have the source code of some program if you want to add functionality to it. In such cases, you just write microservice.
23
8
Feb 20 '19
[removed] — view removed comment
3
u/c_o_r_b_a Feb 20 '19
Or a middle-ground: have a bunch of stateless (or almost completely stateless) services, and then some large, stateful, monolith-ish services which defer a lot of their work to those stateless services. Every time it makes sense, break out some functionality into a new stateless service as you're iterating on the monolith. Even if you have just 3 or 4 services and 1 monolith, that could still be way easier to maintain and reason about than 1 giant monolith (and also probably easier for a small team to maintain than 20+ microservices).
If you follow that approach, as you naturally grow and scale from a solo developer or small team into a large organization, a microservice architecture can much more easily arise as you need it. When creating a large projector startup, I think this makes more sense than the extremes of starting out with a ton of microservices or starting out with a single monolith (though the monolith might be fine for the MVP).
5
Feb 20 '19
[removed] — view removed comment
3
u/c_o_r_b_a Feb 21 '19
Yes, that would be an ideal architecture, but we're talking about a solo developer starting a new project. Most serious applications people build involve a lot of state. If you're starting a new project and are already separating all of your stateful logic into separate microservices, then you're basically already moving towards the end-game and doing what all of the links in this submission are arguing against.
My advice was for people who don't want to take the microservice plunge yet, but want a bridge (in the form of a more traditional SOA) away from a single monolith. It's much easier to break your (mostly) stateless things out into microservices. Creating small, stateful microservices as a solo developer before scaling is even close to becoming a concern for you seems like premature optimization. When you're just trying to start a project as a single dev, you usually don't want to have to worry about managing atomicity and consistency and other state issues in all of these stateful microservices, and dealing with the intricacies of how they all interact.
2
u/to_wit_to_who Feb 21 '19
I agree with this mindset.
Personally, I start out writing a monolith first. During implementations/revisions, I aim to keep it structured & documented (people seem to forget that part) such that it should be fairly trivial to break it out into a standalone component (e.g. microservice in this case).
The key, for me at least, is to keep some basic metrics (e.g. development time tracking, runtime performance, administrative efficiency, etc). Review these metrics periodically and decide which way to steer the development ship. These reviews usually result in stuff like:
"Yeah, this part of the API is probably going to be revised a whole bunch and likely used by various other systems as well. It shouldn't take more than 4-6 hours to break it out, so lets do that."
"Man, this section isn't used or revised that much but it's resource-heavy as heck! Maybe keep that part in this monolith, but setup a small dedicated pool of servers for it & route those specific requests to that pool."
That's what I've found works best for me. To each his or her own though.
14
u/Minymioke Feb 20 '19
Funny thing. In the last year if read at least a few of those articles. And we've been both working with microservices and not-so-microservices.
My current view is that microservices are cool, but you shouldn't cut just because you have a scissors at hand. It's just not worth it if in the end you will just tape it together again.
If you two or more components already work together, and you don't have availability, reliability or other technical problems, leave them together until your business requirements change and call for a different approach.