Hacker News Reader

Comment by daxfohl | Hacker News Reader

This leaves open the question of what are microservices. Are they of necessity completely isolated units deployed with Docker and Kubernates on a CoreOS cluster and communicating only via HTTP each with independent databases? Yes this seems a bit much for most projects.

There are midway options though. Even the lowly batch job is a good way to get some of the decoupling without having to go "all-in". I find batch jobs and message queues give me 80% of the benefit of "microservices" with only 5% of the pain.

In fact someone needs to write an article on "levels" of "microserviceness", (which certainly has multiple dimensions and branches) and point out the benefits and drawbacks of each level.

Of course the end game being: "a Docker container for each line of code."

View on HN

> a Docker container for each line of code

Yes, this is the surest way for developers to guarantee the code itself is always bug-free. Everything becomes "just an ops problem".

2017 predictions: buzzy job title: Ops-Dev. Labview-style graphical programming http://www.ni.com/newsletter/app/largeimage?lang=en&imageurl... becomes the new hotness. Amazon and Google introduce new graphical programming workflow coordination services for lambda. Nothing ever gets finished.

(2018 predictions: google discontinues this service)

(2019 predictions: every machine instruction now belongs to its own docker package; the successor to Kubernates is marketed as a distributed asynchronous virtual CPU. Data centers begin requiring small nuclear stations to generate the electricity to power them. Still nothing gets finished).

(2020 predictions: someone rediscovers this "heroku" thing; things start getting done again. Hot new industry: nuclear waste disposal)

(2119 prediction: nuclear stations powering 2019's data centers are still running at full power but servers are all dormant; nobody wants to turn off a server "just in case").

"graphical programming workflow coordination services"

Those things are always sold to CIO types based on the idea that "you won't need developers" and then you end up with some eldritch graphical abomination where being being able to visualise things just makes it worse....

Draw a rough diagram and then write your code - fine, generate a diagram from code - fine, generate code from a diagram - nightmare.

For people who gawk at this LabVIEW screenshot: this is what actual LV production code looks like - the rule, not the exception!

In fact someone needs to write an article on "levels" of "microserviceness", (which certainly has multiple dimensions and branches) and point out the benefits and drawbacks of each level.

I think I might literally have a "SOA Maturity Model" slide laying around somewhere from my mid-2000's consulting career.

Let me know if you need it, ironically or not.

You're giving me flashbacks.

But the parallels are eerie. Someone gives a nomenclature to a style of architecture that many people were already using (just last week I heard that Netflix "invented" microservices), and suddenly the attention of the industry pivots. Technologies will be invented to ease adoption (yay!), but people will forget that this architectural style is one part of a solution for a particular type of problem -- it is not a solution for every problem, nor does adopting it mean all of your other problems will go away.

But consultancies will rise, debates will rage and conflicts over what truly constitutes a microservice will ensue.

conflicts over what truly constitutes a microservice will ensue.

So true. I feel like this has always been an issue in the "services" world. It's hard to nail people down on a definition that's both accurate and prescriptive. Either you end up with a definition that is so generic as to be unhelpful, or you come up with narrowly defined definitions that miss important use cases. I've decided that "services" is a word like jazz or porn or art: you know them when you see them.

My only wish is that we could, as an industry, find a way to better bootstrap our systems. We have a tendency to launch products / companies around bad ways of doing things and then spend a not inconsequential sum of money retrofitting everything.

It would be great to see tools and framework built from the ground up to address both developer productivity and scalability. It too often feels like achieving scalability comes at the cost of developer productivity... perhaps because by the time you need to scale, you've got enough resources to hire tons more developers and have them engage in menial tasks.

For sure there's a buzzwagon; and, true, microservices are just a kind of SOA (which itself wasn't new), etc.

What's different this time round is that microservice hosting should be much \cheaper\.

When you're cheap enough, all sins are forgiven.

I was just talking with a friend about batch jobs, and I was remarking that they can also be considered microservices. The difference is that batch jobs don't need to be interactive, so the contract is different.

Unfortunately it's a bit late for me to include this in the existing article, but it's a good topic for a next article. You will generally have a much easier time splitting tasks off and running them on workers than full-blown, standalone services (because the MQ can retry the tasks, they can be idempotent, you can have different timeouts, etc).

The usual definition of a microservice is a stricter subset of a task, in general.

Agreed. In fact batch jobs are, in at least one dimension, more decoupled than strict microservices.

Current client is a photobooth. Photos all can be shared from client app and web, each "share" is just a REST post containing "shareType:string" and "meta:json"; all share types (email, mms, twitter, etc) go through the same endpoint. Web api simply adds these to message queue for the corresponding "shareType" job to process. This way new types of sharing options can be added just by changing the client and adding the new batch worker; no updates to the web/api server app itself are necessary.

Proper "microservices" are usually described as being directly coupled to each other. They're just the new hotness so everyone wants a piece.

As most of the comments are saying, choose the shoe that fits.

> Are they of necessity completely isolated units deployed with Docker and Kubernates on a CoreOS cluster and communicating only via HTTP each with independent databases?

I'm pretty sure the Docker, Kubernetes, and CoreOS parts are unnecessary (as, IIRC, microservices started being discussed before those tools were available -- those tools were driven in part by microservices, but aren't essential to the model.)

HTTP is, likewise, unnecessary: its the most obvious protocol choice, but there is no reason that microservices must be HTTP-based -- you could have a set of microservices using just about any protocol you want.

And here again we will see the raise of the mighty, the glorious ENTREPRISE SERVICE BUS.

https://en.wikipedia.org/wiki/Enterprise_service_bus

Were are my mainframes ? I think I'll need them soon.

Maybe every module in a Monolith could also be considered a Microservice, with extremely fast networking and an extremely terse remote interface specification language.

Don't forget RPC with protobufs.

Reply on news.ycombinator.com