Elasticsearch is a great example of a modern monolithic application | Hacker News Reader

Elasticsearch is a great example of a modern monolithic application

twitter.com

104 pointsDVassallo16 comments

Except by itself it does little? Something needs to add documents and something else needs to search indexes. A typical ELK deployment has logstash and kibana as well. ES is a component.

But yeah...having used similarly designed apps(including a lot of apache project apps),it is a good design but only because of the specific use-case. Full blown apps (like ones that would use ES as a backend) might need to be non-monolithic.

Curiously,does the author consider docker-deployed apps monolithic?

Author here. The "monolith" I'm describing is an application-level characteristic. The deployment container, whether it's a bare metal server, a VM, or a Docker container doesn't matter.

I admit that my definition is not necessarily universal, but IMO the characteristics I listed are all highly desirable. I pushed for this model when I worked at Amazon (an AWS service as 1 monolith) and I've seen it work great even at large scale (close to 10K hosts, millions of requests per second, etc).

Interesting,thanks for clarifying.

I’d say most of the properties you mention are highly undesirable, especially monorepo and single executable. But regardless, I think monolith has to be defined at the behavioral level: does one system perform multiple completely independent behaviors? Must you change the same singleton codebase/artifact to effect two totally separate concerns? And indeed this is basically why all types of “mono” workflows (monorepo/monoapp, whatever) are intrinsically bad designs. That you can solve problems in spite of this through intense extra scaffolding bolted into the mono stuff is not any type of endorsement that it’s a good way.

> A typical ELK deployment has logstash and kibana as well.

Now that we have tools like docker-compose, would it not be possible to spin up all the dependency apps in a single command, so as to preserve the character of a monolithic app?

Sure, and I have done just so. But you usually want kibana on a separate host for HA reasons as well as licensing details. You pay for the ES nodes, but not the kibana nodes. So you want the ES nodes only doing ES workloads.

> Except by itself it does little

True of every SaaS and most applications. Take every Office product, for exampe

No,you can edit text,spreadsheets,etc...with office apps without using other programs. With ES you need some other separate program (even just curl) as opposed to the user interacting with the apps UI directly.

Pretty much all databases are like that? And a ton of other things. Pick a random example: cockroachdb. Has all these properties.

I guess I don't understand what the author's point is.

Aren't most things like this? mysql, for eg.

Hmmm - couldn't you also say that Elasticsearch is a great example of a modern microservice?

It's not really `micro` is it though?

Microservices aren't necessarily small, at least by definition if not name. They are discrete services modeled around a business domain which are independently deployable and scalable. As such a "microservices" can get pretty big in terms of code and functionality.

Pardon my ignorance, but isn't that just a "service"?

The "micro" part just seems to cause confusion in every conversation I have about service based architectures.

Yes, it does cause confusion and can cause people to create an architecture that is too fragmented, resulting in a higher than necessary overhead in support for all those tiny services. I suspect a lot of people who don't like microservices are suffering from this problem.

Some people's definitions of microservices are that they are separated business domain, with each development team focusing on their business processes. Therefore they can reflect reflect Conway's law. Those teams develop autonomous services which communicate with the services of other teams (e.g. the invoicing team build services to interact with the sales team).

In smaller companies a single team, or indeed each team in a larger company, can have multiple microservices, but there are some qualities that would be needed to truly fit the microservice definitions.

If you haven't read Martin Fowler's article on Microservices then it's a good start: https://martinfowler.com/articles/microservices.html There's a side bar on that which asks "How big is a microservice?"

Of course Sam Newman is also a great resource for microservice principles: https://vimeo.com/131632250

That's interesting, I always thought there was at least a database layer running separately.

Reply on news.ycombinator.com