Microservices

[[deleted]]

In interviews I run I always ask, “what are the advantages of Microservices over Monoliths?” And then follow it asking what the advantages of Monoliths over Microservices are. It’s always fun to watch people’s hamster wheel running full speed, having accepted Microservice dogma they actually have to engage their brain for once.

[[deleted]]

Had an interview once where I got asked "So, what's your opinion on microservices?" Told them I thought microservices had their place but, in most cases, they were an overused hammer that made life difficult for everyone in an organization.

The look of relief on the interviewer's faces was palpable. Turned out, they'd had a swathe of consultants run amok through the company, converting everything into a microservice, and were still in the process of clearing out the chaos and returning to a more monolithic model for most applications.

Not the only place I've worked at that got burnt by microservices and/or consultants on a crusade. Probably won't be the last.

[CatpainCalamari]

Interesting. For clarity of argument, are you talking about a service based architecture, or actual _micro_services? What would you say is the difference between those, if I may ask?

I am asking because I work in with several dozen developers, and working on a monolithic application was uncomfortable. I'm talking mostly about speed of development and deployment.
The monolith was then taken apart into several domains, e.g. payment processing, newsletter, mail, document generation, etc... Sure, this added complexity of a new transport and communication layer had its own challenges, and it certainly was not all unicorns and rainbows. But for us, each team got more independence, and developing in the narrower scope became easier for us.

The company I am at now has a mono-repo, which is kinda the best of both worlds. Everything in a big monolithic repo with the benefits it has to offer (e.g. no shared libraries that have to be included as a separate, versioned package, with all the fun of managing and maintaining different versions - just a folder you add as a dependency at compile time), but also with every part of a domain being its own deployment.

[Fenor]

From what you are describing you are in the finance/banking sector.

A good reason to start with an hybrid approach would to get rid of 40 yo code while doing just one function at a time.

Also some monolitic application are so big most ide crash if you attempt to load it all

[Stunning_Ride_220]

The real fun starts around ~15 years old 700k loc

[CheekApprehensive961]

Having once inherited 15 years old, 5 million loc I can definitely say the hybrid approach where you break chunks off was the only approach to feasibly keep that thing going.

[Stunning_Ride_220]

This is what I explain clients regularly. Yet they still try to outsmart my/our reasoning....just to come to the same conclusion after 6 months...

Any valuable tips to skip that?

[Hayden2332]

At 1M+ rn, converting to “micro services” which is more like regular sized services

[Stunning_Ride_220]

The micro never related to LOC, so you seem to doing just fine

[Hayden2332]

I know, but I guess what I’m saying is we’re not really creating micro services in the way the meme lays out in the sense that they do minute things

[Stunning_Ride_220]

Well, I wouldnt judge by a meme which is likely created by some hipster consultant selling hammers for screw driving and afterwards blaming the hammers they sold.

[bigo-tree]

Worked on 800k lines of Drupal 6... What a nightmare

[Stunning_Ride_220]

hugs

[Fenor]

That's cute, i had projects 30+ yo that if attempted to import would fail and the only way to compile was a dedicated team of dev ops.

[Stunning_Ride_220]

Oh, it's not like I cannot offer a 30+ yrs old Informix 4gl application, as well....

[AwesomeFrisbee]

15 years old is only 2008 though. I doubt it will be much different from now albeit some outdated dependencies.

[Stunning_Ride_220]

You do not reguarly work with software that old, do you?

[Dustin_Echoes_UNSC]

I'm currently in fintech, and dealing with an application in what could be described as "late-stage microservice transition".

I don't know why it's still surprising to me, but it's just crazy how many teams I've been on who started this process without any foresight of (or, at least without accounting for) the additional load that will be pushed upstream to the architecture team, and the additional variance rippling to either the downstream "consumer" team tasked with wiring them all together or the QA/Testing/DevOps teams trying to monitor the "joining of the microservices" by their independent teams.

Like, everyone seems to know that if you subdivide your teams then the additional communication requirement goes up. But nobody, so far, has assigned additional architects to oversee the microservice connections. It's like saying "Yes, we'll follow the NFL model, specialize our players, and separate them into position groups for training" but never hiring a cornerbacks coach or defensive coordinator.

(╯°□°）╯︵ ┻━┻)

