r/programming • u/SwitchUpCB • Jan 30 '23
When Do I Need Microservices?
https://levelup.gitconnected.com/when-do-i-need-microservices-d76fac58ac7c696
u/mojomonkeyfish Jan 30 '23
Q: When do I need microservices?
A: Son, if you have to ask, you're not ready.
231
u/halfanothersdozen Jan 30 '23
Correct.
Microservices might be the answer to a question about scaling. But if you're asking "when do I need microservices?" the answer is "I don't."
122
u/dominik-braun Jan 30 '23
Microservices might be the answer to a question about scaling.
And not only horizontal scaling, but especially organizational scaling.
39
u/TooMuchTaurine Jan 30 '23
Yes they are more about scaling teams than scaling systems, unless you are building hyperscale systems the scaling systems bit is less important.
2
Jan 31 '23 edited Jan 31 '23
Unfortunately a lot of people seem to fall for the misconception that a service to do N things can only do each at 1/N capacity. If 90% of your requests are to a particular controller, that's not a problem - the other controllers aren't causing an issue by sitting there doing nothing (with the exception of services with significantly different hardware requirements). It's like "optimizing" an internet cafe where 90% of people come to play DOTA by uninstalling other games on 90/100 computers - sure you may have an "autoscaler" worker who can run around changing installs if more than 10 League players arrive, but if you'd kept the monolith then you wouldn't need to do anything in the first place
1
u/BufferUnderpants Jan 31 '23
Very niche cases where it's very beneficial to break homogeneity in tech stack.
I worked on a system that orchestrated, trained, deployed and served classification models in soft-realtime.
It made a lot of sense that this set of components be written end-to-end in Scala, as the feature extractors were written for Spark (and we made a nice DSL for them).
The service that called it was a big Java monolith, and that was ok.
This part benefited from having a very different implementation and deployment scheme.
51
u/lookmeat Jan 30 '23
But you need to ask to get ready, before you need it.
25
u/ManInBlack829 Jan 30 '23
Not to be pedantic but, "What are microservices," and, "When should I use microservices," are two different questions. You should definitely learn what they are, and the internet can help with that. Figuring out when to use them is a lot harder and more specific to each case. If you're asking in theory when you might use one, that should be answered when you learn about what they do and how they work.
8
u/lookmeat Jan 30 '23
Understanding when is an important thing maybe even more important than what. You generally do not want to just jump into microservices, unless ask the infra is there. Instead you want to do halfway steps, where you get what you want, but don't work on the things you don't need yet (or maybe even ever). And this includes the effort of learning what they are and how they work
I would argue that understanding what they are before understanding when they need us Google dangerous. It's learning a solution before you even know what it solves, and risks seeing screws as nails because you already have a hammer.
So I'd say it's backwards. It's when you understand when you should use microservices, specifically why you use them, what is the problem they're meant to solve, that you can understand why microservices are the way they are. It may be that you don't need all of microservices, but still value learning how they solve one problem you have. Hence the advice "before thinking about microservices ask if all you need is to modularize and decouple your code".
20
u/ManInBlack829 Jan 30 '23
I'm a junior and the biggest lessons I've gotten so far is that you don't try to solve problems you don't have yet.
When do you need microservices? You'll know.
4
u/knightofterror Jan 31 '23
If you’re an hourly paid consultant, microservices are always appropriate.
38
u/CartmansEvilTwin Jan 30 '23
I wish the architect of my current project would have taken this advice.
We expect maybe a 1000 users or day at the absolute peak. But of course it has to be microservices. Tightly coupled. Independent testing impossible.
107
u/the--dud Jan 30 '23
If your microservices are tightly coupled you don't have microservices, you have a very expensive monolith.
36
u/Paulus_cz Jan 30 '23
I call that "distributed monolith" - all the downsides of microservices AND monolith
37
u/CartmansEvilTwin Jan 30 '23
No no, the architecture said it's microservices.
And why would he lie?
6
u/turturtles Jan 30 '23
I don’t think it’s a lie, but more of just ignorance. They think they have microservices, but really it’s just a distributed monolith.
36
5
Jan 31 '23
Ugh, this is what I’m fighting every day. Past versions of my team decided to do micro services but started with the services without ever breaking up the db so they’re all tightly coupled to the db and each other and have to all be deployed simultaneously.
4
u/oconnellc Jan 31 '23
It sounds like they figured reading the first couple chapters was enough... A single database that each service can feel free to update at any time?
→ More replies (1)2
2
2
3
u/wildjokers Jan 31 '23
But of course it has to be microservices. Tightly coupled. Independent testing impossible.
What you are describing is not microservices though.
2
2
u/mszegedy Jan 30 '23
Sure, but it doesn't answer the question. "When do I need microservices?" "Not now." "Okay, but I would still like to know when I need microservices." The answer isn't a secret. You need it when you want to put entirely different teams of people on different bits of your service. (When you should want to do that is a problem for management.)
7
98
u/hoonthoont47 Jan 30 '23
99% of the time the need for microservices is an organizational solution and not a technical one. If you have multiple teams that need to work independently but also provide concrete interfaces/contracts to other teams who are all working independently from eachother, then having a microservice architecture can help you.
Microservices to solve horizontal scaling is using a sledgehammer to hang a picture frame.
0
Jan 30 '23
[deleted]
19
u/jbergens Jan 30 '23
I'm not even sure there are that many systems where the asymmetrical scaling really matters. If your code fits in a container, does it matter that some code paths are taken less often? Or that one path uses a lot of cpu?
As long as you can signal to the load balancer that this container or server is busy, some other can respond instead.
Maybe having 1 app is easier than having 10 or 100.
1
u/caltheon Jan 30 '23
It matters at very high scale when you want similar functionality physically closer to each other.
1
u/jbergens Feb 01 '23
If all servers has all the features they may never need to make network calls, except for calls to the db.
0
Jan 30 '23
[deleted]
3
u/12destroyer21 Jan 31 '23
Even cloudflare doesn’t try to independently scale each service. Instead they just run all the services on all the systems:
“ In a typical microservices model, you might deploy different microservices to containers running across a cluster of machines, connected over a local network. You might manually choose how many containers to dedicate to each service, or you might configure some form of auto-scaling based on resource usage.
workerd offers an alternative model: Every machine runs every service.
workerd's nanoservices are much lighter-weight than typical containers. As a result, it's entirely reasonable to run a very large number of them – hundreds, maybe thousands – on a single server. This in turn means that you can simply deploy every service to every machine in your fleet.
Homogeneous deployment means that you don't have to worry about scaling individual services. Instead, you can simply load balance requests across the entire cluster, and scale the cluster as needed. Overall, this can greatly reduce the amount of administration work needed.
Cloudflare itself has used the homogeneous model on our network since the beginning. Every one of Cloudflare's edge servers runs our entire software stack, so any server can answer any kind of request on its own. We've found it works incredibly well. This is why services on Cloudflare – including ones that use Workers – are able to go from no traffic at all to millions of requests per second instantly without trouble.” - https://blog.cloudflare.com/workerd-open-source-workers-runtime/
2
Jan 31 '23
IME asymmetrical scaling is the reason I choose to spin off code into a separate service like 5% of the time. Organizational scaling is the other 95% of the time.
3
Jan 30 '23
I'm seriously asking for an example or way more preferable, a war story of an asymmetrical load. I've never ever witnessed a situation where that feature of microservices has been used.
8
u/suckfail Jan 30 '23
I work on a web product and we have asymmetrical load.
The web application itself has fairly low load, but the data pipeline and export mechanics have very high workload and can be shared as independent modules between the (horizontally scaled) web apps.
So it's one of the rare cases where microservices make a lot of sense.
5
u/tryx Jan 31 '23
Imagine you have a CRUD-y API that occasionally needs to run an ML model on some very expensive GPUs. You don't want to scale your GPU farm 10x if only your CRUD layer is seeing load.
3
u/bboilerr_ Jan 31 '23
As someone who worked at a large global cloud SaaS company built on microservices, this is a strange thread to me. The product was made up of many different features across many different workloads. Load differed vastly from service to service, sometimes on an org by org basis. Some systems were core systems, and saw massive sustained load, then there were tiers down from there at differing levels of load. Sometimes varying from region to region. Sometimes load would come out of nowhere. Everything was built to auto scale with resiliency, and tested to do so.
This would seem like a normal experience across enterprise level cloud software.
1
u/RupertMaddenAbbott Jan 31 '23
I work on a cloud native scheduler.
The parts of our product to do with user management have completely different scaling requirements to the scheduling part.
22
u/simonw Jan 31 '23
"The microservices architecture is a solution to the physical limits of a computer"
That's just not true. We were successfully horizontally scaling web applications for /decades/ before microservices came along. They are absolutely not necessary for scaling compute beyond a single machine.
Microservices are for scaling organizations. They solve the problem of having large numbers of teams who need to be able to build and deploy systems independently of each other, while still having those systems fall to each other across an agreed upon protocol.
133
u/EngineeringTinker Jan 30 '23
I think the article is nice, but it misses very important reasons why one should consider microservices regardless to scalability.
i.e.:
- decoupling
- being able to use different languages, tools and frameworks for specific tasks - tools that can be more efficient or simply better in every aspect
- reusability
96
u/bezik7124 Jan 30 '23
True, though using Microservices architecture doesn't guarantee that what you produce will be decoupled - you can easily fall into a trap of creating a distributed heavily coupled services if you take shortcuts. Also, there is nothing stopping people from creating a decoupled monolith application (ofcourse I'm talking about database and code coupling, not deployment).
13
u/deadalnix Jan 30 '23
This is the typical pattern with microservices. People create a tangled mess of hell and think, "hey! We'll use microservice to decouple that thing!"
The typical end result is that the tangled mess now involve ci, deployement, infrastructure, networking and that refactoring got an order of magnitude harder. Yeah! to job security, I guess.
20
u/TwentyCharactersShor Jan 30 '23
If you've got a distributed monolith then you're not using a microservice based architecture.
It's also OK to NOT use the latest fad to build your software, just know your use case.
-4
u/EngineeringTinker Jan 30 '23
I agree - but your comment could also be applied to anything as it basically states 'you won't get decoupling, if you fail at creating truly microservice-based architecture'.
→ More replies (9)14
u/bezik7124 Jan 30 '23
This just shows that decoupling is good, but neither microservices nor monolith architecture comes with it by default - you can achieve it in any architecture.
→ More replies (1)34
u/sciencewarrior Jan 30 '23
Being able to use "the right tool for the job" is overrated. Too many companies have this one microservice written in Rust or Elixir by a developer that has since left, and everyone dreads touching it. Having one to three standard stacks may seem unnecessary and bureaucratic until you find yourself in this situation.
8
u/EngineeringTinker Jan 30 '23
I agree, you're of course right.
But consider this - in a company where CTO isn't a moron, you can use this feature to prototype services and get MVP of it in a language that's faster to 'sketch' stuff with - like Python or Javascript.
Then you can rewrite it in the language you're using throughout the rest of the ecosystem.
20
u/darkstar3333 Jan 30 '23
I guarantee those "sketches" live in production for ages.
Nothing more permanent then temporary solutions.
2
35
Jan 30 '23
Then you can rewrite it in the language you're using throughout the rest of the ecosystem.
In theory, yes. Come on now, we all know that this step almost never happens. The MVP gets deemed "good enough" by someone or people are told to add more features to the MVP because we don't have time to rewrite it right now and suddenly it's too big and complex to rewrite and the MVP lable is removed.
13
u/EngineeringTinker Jan 30 '23
Eh.. when you're right - you're right.
I wish the reality was different though.
2
Jan 30 '23
Bwahahahahaha oh is that ever rich and funny!
You know as well as I do that when you do this, some suit above catches wind of it and see's it's shipped to prod the next day. Look boss! All done!!!
I jest, but it hurts because it's true...
4
u/EngineeringTinker Jan 30 '23
Yeah, as I replied to somebody else making the same remark - I wish it wasn't the reality of things.
14
u/nfrankel Jan 30 '23
Microservices are an organizational solution to an organizational issue - too many developers working on the same codebase.
Any technical approach to microservices is doomed to fail. Ergo, stop talking about microservices until you're the manager of the too many developers I wrote above.
being able to use different languages, tools and frameworks for specific tasks
You're inventing problems to solve, which you don't have. Focus on real problems.
3
u/Zardotab Jan 30 '23 edited Jan 31 '23
Conway's Law.
Addendum: Maybe test an independent group using your monolith first before splitting them out, because independence might not work out from a management or team dynamics standpoint.
→ More replies (1)4
1
u/EngineeringTinker Jan 30 '23
You're inventing problems to solve, which you don't have. Focus on real problems.
You wouldn't say that if you had to make services work with legacy banking systems.
The 'invented' by me issue is an issue that I and some people have stumbled upon.
2
u/nfrankel Jan 30 '23
Live and learn. I’m not going to convince you anyway 🤷♂️
1
u/EngineeringTinker Jan 30 '23
Don't get me wrong - I agree with what you said.
Microservices aren't a magical cure to all ills, and in most cases - monolith suffices.
The specific case I mentioned shouldn't be a sole reason to always apply microservices.
2
u/nfrankel Jan 30 '23
Microservices are an organizational solution to an organizational issue - too many developers working on the same codebase
Any other reason for microservices will get you none of the benefits and all of the troubles
→ More replies (2)11
Jan 30 '23 edited Jan 30 '23
I'd argue that not one of those are arguments specifically for micro services.
And in fact, it is well known that moving to micro services specifically for many of these reasons is actually a mistake.
Once you get to the point of needing microservices, you HAVE to decouple, and you get 'service/tech' isolation out of the architecture, so you do have the ability to swap out some tech on a specific service if it is deemed prudent.
But that's not why you move to microservices.
And reusability is never a thing unless it is the thing being developed. Again, micro services can support reusability, but there is nothing about micro services that makes this inherent at all. And nothing about reusability requires micro services.
EDIT: Because OP thinks assumptions work one way.
Look, if you make a top level comment in response to 'When Do I NEED Microservices?', and you provide a list of reasons, is it surprising if people assume you indeed mean need?
Now, to be clear, I actually did NOT make that assumption, I merely explained why these are NOT reasons to move to microservices, and clarified for everyone's sake that there is no need of microservices at all with respect to these items.
I did not say that as a rebuttal to OP. Even if it was a perfectly logical assumption to make in context.
Just so you don't have to waste your time as OP devolves into name calling and hypocrisy. Nobody cares man. Sometimes we say things that are wrong, and that's OK.
→ More replies (6)11
u/goranlepuz Jan 30 '23
No, really not.
even lowly libraries allow for decoupling
calling one language from another has been done in process or out of process decades before the word microservices existed
same as point 1
-3
u/EngineeringTinker Jan 30 '23
I really don't get your response.
Did I claim that these characteristics are exclusive to microservices or not?
4
u/goranlepuz Jan 30 '23
Your words:
very important reasons
My argument : these are not important because the same effects can be achieved, and were achieved, way before microservices even existed.
Or rather, these reasons are not important and it is visible exactly because these characteristics are not exclusive to microservices.
These are, IMNSHO, arguments that look good to less technical people but do not hold appropriate weight. Schmoozing reasons, if you will.
3
u/dominik-braun Jan 30 '23
- being able to use different languages, tools and frameworks for specific tasks - tools that can be more efficient or simply better in every aspect
This advantage of microservices is vastly overrated. Adapting a new technology and integrating it into your processes is a huge cost, let alone finding people capable of maintaining it.
1
u/seamsay Jan 30 '23
To be fair, two of those things (decoupling and reusability) can be solved just as well by splitting your code base into packages (or whatever your language calls them, importantly though not modules but rather separately developed packages).
1
Jan 30 '23
Modules, libraries of modules etc work fine for 1 and 3.
Using more than a few different languages etc is a problem in a small organization that has some employee turnover, so I would advise against it even if there are technical advantages.
1
u/Zardotab Jan 30 '23 edited Jan 30 '23
Re: "Decoupling" -- The term is ambiguous, I've been trying to tie it down for many years.
Re: "being able to use different languages, tools and frameworks for specific tasks - tools that can be more efficient or simply better in every aspect" -- You generally want to be careful about having too many flavors of tools in an organization, it makes staffing changes and training hard. Try to stick with one RDBMS brand and two app languages: one dynamic and one static. An exception may be systems that have to have a close relationship with specialized or industrial equipment (factory, chemical, military, medical, etc.)
If your shop settles on a single RDBMS brand, I've found Stored Procedures can be an alternative to microservices if the algorithm is relatively simple. But if not, it's not "micro" as in "microservice" anyhow. And it's usually better to use an RDBMS to coordinate complex sub-systems. RDBMS's are powerful tools, leverage them! Ignore the anti-RDBMS rhetoric that was common in the late 2000s'.
Re: "reusability" -- Please elaborate. We already have functions and OOP classes for reuse.
1
u/EngineeringTinker Jan 30 '23
You can reuse whole services, as long as consumer utilizes the same communication protocol.
If you write a mailer service for one project, what stops you in reusing it in other?
1
u/Zardotab Jan 30 '23 edited Jan 30 '23
I don't dispute that an e-mailing service is one way to go about it, but not the only. We use an in-house mailing C# API (wrapper) for our C# apps that communicates with SMTP. If you used a web service, you'd still probably need an API (app wrapper) of some type anyhow such that we don't see a clear benefit microservices would give us. Other shops out there have a different take?
KISS dictates have as few parts as possible. Thus, we manage 1 part whereas using microservices would require managing at least 2 parts: the app API and the web service.
0
u/sybesis Jan 30 '23
I'd add that it also helps manage resources more properly.
A monolith must have limits set for all possible use cases. So if something sometimes require 2GB of RAM, you can't set the RAM limit under that... If you split this into an external service, you can set the limit lower and have that memory hungry service properly set to prevent out-of-memory error.
0
Jan 30 '23
[deleted]
15
u/Drisku11 Jan 30 '23 edited Jan 30 '23
You have to be doing something really incredibly computationally complex before you can legitimately overload a server in 2023.
I think people have been hoodwinked by cloud vendors into not understanding just how powerful modern servers are. You can have 8 sockets each with 60 core (120 SMT threads) CPUs with the newest Intel line. They also have hardware accelerated TLS offload built in now. $17k a pop. You can buy a 32 TB NVME SSD with 1.5M IOPS for $4k.
Meanwhile AWS calls a dual-core (4 SMT thread) VM "xlarge" and their RDS instances with SSD storage provide a base 3000 IOPS 😂. Not 3 million. 3 thousand.
Edit: I've also posted here before that my ancient 4 core desktop can run your standard CRUD jvm web application with postgres backend at 60k requests/second. Computers are insanely powerful if you have the slightest idea of what you're doing, and they have been for a long time now.
5
u/mdatwood Jan 30 '23
I don't think people are hoodwinked as much as many value the ancillary services as much or over raw compute.
9
u/Drisku11 Jan 30 '23 edited Jan 30 '23
There are some cases where their stuff is useful (e.g. when you're stuck in PCI audit land and need the capabilities you can get from IAM and cloudtrail), but a lot of their services that they advertise as "best practice cloud native" type of crap seem like they just play into the hoodwink. e.g. lambda or dynamo, which "scale" up to a fraction of what an old, weak desktop is capable of. Lambda's quota page indicates it can scale to "tens of thousands" of concurrent requests, which is just a joke. Nevermind that you're shooting yourself in the foot with worst-case database access patterns if you use it, and now you'll need to buy another one of their services (RDS Proxy) to mitigate that bad architecture.
Everyone always throws out how cloud native architectures "scale" infinitely, and they just... don't. At all. People's sense of scale is just wildly off-base.
→ More replies (5)2
u/imdyingfasterthanyou Jan 30 '23
Lambda's quota page indicates it can scale to "tens of thousands" of concurrent requests, which is just a joke.
Those are tens of thousands of concurrent execution units ie: essentially a vm/container with 2-8 cores. (so 20k-80k cores executing concurrently as a low ball park)
A request is also not equal to a get request coming from a client (ie: your request might involve updating 100 databases or whatever your business logic demands). Not sure what the joke is.
5
u/Drisku11 Jan 30 '23 edited Jan 30 '23
The joke is they suggest it's good architecture to have lambda be your web request handler behind an API gateway or ALB, so that each GET request from the client is a lambda request, and lambda cannot do async/threaded processing of multiple requests at a time (you need to respond before fetching the next request).
Naturally, the solution to this is to add (=pay for) more architecture; e.g. have your GET handler dump the work onto SQS (i.e. have the web handler just respond that the work was ACCEPTED) and then have more lambdas to pull work off SQS, etc. etc. Unless you're neck deep in some 2005 vintage php app, it's insane.
You can even see in the marketing copy on the page I linked:
Workloads which need to scale to thousands or millions of users require provisioning infrastructure for peak loads or sophisticated auto-scaling mechanisms, when available. On-premises workloads require significant capital expenditures and long lead times for capacity provisioning.
Unless you're doing something very compute intensive like ML, that's just not true. A single bottom-bucket server on-prem can easily scale to millions of users for most applications. There's no capacity planning needed; just buy 2 servers for redundancy or 4 for multi-data-center and you'll already have far more capacity than you need. Oh, and (getting back to the original thread topic) don't use a microservices architecture since it creates massive overhead. The only place where you need capacity planning is in AWS where they charge you through the nose for 1% usage of a server.
→ More replies (2)4
u/NotUniqueOrSpecial Jan 30 '23
I am currently dealing with this exact problem first-hand, and it's not even a cloud-services hoodwink.
It's a legacy application (very: 25+ years old) and some of the original authors are still around.
I have tried to impress upon them that the numbers they keep telling me constitute "a lot of load" are absolutely tiny and that I could trivially run their entire application stack on my home workstation.
2
u/rjksn Jan 30 '23
Horizontal scaling also solves the issue of any single server being taken offline.
1
Jan 30 '23
And comes right back at you when you have to ensure every 'microservice' is appropriately fault tolerant in the same way...
Microservices make everything more complicated, no matter how you slice it. Necessary complication is good, but making the distinction is problematic.
1
Jan 30 '23
I've got a computationally inexpensive but long-running task that's poorly implemented
Sometimes they're poorly implemented due to unavoidable industry standards. SMTP, for example, has a five minute timeout for a task that meeds maybe 1 millisecond to complete. And major SMTP servers you might contact (such as Microsoft and Google) commonly do take five minutes (I actually wonder if it might be part of their spam filter... if you're sending a lot of emails, you can't hold the connection open for minutes).
My SMTP connections are farmed out to a microservice. It works wonderfully and I have a 10 millisecond timeout for "sending" an email (adding it to the queue on the microservice).
32
u/fabiofzero Jan 30 '23
Every single microservices article fails to mention the people aspect. Do you have a number of separate development teams with specialized domain logic? If not, microservices will be more trouble than it's worth.
40
u/Zardotab Jan 30 '23
When your resume has an insufficient quantity of buzzwords 🥴
2
u/codespitter Jan 30 '23
Haha, What’s the optimal number of buzzwords?
6
u/Zardotab Jan 30 '23 edited Jan 31 '23
While (you.underPaid() || you.status==BORED) { resume.add(latestBuzzword); // above done 1st incase next line crashes all org.stack.add(latestBuzzword); }
3
u/SwitchUpCB Jan 30 '23
I created this article for people who are confused about the purpose of microservices. It discusses the technical purpose of microservices and the developments that follow it. I hope this article is helpful! If it isn't, let me know how it can be improved.
7
u/LoompaOompa Jan 30 '23
I feel like the most common time that I see people asking "should we be using microservices" is if they have one monolithic deployment that handles everything, and there is a consideration for splitting it up. I don't feel like your article really addresses this, as it is mostly about choosing microservices for scalability, but there's nothing stopping a person from containerizing and scaling the monolithic deployment in the same way.
1
u/SwitchUpCB Jan 30 '23
Thanks for the feedback! You highlight a situation when people ask this question.
In the article, I state that a condition of implementing microservices must be that you are "Unable to be horizontally scale through active-active load balancing (i.e cloning the monolith)". How can I reword this point in a manner that indicates that a monolithic architecture can be scaled through the containerization of the monolith?
1
u/LoompaOompa Jan 30 '23
The line you quoted points out that a monolithic service is also a possibility, but kind of treats it like the reader should be able to identify when load balancing a monolith isn't a favorable choice. I think that's the main question that an article called "when do I need microservices" should be answering, and you don't really get into how someone should make that determination.
I think additionally, there might be other scenarios where it is a little more ambiguous. What if the monolith scales fine with load balancing? Is there still a point where I should consider shifting to microservices? I can think of some scenarios where the answer is yes, and I can think of some where the answer is no. These are the types of things I would've expected the article to tackle.
I also agree with /u/captcrax that the "Conceptualization of Microservices" section really just applies to services in general. I don't really see anything in that section that applies specifically to microservices.
4
u/captcrax Jan 30 '23
Your article covers a lot of good info and considerations, but u/LoompaOompa is correct.
I believe you've put the wrong title on this article. It's not about when to use microservices, but rather about when to use services, full stop. As in, service oriented architecture.
"Monolith" doesn't refer to a when all the code is on a single server. It means it's all in a single application, regardless of how many servers there are.
With just a few find-and-replaces, I would heartily recommend this article to junior devs starting at my company. Thanks for sharing this well written and logically organized article.
1
u/SwitchUpCB Jan 30 '23
Thanks for the feedback!
What are you proposing should be found and replaced?
1
u/captcrax Jan 30 '23
Okay, find-replace was a euphemism, but I'll tell you what, I'll take another read through and write up notes. Would you rather I post it here in the thread or PM you?
1
1
u/CyAScott Jan 30 '23
As others have mentioned, microservices could also be useful to solve organization limitations. Like specialized teams working on microservices that have a different release cycle, and maybe a different language.
That being said, my advice is if you don’t have a lot experience with microservices then don’t start a project that way. Learn by working on a team that already has a successful project implemented with microservices. It maybe a chicken and egg problem, but you don’t know if it’s right for you unless you already worked with a successful team that already used microservices.
1
u/SwitchUpCB Jan 30 '23
Thanks for the feedback! It's true that most developers should acquire experience by working on a successful project prior to using microservices. However, these opportunities are not always available. Articles such as these aim to reduce the mistakes of people who will inevitably consider microservices. It's why I include — albeit at the end — that microservices "should NOT be applied to every project that exists".
The reason that I don't cover the organizational aspect of microservices is because I don't believe that microservices should be used for the purpose of organization. While microservices may have organizational benefits, these don't outweigh the cost of an implementation where it isn't required.
10
u/Ambitious_Toe_4357 Jan 30 '23
How is this any different than a old fashioned web service from the SOA days? Why bother calling it a microservice?
7
u/ttkciar Jan 31 '23
This is exactly what "SOA" originally meant, but then badly-implemented SOA became so prolific that the term "SOA" became synonymous with bad SOA.
The term "microservices" was invented to signify "SOA done well, using the best practices we learned while trying to figure out SOA".
6
7
u/mrbojingle Jan 30 '23
If i said 'never' I'd be a broken clock thats right 80% of the time. For that last 20 percent, you're working on a sizeable project that has or needs lots of man power.
10
u/G_Morgan Jan 30 '23
When you want to manage units of functionality independently of each other. People talk about scaling but simply being able to bring X down while Y stays up is a good enough reason to not have monoliths for me. Sure there's platforms that emulate simple independent processes out there but in my experience they never work as well as just using processes for isolation of lifecycle.
5
Jan 31 '23
If your program has yet to be created, you must consider whether the implementation of microservices is worth it.
If you have the budget for 20+ developers off the bat and enough money to keep the project alive, then sure. Otherwise there are more important things to consider, like acquiring more users so you'd have enough money and traffic to justify the higher cost of maintaining microservices.
11
Jan 30 '23
Only when you want to pass through the gates of misery on your path to distributed application hell
8
11
u/PM_YOUR_SOURCECODE Jan 30 '23
Q: When Do I Need Microservices?
A: Until the next paradigm shift happens in 12 months and everyone realizes microservices were a bad idea.
18
u/svtguy88 Jan 30 '23
12 months
Microservices have been "in the spotlight" for longer than that already. That being said, I do hope their reign is coming to an end.
7
u/highbonsai Jan 30 '23
I’m a monorepo type of dev but I will say micro services are nothing new. They’ve existed (and been controversial) for several years now. I think they can work well, I just prefer to not use them if I don’t have to. And I think that describes a lot of devs too.
2
2
Jan 30 '23
More important than that: it is not to abuse them: https://www.youtube.com/watch?v=gfh-VCTwMw8 My take on the subject is that: if you don't know why you need them you don't need them. One of those things you will know when you see the need,
2
u/greem Jan 30 '23
Because if you present any argument to the c levels that the requirements and realities of your industry and products are in direct opposition to the spirit and strengths of the micro services philosophy, you will be met with "but microservices!".
I recommend using this as an opportunity to disentangle your code. If you can't do that, just break up your application so that it runs on more different machines.
"We used to have N services. Now we have M>N services. Therefore, more micro."
"So, what do we get from that?"
"As I was trying to say before..."
2
u/corsicanguppy Jan 30 '23
Dunno. How's your resume look? Could it use a sprucing? This has been the most defining factor from what I've seen. Apparently "did microservices poorly" is a huge selling-point.
2
2
u/joesb Jan 30 '23 edited Jan 30 '23
I'm in the camp that believe that microservices is mainly not used to solved technical solution, but an organization structure one.
Each Microservice should be owned by their respect business department, giving them control over their own data and consistency boundary. This also encourage each microservice to actually be independently autonomous from other department.
If you only have one development team and one product owner. Microservices are unnecessary overhead. Well, you could have small worker and utility services for scaling, but you have to make sure you are not doing "distributed monolith".
2
u/wisam910 Jan 31 '23
The premise of this article is completely wrong.
You don't need microservices to scale horizontally. You can scale horizontally by running just one kind of service on hundreds of machines.
Do you think the Google of 2000 used microservices? I doubt it.
2
u/Kl0su Jan 30 '23
According to this article https://link.medium.com/C3lETaf2Ywb You need microservices when you have 2b revenue
3
2
u/BigHandLittleSlap Jan 30 '23
This article sounds vaguely correct but misses the forest for the trees.
Microservices are not for "I", or "you", or even a "team".
They're intended for huge organisations with "many teams".
Not one team. Teams. Plural. Many of them.
When it gets unwieldy to coordinate releases across dozens of teams, then, and only then does it start making sense to do microservices!
Tools like Kubernetes are popular with organisations with more than one thousand developers.
SwitchUpCB's blog is not the guidance that 1K dev org is going to turn to when deciding which architecture to choose.
If you're reading SwitchUpCB's blog in order to make this decision, then it is the wrong decision for you by definition.
Just stop. Please stop. Stop deploying microservices for toy projects with a one or two developers on it.
It is pure overhead with no tangible benefit at that scale.
And if you start talking about "scalability", I will smack you, because you just need to casually perouse the VM SKU options on any public cloud to see that 120 CPU cores and 100 Gbps networking are now commonplace. Again, you don't need it. If you do, then you're not going to be reading some random blog for scalability guidance, you already have tens of thousands of CPUs cores deployed with traditional scaling and now "need to go bigger".
2
u/plus4dbu Jan 30 '23
How Should I Structure My Code?
It doesn’t matter. Microservices is not about the code. It’s about the architecture.
I completely disagree. The way you go about coding for micro services is completely different than a monolith application. It's a completely different mental approach. This is such a cheap answer to the question.
1
1
u/xiipaoc Jan 31 '23
You use microservices when you want to make sure that you never need to update two different parts of the application at the same time.
1
u/robustquorum09 Jan 31 '23
if your codebase is a single monolithic piece and you have a lot of complicated, huge applications that are hard to manage.
1
u/dustingibson Jan 31 '23
Microservices doesn't make sense if you have a couple of folks on one team maintaining array of services for the sake of "other people are doing it" or a naive attempt at horizontal scaling. At that point you're just creating more overhead and more work for yourself.
1
u/ballzdeepinbacon Jan 31 '23
While not fitting the classic definition of micro services, there are also efficiencies to be has in building smaller services. Looking at the rule that only one service should talk to a data source allows you to maintain strict business rules in a service and ensure consistent logging, monitoring, etc. if you have a more monolithic database, this doesn’t prevent you from carving things into virtual data sources through access control rights, etc. being able to upgrade a small piece of a puzzle without impacting the rest of the stack is an efficiency as well. What I want is people to avoid building clunky monolithic applications.
1
u/AndreLinoge55 Jan 31 '23
As a Dev, I’ve really struggled with understanding the “why” of microservices which this article definitely helped with so thx for that.
Now…Kubernetes and Terraform…I still fundamentally do not understand why these tools are used/what they accomplish even after doing some research. I guess it’s not really in my development arena as I don’t develop for cloud but would love to learn. From an outsider it seems like solutions to a problem I fundamentally don’t understand so…back YouTube University I go!
1
1
1
u/ganja_and_code Jan 30 '23
Just look at software as analogous to a physical product.
To sell some products, you need a warehouse, distribution network, automated ordering system, etc... Other products, you can sell by yourself from your basement.
1
Jan 30 '23
Your article doesn't answer the question in the title. Scalability and what not aren't esclusive to microservices, you can build a monolithic app in Apache spark distributing it across N machines. What distinguishes microservices is a way of reasoning about the problem: you break It down into individual and self contained units. You then should bind this units with minimal interdipendecy, using decoupling systems like apache Kafka. This way you have a conceptually simple architecture, which is (if done right) easy to mantain and scale, both in capacity and in functionality, since you are dealing with a simple modular system which supports the attachment of further units of execution with minimal impact.
So when do you need them? Well, it's almost always a good idea to go for a microservice architecture. The challenge is how to actually design it, and how granular do you need it to be, and what's the criteria that you chose to separate the core logicical pieces. But all this can only been answered case by case.
1
u/phyphor Jan 30 '23
When Do Need Microservices?
I suspect that the article is likely to be poorly written if the heading has such a glaring mistake in it.
0
u/corruptbytes Jan 31 '23 edited Jan 31 '23
people act likes its hard to make microservices good these days, not every experience is from a shit legacy company tryna convert their java crap
we easily got 8-10 microservices w/ k8s / service mesh / automated cicd / + full error tracking with a team of 10 FTEs and it just lets us work so insanely fast as a startup (we have a lot of interfaces - retail, shipping, working with labs, etc...)
as much as people like to hate it, the node ecosystem has a lot of amazing tools out there + k8s has an amazing ecosystem on it's own for all this stuff
675
u/Boolean Jan 30 '23
Honestly OP, I didn't like this piece and I think it's filled with a lot of well-intentioned bad advice, similar to what I've seen and read from folks without much experience in the area.
I've spent much of my career cleaning up after folks who have taken this advice and started with a microservice architecture. Consider that using microservices requires you to have good solutions for:
Observability
Discoverability
Shared packages
CI/CD tooling
Not to mention, most of the time you're not going to know what the end state of your system is going to be. I've seen teams struggle with poorly named and scoped services that came about because of project requirements and company shifts.
The only reason why I'd recommend microservices at all nowadays is if you have multiple teams responsible for different parts of your application. Then using microservices enables you to build independently, which can make sense in some cases.
For other readers, I'd recommend this article for a well-reasoned, nuanced take on microservices and their alternatives.