4 ms·

I was prepared to be convinced, what in our field does bring nothing but benefits? I didn't see much to worry about here though; * who cares if you're deployin

by cs02rm0 12y ago

I was prepared to be convinced, what in our field does bring nothing but benefits? I didn't see much to worry about here though; * who cares if you're deploying 20 services or 1 when you run your deploy script? * who doesn't have an operationally focused dev team? * who isn't already dealing with interfaces even if not micro services? * since when do micro services have a monopoly on distributed architectures or asynchronicity? I can't agree testing is harder either. Too much fluff in this article to read much value into it.

zwischenzug 12y ago
I've run such operational teams, and the benefits of monoliths are immense.
- cs02rm0 12y ago
  Fancy listing some then rather than just stating it? Better yet, write a more concrete article than the above and post a link to it.
tracker1 12y ago
I think that mentioning that many of these microservice environments tend to be polyglot environments or that infrastructure is a big deal. Moving towards containerized deployments helps at some levels and is more difficult at others. Having internalized heroku-like abilities goes a long way too.. it really depends. Even looking at Lambda as a service layer seems pretty nice... the bigger issue to me seems to be the coordination layers of these services. You have upstarts like etcd, along with the likes of zookeeper and others. Just the same, it takes a lot of effort. For the same note, you may want to just keep some more logical service/worker boundaries in place, and API all the things so to speak... that doesn't even mention caching and related issues. It depends on the environments.. when you are trying to introduce half a dozen platform/technology changes in a small company, it's not easy in terms of training alone...
ExpiredLink 12y ago
You can easily end up in microservice spaghetti like this application: http://www.infoq.com/presentations/scale-gilt http://www.infoq.com/presentations/scale-gilt scroll to 20:40
- ddorian43 12y ago
  A minute later, I think they create a service whenever they need a function.
  - ExpiredLink 12y ago
    Surprisingly, this application is presented as 'success story'.
ryanbrunner 12y ago
Regarding interfaces, dealing with an in-process, code level interface is just on the surface simpler than dealing with an external interface like a JSON endpoint. If you're working with a statically-typed language, the comparison isn't even worth making - a contract that needs to be extensively tested turns into a compile error. Even in a dynamically typed language, the tooling to test that methods are being called correctly are much more mature and developed than determining that two independent services are conforming to the same contract.
- ayrx 12y ago
  Just wondering out loud: maybe it's possible that tooling for this just hasn't been written yet? Something along the lines of declaratively stating what a JSON endpoint should be like and having a tool automatically assert that the services conform to that interface doesn't look impossible.
  - logicchains 12y ago
    F# could do this with type providers. Or, something like Google Protocol Buffers could be used.
    - cs02rm0 12y ago
      Or Java with JAX-RS. Or one of probably hundreds of alternatives.
  - jacques_chester 12y ago
    It's been tried many many times, but as a network service you simply have no way to enforce what messages you are going to receive until you receive them. So you have to type check at runtime. You can build tooling to make it easier to produce conforming software at each end, but you can't guarantee that someone won't just go ahead and write any old thing. So in practice you still perform validation on each message. Put another way: distributed systems turn all type errors into runtime errors. The guarantees of compile-time checking are severely weakened.
  - 12y ago

by cs02rm0 12y ago

zwischenzug 12y ago

I've run such operational teams, and the benefits of monoliths are immense.

cs02rm0 12y ago
Fancy listing some then rather than just stating it? Better yet, write a more concrete article than the above and post a link to it.

tracker1 12y ago

I think that mentioning that many of these microservice environments tend to be polyglot environments or that infrastructure is a big deal. Moving towards containerized deployments helps at some levels and is more difficult at others. Having internalized heroku-like abilities goes a long way too.. it really depends. Even looking at Lambda as a service layer seems pretty nice... the bigger issue to me seems to be the coordination layers of these services. You have upstarts like etcd, along with the likes of zookeeper and others. Just the same, it takes a lot of effort. For the same note, you may want to just keep some more logical service/worker boundaries in place, and API all the things so to speak... that doesn't even mention caching and related issues. It depends on the environments.. when you are trying to introduce half a dozen platform/technology changes in a small company, it's not easy in terms of training alone...

ExpiredLink 12y ago

You can easily end up in microservice spaghetti like this application: http://www.infoq.com/presentations/scale-gilt http://www.infoq.com/presentations/scale-gilt scroll to 20:40

ddorian43 12y ago
A minute later, I think they create a service whenever they need a function.
- ExpiredLink 12y ago
  Surprisingly, this application is presented as 'success story'.

ryanbrunner 12y ago

Regarding interfaces, dealing with an in-process, code level interface is just on the surface simpler than dealing with an external interface like a JSON endpoint. If you're working with a statically-typed language, the comparison isn't even worth making - a contract that needs to be extensively tested turns into a compile error. Even in a dynamically typed language, the tooling to test that methods are being called correctly are much more mature and developed than determining that two independent services are conforming to the same contract.

ayrx 12y ago
Just wondering out loud: maybe it's possible that tooling for this just hasn't been written yet? Something along the lines of declaratively stating what a JSON endpoint should be like and having a tool automatically assert that the services conform to that interface doesn't look impossible.
- logicchains 12y ago
  F# could do this with type providers. Or, something like Google Protocol Buffers could be used.
  - cs02rm0 12y ago
    Or Java with JAX-RS. Or one of probably hundreds of alternatives.
- jacques_chester 12y ago
  It's been tried many many times, but as a network service you simply have no way to enforce what messages you are going to receive until you receive them. So you have to type check at runtime. You can build tooling to make it easier to produce conforming software at each end, but you can't guarantee that someone won't just go ahead and write any old thing. So in practice you still perform validation on each message. Put another way: distributed systems turn all type errors into runtime errors. The guarantees of compile-time checking are severely weakened.
- 12y ago