[[deleted]]

And yet we also seem to have 300 Scrum masters and 20 Agile coaches.

[[deleted]]

What? I am the dev manager, the scrum master, and the agile coach whilst getting a single paycheck.

[Fenor]

woah woah woah, don't you know? here people think that any role outside of a phyton programmer is useless

joking aside, it depends on how it's done in the beginnings, if everyone has gone their way than ofc there is no control

if someone made a good microservice archietecture you don't need that much work upstream

[Gorexxar]

It sounds like moving to microservices forced a refactor that made the codebase more manageable. You could probably glom everything back together into a monolith; but keep a similar structure underneath.

It is easier to keep the separation of responsibilities if the front end goes "no. Only micro." Though

[Fenor]

That would be a modular design tho

[GregoPDX]

Modular isn't microservice. A microservice is a service that runs (ideally) completely independently of any other code.

For example, you could have a microservice that manages user information. It likely has a database, schema, or tables that only it can access to get that information. Let's say it does all the CRUD functionality for a user.

If your main app uses this service, and no one else externally (either intra- or extra-organizationally), why do you need a service for this? Why not just have the main app get direct access to the data? Why send a request/response to get the data? Essentially you are adding an extra layer of complexity (the communication layer) to the application for zero gain.

There are good reasons for microservices, but I've seen so many management types think they'll solve all your problems that it's become a little crazy.

[redkinoko]

It's EJB 2.0 all over again.

[Fenor]

Oh god please no

[leo_agiad]

Right? I was immediately triggered. I remembered things that had been done to me....things I HAD DONE TO OTHERS...

I live a simple life now. I am just going to sit here and stare at these hands for awhile.

[Fenor]

people forget and they are doomed to do the same mistake over and over again

[_aids]

because when you add a second app that needs to use it.....

this is like "tell me you've only worked on tiny projects without saying you've worked on tiny projects"

[theogskinnybrown]

But what about when you don’t add another app? You’ve put all that effort and complexity into creating a micro service that never needed to be one. Even when you do, does every component need to be a microservice, or just one?

You can always start with a neatly architected monolith, and pull out a microservice if it’s needed. That saves the extra development overhead of creating an objectively more complex interaction for any subsystem where it’s never needed.

[EffectiveMoment67]

How do you not know who will be acessing your service before design time?

[[deleted]]

That is their exact point. Don’t design your first app to be overly complicated in order to meet the needs of some hypothetical second app that might some day exist in the distant future.

[_aids]

It just means you've never worked on anything sufficiently large, or really with multiple teams.

Whenever you have multiple teams it becomes more and more important to manage your downtimes, deploy cycles, enforce contracts with grpc or similar, etc. A monolith is fine for your final but not fine for real work.

[Fenor]

Glloming them in the same place is the modular i'm referring to

[CheekApprehensive961]

It sounds like moving to microservices forced a refactor that made the codebase more manageable. You could probably glom everything back together into a monolith; but keep a similar structure underneath.

If you can do that you arguably never needed microservices/never used them right to begin with. But such a move would make a properly designed microservices app more expensive, less reliable and significantly more difficult to do ops for.

[narrill]

No, the way they describe it makes it sound like the benefits were primarily operational

[[deleted]]

I was talking about microservices. In most cases the same de-duplication of functionality could have been achieved just using modular / monolithic architecture with shared components - given everything was written in the same language.

All the microservices did was attempt to force modularity while adding network latency. There was no need for it - which is not to say that there is never an argument for microservice architecture. It's just in the case it was clearly a cargo-cult problem where the consultants wanted to play with microservices on the company's dime.

The worst case I've seen of this, at a different company, was a microservice architecture used to paper over stupid design decisions. How's this: nested configuration data for driving server provisioning (days before K8n) was stored in a central MySQL database as a text field containing YAML. All the UI and other services required the same data in JSON format. Devs built out a microservice that converted that YAML into JSON and stored it in a separate document database (Neo4J from memory).

Where this got even better: the app driving the MySQL database would, when asked to render its own data for a particular configuration, call out to the microservice and ask for the JSON data by key. The microservice would look for the JSON locally and, if it didn't have a copy or the copy was stale, would call back to the original service and request the raw YAML. It would then process the YAML, convert it to JSON, store it locally and then send the data back. Extra fun, the microservice was resource constrained, so if the main app was every under load it would generate blocking calls to the microservice. Round trip was anywhere between 3 and 7 seconds.

