
Apollo: Spotify's Java libraries for writing micro-services - ingve
http://spotify.github.io/apollo/
======
sandius
I quite like how the page pays homage to the visual style of the Apollo
Program documentation (e.g.
[http://history.nasa.gov/ap12fj/pdf/a12_sa507-flightmanual.pd...](http://history.nasa.gov/ap12fj/pdf/a12_sa507-flightmanual.pdf)).

------
mtolan
This seems like a use-case that a whole lot of people are excited about since
microservices are presently in vogue. What would make me want to choose Apollo
over, say, Dropwizard ([http://dropwizard.io](http://dropwizard.io)) if we
assume that I'm not a developer at Spotify?

~~~
j_jochem
If you compare the "Getting Started" sections for both frameworks
(Dropwizard's is here: [http://www.dropwizard.io/0.9.1/docs/getting-
started.html](http://www.dropwizard.io/0.9.1/docs/getting-started.html)), it
looks like the initial setup for Apollo is a lot less complex. This may be a
significant advantage, because it cuts down project setup time, which is one
of the annoying parts of microservices.

However, I can imagine having to pay for this once you need some more advanced
features. Dropwizard comes with a lot of stuff for configuration management
and integration, which I guess is mostly missing in Apollo.

~~~
ones_and_zeros
Really? The dropwizard example looks almost identical except for an extra
Config related class (which seems like a more sane design to me) and 2 extra
methods to implement. Not sure I'd call it a lot less complex.

I think what is happening is the getting started guide for dropwizard looks
significantly more _indepth_ than the Apollo guide, covering some features
that are entirely optional (and may not even be supported by Apollo.)

------
spdionis
Interesting difference in attitude I notice. The java (i suppose) devs
commenting have the general attitude of "give me one good reason to use this
instead of X". In contrast when a new javascript framework is posted people go
"yay, this looks awesome, congratulations! I will try it for my next
project!".

I tend to have an attitude similiar to the java side. I wouldn't say the
javascript attitude doesn't have benefits though.

~~~
structAnkit
I don't see an issue with having more available options, especially in the
fast moving JS world.

I think it's more important to consider the support behind a technology vital
to your stack so you can expect to regularly integrate improvements, security
fixes, etc.

------
Domenic_S
So, in the startup world at least, I always hear JAVA IS DEAD! DOWN WITH JAVA!

But this library, a bunch of Google stuff, most of Netflix's stuff -- it seems
like the real, this-makes-money work is still done in Java. Am I wrong? Is
Java not dead at all?

~~~
vonnik
If Java was dead, they wouldn't have to shout down with Java. Rumors of Java's
death have been greatly...oh, you know.

Java's in the running to be the world's most widely used programming language.
This is, in large part, due to Android.

[http://news.softpedia.com/news/the-top-10-all-time-
programmi...](http://news.softpedia.com/news/the-top-10-all-time-programming-
languages-on-github-489852.shtml#sgal_0)

It so happens that a lot of companies have bet their stacks on Java. Java is
the language of Hadoop. In addition to the companies you mention, there's
Amazon, eBay, Facebook, LinkedIn, Twitter. (There are plenty of other great
languages that outperform Java in one way or another, but this post is just to
make that point that Java is far from dead...)

It's a stable language with a huge ecosystem, that's growing all the time. Our
project, [http://deeplearning4j.org](http://deeplearning4j.org), gives it deep
neural networks that run distributed...

------
rce
Not sure why they'd write all these libraries from scratch instead of just
reusing something like Play or Dropwizard that are more used and thus probably
better supported and have more of the kinks worked out. Wish they'd explain
that up front.

~~~
betimsl
Have you tried play framework? Because it installs a lot of libraries and
let's not talk about performance.

~~~
paulddraper
I'm using the Play framework. I run it on dedicated hardware, so the few extra
MB of disk space doesn't bother me.

I know you don't like talking about it, but do you have something to share
about its performance?

~~~
betimsl
It's not a matter of a few extra MB, but number of libraries, more libraries
equals more bugs equals more problems.

I'm not saying only play has this problem, almost all java frameworks from the
time of play have similar properties.

On the other hand, it is slow, embarrassingly slow (try running it on RPi).
For me it's really complicated as well. You have routes file (which is
redundant). Templating language forces you to write Scala which then uses a
Scala compiler to compile which it is really slow (even Martin said it's
slow). It's a vicious circle.

------
kitd
Not sure about that name. A bit too close to ActiveMQ's Apollo [1] for my
liking. The functional areas aren't that dissimilar.

[1] -
[https://activemq.apache.org/apollo/](https://activemq.apache.org/apollo/)

~~~
wging
I bet Apollo is a fairly commonly used name. As one example, Amazon's internal
deployment system is named Apollo:
[http://www.allthingsdistributed.com/2014/11/apollo-amazon-
de...](http://www.allthingsdistributed.com/2014/11/apollo-amazon-deployment-
engine.html)

It's probably a stretch to say that Amazon's Apollo has a bigger "market
share", because it's not on the market. AWS CodeDeploy may be similar--haven't
checked it out. Nevertheless, the Amazon Apollo's user base is probably way
bigger than ActiveMQ's or Spotify's Apollo :)

Also, it seems the Greeks have stolen the name for one of their gods too.

------
bjoernw
Spring Boot, Dropwizard, and Apollo all seem to try to do the same thing. They
all seem easy to use, more or less opinionated with Spring Boot being the most
opinionated. The one thing in Apollo I find quite interesting is the native
integration of async-ness. Very nodeJs like but could also be achieved in
Spring Boot or Dropwizard with Reactor. I do think Dropwizard would have been
THE framework to extend here with some async sugar. But hey, developers love
to build their own things.

------
crudbug
Putting resources behind dropwizard would have been a better approach.
Dropwizard needs some love on the admin/ops UI sides.

~~~
quicksilver03
What do you think is missing in Dropwizard from an admin/ops point of view?

~~~
crudbug
I am using DW 0.9.x. I miss an admin interface like django admin.

------
betimsl
This looks cool, but looks like they waited too long to release it. I would
like to see some benchmarks, but _humbly_ think that it can come no where near
Rapidoid
([https://news.ycombinator.com/item?id=10729868](https://news.ycombinator.com/item?id=10729868))
which in my opinion is more elegant and complete.

------
mikebo
What are you using for service discovery and registration? I took a quick look
through the docs but didn't see this mentioned.

~~~
callesgg
They used to use dns, i think. Not sure if they still use that.

I read about it some time ago.

------
SureshG
What are the advantages of using these libraries over Playframework which IMO
is more complete and batteries included?

------
bm1362
Diagrams are really good looking, anyone know of a tool to create attractive
diagrams, quickly?

------
Omnipresent
How is this different than dropwizard?

