Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lessons Learned While Building Microservices

blog.runnable.com

Post reply on HN
Print view View original

11–20 of 27 posts

Re: Lessons Learned While Building Microservices

#11

Post by Retric »

throwanem wrote: post #10
Retric wrote: post #8

Earlier quoted context omitted.

Microservces enforce some separation of concerns, but Monoliths can use the same approach without nearly as much complexity. Overall, I find microservices to add a huge range of new failure modes for little net gain. The sweet spot seems to be services where large chunks of the application operate independently. 10 services are manageable, 100 are not.

> Monoliths can use the same approach without nearly as much complexity Do they? > The sweet spot seems to be services where large chunks of the application operate independently. Which could be said to be a design choice in many cases, perhaps even most.

> Do they?

Ideally OOP should treat each object like a microservice with an interface, independent data store, and test suite. I have seen several applications that do this, but a big ball of mud is also common, so it depends on the team.

PS: IMO, I think something is lost when languages don't have both objects and records. Passing around structured data can make for a clean design, but people get stuck on the idea that data and computation must be linked which makes it harder to have clean separation between different parts of your application. Function X is used by A, and B so now you can't change X without impacting A and B. Wait if we make a sub class then...

Re: Lessons Learned While Building Microservices

#12

Post by spriggan3 »

throwanem wrote: post #5
ChemicalWarfare wrote: post #4

So while I'm not anti-microservices, from the developer's perspective sometimes there's just way too many moving parts. one code change+one test change back in the "monolith" days (and if the change broke the existing tests you know right away) now becomes an ordeal. Tracking down the client services/altering their code + tests+ simulators (not to mention that you now have to check the code out from bazillions of rep…

I've done a lot of work on monoliths, and a fair amount with microservices. I've never observed the perceived simplicity of the former to bear out in practice; there's just as much complexity, but instead of being reasonably well contained and prevented from spilling across service boundaries, it's smeared all over the application, so being confident you've tracked down and addressed all of it is much more difficult…

> it's smeared all over the application

How about writing libraries with clean API and encapsulation ? because basically your argument is "Our developers aren't disciplined enough to write clean API, so we need to force it with http calls ...".

Re: Lessons Learned While Building Microservices

#13

Post by throwanem »

Retric wrote: post #11
throwanem wrote: post #10

Earlier quoted context omitted.

> Monoliths can use the same approach without nearly as much complexity Do they? > The sweet spot seems to be services where large chunks of the application operate independently. Which could be said to be a design choice in many cases, perhaps even most.

> Do they? Ideally OOP should treat each object like a microservice with an interface, independent data store, and test suite. I have seen several applications that do this, but a big ball of mud is also common, so it depends on the team. PS: IMO, I think something is lost when languages don't have both objects and records. Passing around structured data can make for a clean design, but people get stuck on the idea t…

Ideally a lot of things would be other than they are. There's a cogent argument to be made that the microservice architecture offers value in making a big ball of mud harder to create. Of course, there's also a pertinent question to be asked about whether one big ball of mud is really that much worse than several smaller ones flying in loose formation.

"It depends on the team" is probably about as close as it's possible to come to a single right answer here.

PS: I absolutely agree.

Re: Lessons Learned While Building Microservices

#14

Post by dominotw »

ChemicalWarfare wrote: post #4

So while I'm not anti-microservices, from the developer's perspective sometimes there's just way too many moving parts. one code change+one test change back in the "monolith" days (and if the change broke the existing tests you know right away) now becomes an ordeal. Tracking down the client services/altering their code + tests+ simulators (not to mention that you now have to check the code out from bazillions of rep…

your comment reminds me of this tweet

https://twitter.com/honest_update/status/651897353889259520

  We replaced our monolith with micro services so that every outage could be more like a murder mystery.

Re: Lessons Learned While Building Microservices

#15

Post by catnaroek »

throwanem wrote: post #5
ChemicalWarfare wrote: post #4

So while I'm not anti-microservices, from the developer's perspective sometimes there's just way too many moving parts. one code change+one test change back in the "monolith" days (and if the change broke the existing tests you know right away) now becomes an ordeal. Tracking down the client services/altering their code + tests+ simulators (not to mention that you now have to check the code out from bazillions of rep…