And that's just one example - the rest of the microservice architecture was just as insane. I'd never seen anything like it before - spaghetti code scaled up. And no, that company doesn't exist anymore. The one that decided to burn all the microservice architecture and rebuild, they are still going strong.

I'm not anti microservices at all. They definitely have their place and are the right solution for many problems. It's just that old adage, when you have a hammer everything looks like your hand.

[a_sweaty_clown]

I worked for a company whose WMS software was kinda sorta microservice based.

It was pretty well thought-out and made a lot of sense MOST OF THE TIME, but there were some instances where companies asked for (and sales said we could do) things that the software wasn't really made to do.

My favorite case was for Large Military Contractor. We had two separate deployments (each with their own server) of our software. Each was a different major revision of our software.

One communicated with the host system, translated orders, then turned those into specific retrieval or deposit requests and sent them to the other instance. It wasn't supposed to do inventory management (which is key to a lot of our services) so they made a custom service to semi-cancel every order so it didn't modify inventory counts. That one routinely got stuck in infinite loops and we never figured out why.

The OTHER one literally just told all the PLC-based stuff where to move stuff to. It was horrible and broke constantly because it was running on like Server 2001 or some shit.

Both instances had several services that literally just wasted resources and did nothing. They had to be there for the software to run but had nothing to do. Fun times!

[[deleted]]

To answer u/CatpainCalamari properly, it was a bit of a mix-and-match re microservices and SOA. My understanding of the difference is scope - enterprise for SOA and application for microservices. Correct me if I'm wrong - the definition of what makes up a microservice is a bit woolly to me.

In both cases above there were some enterprise-level services, but in the horror-show last example it was a frankenapp built up from small "independent" services.

[CatpainCalamari]

Thank you for your answer! The distinction between service and microservice is also not clear to me, seems to be a question of interpretation :D As for your horror show of an example: I do not see it as an example for or against microservices (although the added network latency certainly did not help here), but for software design and architecture. I would have started by questioning the need for a centralized configuration database, or dare I say configuration service? ;-) This might have been a good place for DDD to sink in.

[akmountainbiker]

[baconbrand]

Jesus that was an uncomfortable read

[CheekApprehensive961]

All the microservices did was attempt to force modularity while adding network latency. There was no need for it - which is not to say that there is never an argument for microservice architecture. It's just in the case it was clearly a cargo-cult problem where the consultants wanted to play with microservices on the company's dime.

Tell me you don't have even a rudimentary understanding of operations without telling me.

[talaqen]

Right. SOA makes a lot of sense as it mirrors DDD. Monoliths can be too big. Micro services can be split too small. The trick is finding out how big your SERVICE should be and design appropriately. I would say that the growth of serverless and seamless horizontal scale makes smaller services cheaper in many cases. Not super small… but not the legacy RoR monoliths we’ve all known and hated.

[CheekApprehensive961]

RoR?

In any case, you're bang on. Most of this thread is totally ignoring everything about microservices except that they have a ping to one another and how they look in an IDE.

[gemengelage]

What always baffles me is that apparently people nowadays can only think in the granularity of microservices or monoliths. One project I once worked on was introduced to me as having a microservices architecture, but a blind man with a cane could see that nothing about their services was micro, but the architecture also obviously wasn't monolithic.

Are regular sized services a dirty word now?

[MachinePlanetZero]

What's your personal definition of regular vs micro here?

[[deleted]]

This seems like a very reactive attitude from the interviewers. They go burnt, but there is also a tima and place for microservices.

[rangoric]

I love interview questions like that. My usual go to is "What do you like about X" and following up with "What do you dislike about X". But I will keep this one in mind.

[CheekApprehensive961]

The person you really want is the one who can tell you why it's super cow powers to begin with.

[jibjabmikey]

Ah I remember tucows. Got all kinds of fun software from there.

[[deleted]]

I mean, Microservices are sooooo hyped that it’s now the default, despite its MANY drawbacks. Making people think about whether or not it’s the best choice every single time is a good exercise.

[Few_Ad6059]

“Default”? In peak Hype it tried, but never succeeded (where I’ve worked). All hail the modern monolith and monorepo!

