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