Hacker News Reader

Comment by cs02rm0 | Hacker News Reader

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.

View on HN

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.

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.

F# could do this with type providers. Or, something like Google Protocol Buffers could be used.

Or Java with JAX-RS. Or one of probably hundreds of alternatives.

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.

Apache Thrift? the issue is introducing yet another layer of indirection in an application. I'm personally not fan of micro-service architectures that don't use a coherent set of language(s).

But the tooling is already here,no question.

The issue is,should it be "baked" into a language?

Just because an interface asks for a String parameter doesn't mean you can't send data through it that won't be caught at compile time.

Neither does it mean that you can't have an actual Java interface exposed as a JSON endpoint.

By definition, any problems sent to a JSON endpoint necessarily needs to be caught at runtime. You can build up all sorts of defences up to the point of the service boundary, but at some point, something is going to be accepting messages from unknown or little-known services expressed as JSON documents and not a statically-typed interface. That's a pretty fundamental difference in my mind.

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...

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

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.