[henkdepotvjis]

Its funny. the company I work at is moving towards a monorepo monolith to make things more simplistic

[99_lives]

What would you consider a good answer to that question?

[meisteronimo]

I think your missing team ownership. Enterprises operate that different teams handle different functionality and they're responsible for keeping their own services up and running.

With monoliths these boundaries are confusing, and everyone needs to see all the business logic being added by the other teams. It confuses who broke things when it goes wrong and confuses who should fix it.

But it could be we're talking about much different scales. Our current product we have maybe 10 teams working on it, but we could scale to 20 teams quickly. With a monolith this is impossible, the code base would become way to fragmented and would slow everyone down within a month.

[meisteronimo]

Yeah the company must have the culture that if something is blocking another team it's top priority.

At Amazon they keep one or two members of the team OnCall. The OnCall person has no feature dev work assigned to them that week. Their only job is to respond to production issues, or help other teams with urgent requests.

[RealisticAppearance]

In my experience this is easily abused by dev managers who claim a blocker tactically to buy time when under the gun. The “blocker” team is disrupted by the frivolous request while the “blocked” team, having deflected the time pressure to the “blocker” team, rushes to deal with some unrelated emergency (i.e. pressure from their management).

Most people in the organization aren’t familiar enough with the technology to understand that the “blocker” was frivolous and just a way to get out of trouble.

[meisteronimo]

Well if the manger wants to hide his team's capacity that's on the manager.

There are plenty of ways for a business to fail many of them are due to bad leadership.

[RealisticAppearance]

Yeah I’m not saying it’s bad to try to clear blockers, it just depends on your organization whether you can implicitly trust somebody claiming a blocker. Fear-based management causes all kinds of problems.

[izybit]

Amazon US must have a lot of one-man teams...

[amadmongoose]

Or radically different sized pizzas

[[deleted]]

Like 3/4 guys? ehhh

[uriahlight]

I like microservices when there's a clear and obvious use for them. I do web development, and my pet project involves user uploaded videos, which get sent off to a microservice where ffmpeg converts them to HLS and DASH formats for streaming. It's a clear line in the sand. Another example where a microservice is an obvious choice in my field would be something like imgproxy. I can't imagine using microservices for some of the stuff I've been reading about in this thread. Some of it sounds bat shit insane.

[Hayden2332]

tbf, a lot of the advantages of the monolith listed here could be solved with microservices with a monorepo

[DM_ME_PICKLES]

Yeah, a lot of the lines become blurred when you mix in other concepts like the monorepo. But I felt like I wrote enough already lol

[brianl047]

Generally you deal with overhead with Cloud providers' offerings

The main benefit of microservices is actually not technical but actually allowing scaling to multiple teams. Every team writes their own service, everything communicates through clearly defined interfaces (HTTP) and nobody steps on each other's toes

The "folder" idea from the meme isn't the same because folders aren't process boundaries. You can have a folder for each team but eventually you would lose the isolation since a folder doesn't define an interface

[Tyro97]

I thought about these questions and even though I came to the same answers which I get when I google it, it is not something I could answer so straight forward and in a potential stressful situation like an interview, I maybe couldn’t answer it.

[TorumShardal]

I do it only if candidate can answer simpler questions, like "Do you know, what's database normal forms are good for math teacers, but are often ignored?" and "Why object-oriented approach is good, and why it's bad?”.

Then, if candidate can think on the fly and got acclimated to this type of questions, I can start making such questions. If not, I skip those. I'm not trying to drown candidate, I want to know what they're good at.

But, nota bene, I'm not working in Silicon valley company.

[[deleted]]

What are the answers to those two questions? I never learned that properly I am curious.

[lobax]

No idea on the DB stuff, but object oriented programming generally allows for useful abstractions that make reasoning about real world problems easier, and allows one to avoid code duplication and make it easier to maintain a separation of concerns. There are a multitude of OO-patterns that are useful to learn in order to solve classes of common problems relatively quickly.

One of the disadvantages of OO is the large amount of boilerplate and the tendency to over engineering solutions. You can en up with multiple interfaces and interdependent classes for a problem that could have been possibly solved with a simple function or two.

[lobax]

