
Elasticsearch is a great example of a modern monolithic application - DVassallo
https://twitter.com/dvassallo/status/1169798034110025728
======
badrabbit
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?

~~~
DVassallo
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).

~~~
badrabbit
Interesting,thanks for clarifying.

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

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

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

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

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

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

~~~
dominicr
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](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](https://vimeo.com/131632250)

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