I've done a lot of work on monoliths, and a fair amount with microservices. I've never observed the perceived simplicity of the former to bear out in practice; there's just as much complexity, but instead of being reasonably well contained and prevented from spilling across service boundaries, it's smeared all over the application, so being confident you've tracked down and addressed all of it is much more difficult…

Microservices are a great idea in principle. In practice, they require you to spend way too much effort (IMO) on:

(0) Serializing and deserializing objects. (At least if you're not using something like Erlang.)

(1) Validating things that would be considered internal invariants under a more monolithic design, simply because they lie on a service boundary.

Not to mention microservices constrain your API to what your transport (often HTTP) can readily express (which is often not much). If you're used to working with expressive languages, the expressiveness drop can be very annoying.

Re: Lessons Learned While Building Microservices

#16

Post by erikcw »

Does anyone know of a good resource for learning microservices best practices? We're at a stage at my company where it makes sense to consider the transition from a monolith -- but would love to do the right homework first to avoid some of the pitfalls.

Re: Lessons Learned While Building Microservices

#17

Post by derrekl »

One of the stated lessons learned is: we'd still be on node 0.10 if we weren't using microservices. I've worked a lot on huge monoliths and microservices. Being "stuck" on a version has less to do with monoliths/microservices than it does consistent update practice. If you are using FOSS and schedule periodic updates of the core language and the apps dependencies you'll prevent yourself from getting stuck on old versions. If you run across some dependency that isn't working on version X of the core language you can open tickets against it and/or schedule updating the dependency yourself (this doesn't go away with microservices). Opening tickets against dependencies as the core language updates helps both you and the dependency owner by helping them test and get out ahead. Not only will you prevent from getting stuck on old versions but you'll also have the latest security updates. Note: you don't have to be on the bleeding edge but you should strive to be, in my opinion, no more than 6 months or so from the edge.

Re: Lessons Learned While Building Microservices

#18

Post by throwanem »

spriggan3 wrote: post #12
throwanem wrote: post #5

Earlier quoted context omitted.

I've done a lot of work on monoliths, and a fair amount with microservices. I've never observed the perceived simplicity of the former to bear out in practice; there's just as much complexity, but instead of being reasonably well contained and prevented from spilling across service boundaries, it's smeared all over the application, so being confident you've tracked down and addressed all of it is much more difficult…

> it's smeared all over the application How about writing libraries with clean API and encapsulation ? because basically your argument is "Our developers aren't disciplined enough to write clean API, so we need to force it with http calls ...".

If discipline were the sole answer required for every problem in programming, many things would not need to exist.

Re: Lessons Learned While Building Microservices

#19

Post by throwanem »

catnaroek wrote: post #15
throwanem wrote: post #5

Earlier quoted context omitted.

I've done a lot of work on monoliths, and a fair amount with microservices. I've never observed the perceived simplicity of the former to bear out in practice; there's just as much complexity, but instead of being reasonably well contained and prevented from spilling across service boundaries, it's smeared all over the application, so being confident you've tracked down and addressed all of it is much more difficult…

Microservices are a great idea in principle. In practice, they require you to spend way too much effort (IMO) on: (0) Serializing and deserializing objects. (At least if you're not using something like Erlang.) (1) Validating things that would be considered internal invariants under a more monolithic design, simply because they lie on a service boundary. Not to mention microservices constrain your API to what your tr…

I've never run across a microservice architecture that involved passing objects across service boundaries. Data records, yes, but if those are expensive or painful to serialize or deserialize, I'd say that's the first problem to solve.

Re: Lessons Learned While Building Microservices

#20

Post by vkjv »

erikcw wrote: post #16

Does anyone know of a good resource for learning microservices best practices? We're at a stage at my company where it makes sense to consider the transition from a monolith -- but would love to do the right homework first to avoid some of the pitfalls.

I highly recommend reading Martin Fowler.

http://martinfowler.com/articles/microservices.html http://martinfowler.com/eaaDev/EventSourcing.html

Post reply on HN