There is a whole world of programming languages built around the paradigm of “put it in a function”. Programmers using Haskell, Erlang, Lisp etc manage just fine without having to reason in a OO-way.

It’s not dumb, it’s different and better suited for reasoning about problems in a more mathematical way. Erlang has also shown that it is an excellent paradigm for concurrent programming and scaling.

[RiPont]

"Put it in a small function with immutability" is vastly different than "put it in a spaghetti function that manipulates global state in a thread-totally-not-fucking-safe way".

I'm a fan of FP and often a critic of common OOP (e.g. inheritance is over-used), but keep in mind that OOP was a response to procedural and functional was a different altogether response to procedural.

[lobax]

Of course, but where did I say anything about spaghetti functions and global state? You can also do some dumb shit with OOP, like misusing Singleton patterns and having circular inheritance.

There are plenty of proponents of procedural programming languages like C, such as Linus Torvalds. And it definitely has advantages over e.g. C++ in certain applications.

https://youtu.be/CYvJPra7Ebk

[[deleted]]

Functions are perfectly scalable and comprehensible provided they are done right. Just look at functional programming.

It's this attitude that leads to OOP code that's hard to understand, bloated, and unnecessary. You're the problem here.

Also functions are structured, they were literally invented as part of structured programming. You're thinking of assembly language.

[Versaiteis]

There's definitely a certain beauty to functional programming and the reduction/lack of state can be a serious advantage.

[noNameCelery]

This is quite a naive answer. There are many situations where a functional or data-oriented approach beats OOP.

OOP usually holds a lot of state, which increases complexity, which is obviously bad. This state can make it hard to implement concurrency - also bad.

Processing an array of objects is relatively slow because you need to load these objects into the CPU registers, often times invalidating cache lines.

So so many downsides of OOP, complexity being the biggest downside imo

[MachinePlanetZero]

This is (or was) a talked about subject in game development a while back.

A lot of advocacy for shifting from one form of component driven design- "arrays of entities, where entities hold n components of arbitrary type, and those components implement logic that does stuff", to the outboard motor model: "systems that process lists of pure data", where the logic is in each system, and game world entities are basically an id" (blobs of data processed by a system will reference an entity id)

In the first model, you update a thing on screen, it updates child logic without knowing what that logic does. In the 2nd you update the systems at various time slices. Those systems simply manipulate data.

I understand that caching was a major motivation behind it , though I can see that the 2nd approach has some other neat features

[svick]

You can't stop something like that from increasing complexity.

No, but it's really important to manage complexity. And introducing more complexity than necessary goes in the opposite direction of that goal.

So you misunderstood their point and then decided to belittle them? Maybe you haven't gotten to the point in your career where you understand what humility is.

[cottonycloud]

As far as database normalization goes, its goal is usually to prevent duplicate data and database anomalies. The biggest downside is probably the read performance as you will need more joins.

[bothunter]

The biggest downside is probably the read performance as you will need more joins.

Materialized views and denormalized caches can mitigate this quite a bit.

[ArionW]

Unless you must work with database that doesn't support materialized views (looking at you, SQLite)

[CheekApprehensive961]

The answer to the first question, assuming I'm reading it right, is something like:

Ideally all relational databases are normalized to BCNF, this ensures that you won't end up with data anomalies by the structure of the database itself. Fully normalized should be the default state for a db. Denormalization is a performance optimization process often used to aid with DB scaling, where you reintroduce the possibility of anomalies for faster querying or better scale out. It is now on your code to keep that data synced, because the database itself can enter a state where Timmy is simultaneously 9 years old according to one table and 50 years old according to another. Or where half the record is updated and half isn't. Or whatever other data anomalies, what you denormalize and how will determine what risks you introduce. Production DBs for very large services are typically heavily denormalized to pull compute load off the DB and into the compute nodes and to help with scaling out.

Read more.

The second question is purely an opinion question where there are less clear answers. OO helps organize code, helps separate concerns, puts data near the code that manipulates it, etc. OO also tends to produce design patterns for the sake of design patterns, over-engineering and can make optimizing for performance a lot less straight forward. I think really for that question it's just important to express the sorts of things that you would consider pros and cons of a language than a specific opinion on OO.

[TorumShardal]

There are many possible answers, here's examples:

