Apollo: Spotify's Java libraries for writing micro-services | Hacker News Reader

Apollo: Spotify's Java libraries for writing micro-services

spotify.github.io

110 pointsingve35 comments

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

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) if we assume that I'm not a developer at Spotify?

"in vogue"

Interesting phrasing. I really hope people are choosing the best architecture for their application and not heading into microservices land because it's hot or "in vogue".

(Note, mtolan, not assuming anything about you or your choices here.)

Hope does spring eternal.

> What would make me want to choose Apollo over, say, Dropwizard

Came here to ask this too, if anyone in the know can provide an answer, because it doesn't seem to address this point in the readme from what I can see.

Looking at the examples on github, the thing I notice immediately is that it seems more DIY in nature, with seemingly all the libraries required for dealing with http, middleware, routing, etc written from scratch, as opposed to Dropwizard's approach of pulling together popular existing libraries to do all these things and providing really only the the glue code to piece them together as a framework.

Unlike Dropwizard, it is really intended for an asynchronous model of development. You don't have to worry about pushing the concurrency limits of an OS by starting thousands of threads if your application has a high ratio of callouts (disk, network IO) to computation (CPU), as is common with a lot of microservices. I guess this approach works best if your app's dependencies are convenient for asynchronous calls as well - HTTP, Cassandra, etc.

There's no need for asynchronous code and new frameworks to achieve that. Comsat makes Dropwizard run simple blocking requests in Quasar fibers (I'm a Quasar/Comsat dev), so you get all the performance of async code while still working with simple blocking code, standard APIs (JAX-RS), and standard servers (Jetty). You can easily run a hundreds-of-thousands if not millions of fibers in a single JVM without getting into trouble.

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

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

Project setup time with microservices really shouldn't be the issue. Build one template then use for all your services. Don't pick your framework because of setup time (plus I want to argue the differences are minor).

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.

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.

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?

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

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, gives it deep neural networks that run distributed...

It's almost as if some of the stuff you hear in "startup world" is wildly inaccurate.

Startups and huge multi-billion dollar companies have different priorities.

If you have lots of money to hire a bigger team and you want to be able to handle lots of users on fewer machines then Java (or even C++) makes sense.

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.

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

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?

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.

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/

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

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.

I agree, dev team could have shown some creativity in naming the project. As Knuth says, naming matters a lot.

Spotify has used Greco-Roman Pantheon names in its technology stack. I don't know all of the exact details for Apollo in this context but I assume similarities to existing tech is coincidental.

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.

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

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

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

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) which in my opinion is more elegant and complete.

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

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

I read about it some time ago.

a (so far) in-house built service that manages DNS srv records.

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

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

How is this different than dropwizard?

Reply on news.ycombinator.com