5 ms·

Microservices, like nosql databases, and complex deployment systems (docker) are very important solutions to problems a very small percentage of the development

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 using these tools. There are exceptions, of course, where the problem does call for huge-company solutions, but they're rarer than most people expect.

eric_h 10y ago
Indeed. It's easier to change a monolithic stack while you're still discovering the actual architectural requirements of the particular problem you're solving. As you get a better understanding of how you need to handle things, where the performance bottlenecks are, etc., you can start breaking out pieces that would benefit from being isolated. It's extremely unlikely that in the short term (first year(s)) of the application being used that the engineering would benefit from a micro services architecture.
- collyw 10y ago
  That sounds like the obvious approach. Premature optimization and all that.
txutxu 10y ago
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 point) app1 name: FooBar type: int app2 name: foo_bar type: int32 app3 name: Foobar type: Meta::Foo::Bar app4 name: foobar type: string app5 name: fooBar type: int64 ... etc until app 35 and script 192679 Microservices, thinking transversely, solve that. See AWS, GoogleCloud, Azure, etc "resource names" (ARNs, etc), for an example of a simple and great microservice. Note also, that microservices experts (and I'm not one of those) recommend a monolithic and transactional core architecture, for microservices infrastructure.
- aikah 10y ago
  > I see microservices as responsibility deduplication in a organization-traversal-wide. AKA SOA. Why call it microservice ?
  - cmdkeen 10y ago
    The Newman book is worth a read - I'm going through it at the moment and a lot is applicable to SOA as well. Microservices is partially a re-branding exercise to take the massive space SOA covers and talk about a more specific definition. The main thing is the size of the services, the clue being in the name. Also there's a clearer emphasis on the services being more business related concepts, SOA can often described in more techy service splits rather than business concepts.
- ceslami 10y ago
  > Note also, that microservices experts (and I'm not one of those) recommend a monolithic and transactional core architecture, for microservices infrastructure. This is a pithy encapsulation of something I've been thinking a lot about recently: bud off a microservice from your transactional core if it is higher leverage to do so. Any good readings you've found on this perspective? An example that comes to mind is: I might write my core application in Ruby on Rails, but need to perform a specialized, CPU-intensive function (PDF generation). I can delegate that to a microservice, invert a CPU-bound problem into an I/O bound one (from the perspective of the Rails core), and get the job done with less hardware.
pbreit 10y ago
My company built from the ground up with micro-architecture and it is an unmitigated disaster. Totally unnecessary, mind-numbing problems unrelated to end-user features, unpredictability at every step, huge coordination tax, overly-complex deployments, borderline impossible to re-create, >50% energy devoted to "infrastructure", dozens of repos, etc. The whole thing could be trivially built as a monolith on Rails/Django/Express. But that's not exciting.
- johns 10y ago
  We were also built from the ground up with microservices and had the exact opposite experience. Faster shipping (more value to end users), more predictability (APIs designed/behaved similarly across functions despite polyglot tech), much less coordination overhead (deployed dozens of times per day with a < 10 dev team, pre-release backends well in advance of the user-facing parts), etc. We had to invest a lot in infrastructure, but that was worth it for many other reasons as well. Dozens of repos is annoying, but not for a technical reason (a lot of SaaS like Bugsnag and GitHub used to charge by project). The biggest downside is it makes shipping an on-prem version nearly impossible. The infrastructure and the software are so inextricably linked that it is not portable in the least bit.
  - dragonne 10y ago
    We ship a microservices-based product on-premises. You can do it, but it's a heck of a lot of work. Plus you don't get any of the benefits microservices might bring in a CD scenario: you can't do CD over an airgap.
  - wstrange 10y ago
    I think this is where Kubernetes has potential. You can bundle up those complex dependencies into deployment manifests, or use helm. It's like a SAAS in a box
  - parasubvert 10y ago
    One of the ways we managed to get a microservices system on prem (vSphere or Openstack) is to configure it with a system that can handle the whole provision/build/configure/deploy as a single unit: http://bosh.io http://bosh.io .. though the learning curve was steep.
aikah 10y ago
The problem with Micro-service is the notion of Micro. Services shouldn't be micro or macro but the right size. "Monolithic app" isn't a bad word, unfortunately some influential people tried hard to make it sound like it was.
xorcist 10y ago
In many ways it's just like micro kernels again. If micro services are the bee's knees, why are you writing them in Eclipse or Emacs? Wouldn't interconnected processes make up a "better" environment? An why are you deploying on something as monolithic as Linux? Shouldn't you out-compete all of these obviously inferior solutions, as there are probably more money in that than whatever web app you are currently building?
- jsmith0295 10y ago
  That's one thing I've always thought when people claimed microservices followed "the UNIX philosophy". UNIX doesn't even follow that philosophy, it's a monolith! Yet it's also a modular system, which is possible without being either a microkernel or microservices.
  - jamesblonde 10y ago
    Yes. For me, shared state in the Linux kernel is like a shared database between microservices. It makes life way easier, is faster, but you need to be careful you don't introduce subtle bugs.
  - mej10 10y ago
    The kernel is only one piece of a *NIX system. The userland tools are (mostly) a good example of small focused applications that can be combined in interesting ways.
    - jsmith0295 10y ago
      Yeah, that is definitely true. I was looking at it as effectively being a monolith that existed to facilitate that, but that does only apply to the kernel.
_pmf_ 10y ago
> It just so happens that the portion of the community is the one most looked up to by the rest of the community It certainly is the most vocal.

eric_h 10y ago

Indeed. It's easier to change a monolithic stack while you're still discovering the actual architectural requirements of the particular problem you're solving. As you get a better understanding of how you need to handle things, where the performance bottlenecks are, etc., you can start breaking out pieces that would benefit from being isolated. It's extremely unlikely that in the short term (first year(s)) of the application being used that the engineering would benefit from a micro services architecture.

collyw 10y ago
That sounds like the obvious approach. Premature optimization and all that.

txutxu 10y ago

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 point) app1 name: FooBar type: int app2 name: foo_bar type: int32 app3 name: Foobar type: Meta::Foo::Bar app4 name: foobar type: string app5 name: fooBar type: int64 ... etc until app 35 and script 192679 Microservices, thinking transversely, solve that. See AWS, GoogleCloud, Azure, etc "resource names" (ARNs, etc), for an example of a simple and great microservice. Note also, that microservices experts (and I'm not one of those) recommend a monolithic and transactional core architecture, for microservices infrastructure.

aikah 10y ago
> I see microservices as responsibility deduplication in a organization-traversal-wide. AKA SOA. Why call it microservice ?
- cmdkeen 10y ago
  The Newman book is worth a read - I'm going through it at the moment and a lot is applicable to SOA as well. Microservices is partially a re-branding exercise to take the massive space SOA covers and talk about a more specific definition. The main thing is the size of the services, the clue being in the name. Also there's a clearer emphasis on the services being more business related concepts, SOA can often described in more techy service splits rather than business concepts.
ceslami 10y ago
> Note also, that microservices experts (and I'm not one of those) recommend a monolithic and transactional core architecture, for microservices infrastructure. This is a pithy encapsulation of something I've been thinking a lot about recently: bud off a microservice from your transactional core if it is higher leverage to do so. Any good readings you've found on this perspective? An example that comes to mind is: I might write my core application in Ruby on Rails, but need to perform a specialized, CPU-intensive function (PDF generation). I can delegate that to a microservice, invert a CPU-bound problem into an I/O bound one (from the perspective of the Rails core), and get the job done with less hardware.

pbreit 10y ago

My company built from the ground up with micro-architecture and it is an unmitigated disaster. Totally unnecessary, mind-numbing problems unrelated to end-user features, unpredictability at every step, huge coordination tax, overly-complex deployments, borderline impossible to re-create, >50% energy devoted to "infrastructure", dozens of repos, etc. The whole thing could be trivially built as a monolith on Rails/Django/Express. But that's not exciting.

johns 10y ago
We were also built from the ground up with microservices and had the exact opposite experience. Faster shipping (more value to end users), more predictability (APIs designed/behaved similarly across functions despite polyglot tech), much less coordination overhead (deployed dozens of times per day with a < 10 dev team, pre-release backends well in advance of the user-facing parts), etc. We had to invest a lot in infrastructure, but that was worth it for many other reasons as well. Dozens of repos is annoying, but not for a technical reason (a lot of SaaS like Bugsnag and GitHub used to charge by project). The biggest downside is it makes shipping an on-prem version nearly impossible. The infrastructure and the software are so inextricably linked that it is not portable in the least bit.
- dragonne 10y ago
  We ship a microservices-based product on-premises. You can do it, but it's a heck of a lot of work. Plus you don't get any of the benefits microservices might bring in a CD scenario: you can't do CD over an airgap.
- wstrange 10y ago
  I think this is where Kubernetes has potential. You can bundle up those complex dependencies into deployment manifests, or use helm. It's like a SAAS in a box
- parasubvert 10y ago
  One of the ways we managed to get a microservices system on prem (vSphere or Openstack) is to configure it with a system that can handle the whole provision/build/configure/deploy as a single unit: http://bosh.io http://bosh.io .. though the learning curve was steep.

aikah 10y ago

The problem with Micro-service is the notion of Micro. Services shouldn't be micro or macro but the right size. "Monolithic app" isn't a bad word, unfortunately some influential people tried hard to make it sound like it was.

xorcist 10y ago

In many ways it's just like micro kernels again. If micro services are the bee's knees, why are you writing them in Eclipse or Emacs? Wouldn't interconnected processes make up a "better" environment? An why are you deploying on something as monolithic as Linux? Shouldn't you out-compete all of these obviously inferior solutions, as there are probably more money in that than whatever web app you are currently building?

jsmith0295 10y ago
That's one thing I've always thought when people claimed microservices followed "the UNIX philosophy". UNIX doesn't even follow that philosophy, it's a monolith! Yet it's also a modular system, which is possible without being either a microkernel or microservices.
- jamesblonde 10y ago
  Yes. For me, shared state in the Linux kernel is like a shared database between microservices. It makes life way easier, is faster, but you need to be careful you don't introduce subtle bugs.
- mej10 10y ago
  The kernel is only one piece of a *NIX system. The userland tools are (mostly) a good example of small focused applications that can be combined in interesting ways.
  - jsmith0295 10y ago
    Yeah, that is definitely true. I was looking at it as effectively being a monolith that existed to facilitate that, but that does only apply to the kernel.

_pmf_ 10y ago

> It just so happens that the portion of the community is the one most looked up to by the rest of the community It certainly is the most vocal.