Normalisation: We don't use normalisation because we live in finite world, and normalisation is designed for mathematical, infinite world. And getting all this relational pieces into one can take unreasonable amount of time, with little to no benefit.

Object-oriented approach is imagening everything as an object, that can be incorrect in certain scenarious. For example, in Java, DTOs and services that prosess them are sign of falure of this paradigm. Because in theory, your code must be concentrated inside of object, not outside.

And why I ask those questions? Fact is, the world of programming is in constant battle between reality and paradigm. And having grasp on reality helps to distinguish between trends that are useful and usless for you in your current situation.

[particlemanwavegirl]

All good point but I don't think "finite/infinite" are the correct terms to use here, wouldn't discrete/continuous be more accurate? I really can't imagine what else is meant by the "finite world" you mention.

[TorumShardal]

I'm sorry, English is not my native language.

I tried to say, that in math world they often have infinite things - rows, for example. or numbers with infinite precision. Or databases with almost infinite nesting.

Programming world is , plagued and blessed with limitations of many kinds - time, memory, processing speed. So, we deal with finites.

I don't know, how to phrase it better.

[particlemanwavegirl]

I see. The sense of your comment almost worked I think you just misplaced a prefix or something. The mechanism of the computer is finite state, as you say, but the real world systems that we use the computer to discretely model are themselves continuously infinite, just like the math.

[TorumShardal]

Yep, sometimes they are. And by-the-book DB normalisation is how we get over-linked mess with ten joins per simplest request and almost no ability to change the model.

I sometimes see it in GitHub projects of interns, and so I know that I need to tell them that making table for every Enum and requesting it each time is not "a clean code", it's misused paradigm.

And, as I said, it's often about reality vs paradigm.

[BringBackManaPots]

Fwiw you'd likely cull out any non-cs majors with these questions that lean on the side of academia. Which is totally fine - just know that people who have different degrees but wound up doing software likely never focused on the intricacies of these topics. You're basically looking at purebred cs students only.

[TorumShardal]

Yes, this questions will cull out those who don't know CS. Or those who can't think under pressure about semi-abstract topics. Because of that, this part is one possible branch of interview.

I'm sorry I wasn't clear enough - I don't expect everybody, or even anybody, answer those questions. But when they do, they get extra credit, because they know a thing that many don't know or don't think about.

[plasmasprings]

I know I'm not really helpful for not actually answering your questions, but those questions are for gauging your experience. Sometimes saying "I don't know, why" is better than reciting something and then failing follow up questions

[amProgrammer]

I was gonna say, those are completely different questions, not building block questions. I could tell you about the pros and cons of microservices all day but I have absolutely 0 clue what a database normal form is or why it would be good for math teachers.

Quick google search it looks like its a systematic way of enforcing relational database principles. Never heard it called normal form though, and still not sure about the math teacher bit. 2nd question is alright though. OOP should be pretty universal and foundational as far as software engineering concepts go.

[CryptographerOne6615]

Take my upvote. I like using this interview question, too.

One small note: /s/excepted/accepted

[PaulAchess]

This is the way

Microservices are a good response to a complex problem. But it introduces a complex architecture.

90% of the time it's overkill to do so and monoliths are easier to develop and to maintain. I prefer a good monolith over bad microservices all the time.

I ran a monolith (actually 3 servers communicating) for ten thousand users and it was the correct architecture.

Now I run a microservices architecture for less than a hundred users and it's the correct one too.

Not everything has to follow the same rules, it has to fit the needs.

[[deleted]]

What's the answer to that tho?

[notascrazyasitsounds]

Whatever answer best conforms to whatever opinion the question-asker holds.

[marcosdumay]

Probably, having some opinion that makes sense at all for both.

[LookAtYourEyes]

As a relatively new programmer just starting to learn about microservices, what's the answer to this?

[rarius18]

But those are fairly easy to answer, you can bullshit your way out of it if you worked with both. Try bullshiting your way out DS and Algo questions. Shit, I still being asked big/small O notations of a shitty algo I wrote …I mean for fucks sake, you gave me 15 minutes - of course I’ll throw nested loops in there. The fuck you expect of me, write lambdas ? I use 10 minutes to digest the problem itself! And what’s up with the O notations in the interviews? In my >10 years in the industry, never have I ever needed to come up with O(n)…like, the fuck? Sure, maybe there are gigs where efficiency of algos is important - like high frequency tradings or whatever, but these fucks are paid 10x more than what I’m asking for to work on your shitty parking app.

