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

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

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