Microservices

Post by aikah » Thu, Sep 15, 2016, 9:40 PM UTC

txutxu wrote: post #39

throwaway13337 wrote: post #15

Microservices, like nosql databases, and complex deployment systems (docker) are very important solutions to problems a very small percentage of the development community has. It just so happens that the portion of the community is the one most looked up to by the rest of the community so a sort of cargo cult mentality forms around them. A differentiator in your productivity as a non-huge-company could well be in not…

I see microservices as responsibility deduplication in a organization-traversal-wide. De-duplication is a very old concept (differentiates good "sysadmins" from bad ones, since the 90's, and good programmers from bad ones). Thinking organization-traversal-wide is what is hard for some persons. Currently working at consulting in a big corp... you get to this problem: Resource: name FooBar, type int (organization view…

Post by dragonwriter » Thu, Sep 15, 2016, 9:43 PM UTC

TickleSteve wrote: post #68

“You don’t need to introduce a network boundary as an excuse to write better code” Absolutely this! microservices is just decoupling by another name.... and you do not need a network-boundary to enforce this. Monolithic code can also be nicely decoupled too.

Post by aikah » Thu, Sep 15, 2016, 9:46 PM UTC

StabbyCutyou wrote: post #49

fishtoaster wrote: post #26

There's some good points here and some I disagree with. One area, though, where I think he misses the point, is: > Additionally, many of these stories about performance gains are actually touting the benefits of a new language or technology stack entirely, and not just the concept of building out code to live in a microservice. Rewriting an old Ruby on Rails, or Django, or NodeJS app into a language like Scala or Go…

One of the downsides of the blog post was that I adapted it from a lightning talk, so it was meant to be a little content-light, but to put ideas in peoples minds around how to think about the tradeoffs. For example, your point about Go vs Rails is an apt one - I would only add that I made that comparison because... A: It was originally a golang meetup where I gave the talk B: Go is increasingly becoming popular as a…

Post by naasking » Thu, Sep 15, 2016, 10:18 PM UTC

dragonwriter wrote: post #73

TickleSteve wrote: post #68

“You don’t need to introduce a network boundary as an excuse to write better code” Absolutely this! microservices is just decoupling by another name.... and you do not need a network-boundary to enforce this. Monolithic code can also be nicely decoupled too.

> microservices is just decoupling by another name.... and you do not need a network-boundary to enforce this. If code is decoupled enough that it can be separated into independent processes communicating over a network, that creates additional freedom into how the components can be deployed to (real or virtual) hardware, which is itself a kind of decoupling. If you have processes communicating by local-only IPC meth…

Post by oelmekki » Thu, Sep 15, 2016, 10:34 PM UTC

naasking wrote: post #76

oelmekki wrote: post #56

Instead of microservices, I split my projects in tons of libraries and think of them as products, enforcing a well thought of and consistent api (usage api, not http one). I call that an atomized monolith. I get the cool things about microservices: properly isolated functionalities, ability to assign a team on it, simplicity of code and considering each feature as important, not just "that thing in the codebase". But…

> Instead of microservices, I split my projects in tons of libraries and think of them as products, enforcing a well thought of and consistent api (usage api, not http one). I call that an atomized monolith. There's already a term for that: modularity.