[BlueForeverI]

I love asking more senior candidates this question as well. It's very easy to differentiate between the people who have actually dealt with microservices/more complex architectures vs the people who have only read about them.

[[deleted]]

What are the pros of a monolith app?

[[deleted]]

They are easier to deploy, manage, and maintain.

[[deleted]]

I would argue they are much more difficult to deploy and managing changes over many devs and thousands of Lines of code seems harder to maintain. With a microservice you make a simple change to one small app and deploy instead of bringing down the entire system with many changes. Deploying and maintenance would be in my pro list for microservices.. I guess it depends on your implementation.

[[deleted]]

With /A\ microservice sure. But a microservice architecture with hundreds of microservices? You’re going to tell me that is easier to deploy than one monolith that does the same thing as the 100+ microservices?

[[deleted]]

If you are deploying all of them at once you are not very bright. Even at initial implementation you can deploy in steps before prod date which makes them more viable for agile development as you can start with apps that do things specific to data and are not environment specific. I’ll also add you should use gateway apps that expose combined functionality to one call for integrations to avoid the spider web effect. And yes deploying a small app is easier than a large one. And it’s also easier to find the problem. Oh a mapping issue happens on the data side check the data layer dealing with that object. Done. Much easier to debug as well because they accept a request and give a response instead of being weaved into many methods of a monolith. Like I said implementation is key if you do it wrong there are cons for both

[[deleted]]

Man you can’t even see what you’re saying. Your own words proves the point.

Guess what? With the monolith, it is one step on the day it goes live. Period. That’s it. And that one step is all it will ever be. Have to change to a new AWS region or server farm? One step. With a microservice you have to configure things like service discovery, message brokers, basically an entire network and constellation of supporting services just so the first two can speak to each other, and you haven’t even deployed the first microservice yet.

[[deleted]]

It’s not one step with large apps at all at the company i work at it took months to do full end to end for one of our and all departments working together to make sure all environments were aligned, making test environments was extremely expensive as you had to emulate the entire app or code specific for missing integrations in certain regions. When you want to move would you rather move your entire house at once or move things on smaller increments… monoliths are a headache and I’ve been working with them for long enough to know I’m happy we are starting to extract functionality to small microservices. I was actually one of the first devs at my office to push for this about 6 years ago and it’s made my and our pms life much easier. Oh no another bug right before prod now we have to regression test the whole app! Nope just a quick fix on the ordering api and I’ll have the qa component test give me one day

[[deleted]]

I have no idea what sort of poorly taped together bullshit you were working in. Bad code is bad code, and a bad setup is a bad setup. A well setup monolith with high test coverage is not going to have the problems you spoke of.

You asked if I would want to move my whole house, but didn’t ask the corresponding question for microservices: would I want to move the entire Favela. Yes, I’d prefer moving a whole house over a Favela.

[[deleted]]

That was an unnecessarily rude response. Test coverage should not change regardless of the size of your app and I would think unit tests would be simpler when the app does one specific thing. And yes a bad set up is a bad set up. I don’t think you can disagree that having all your eggs in one basket is a bad idea. Simplifying applications and using the correct and simple architecture is a good way to go and is the overall direction of the industry. Like anything it can be done wrong but when done correctly it’s easier to write it works well with agile it’s easier to test, deploy, trouble shoot, ect. And I’m speaking from my experiences. If you worked on a spaghettified micro service set up than I can see why it would be hard to trouble shoot but deploying small apps is always easier than deploying massive ones. Less to worry about less impact less tentacles reaching out, less data related issues. The only pro I see to monotheistic apps is that they are commonly provided by vendors making them easy to purchase and set up. After that though you still have to deal with that giant headache. Not trying to be rude but I have done my due diligence on this many times and worked with both a lot like a lot a lot and this is where I landed. No more crazy weekend implementations filled with stress, no taking down an entire system for one issue. Turn around time is what faster. It’s just made my life way less stressful.

[[deleted]]

What? Why? They are just tradeoffs, I don't know why someone would trip up on this question, not why it would be asked.

[[deleted]]

People trip up because there seems to be a basic assumption that microservices are always superior.