3 ms·
> It's neat. But is it worth it? Saving traffic is good in general, insofar as it speeds deploys and allows higher container density. But for me the key was t
by jacques_chester 10y ago
> It's neat. But is it worth it?
Saving traffic is good in general, insofar as it speeds deploys and allows higher container density.
But for me the key was trying to get out of dependency hell. The shade plugin isn't perfect.
I work at Pivotal, we inherited the Spring team from VMWare. When I first saw Spring Boot I wondered what all the fuss was about. Then I worked with a classic Spring-with-hand-rolled-Maven app and oh boy, let me tell you, I got it.
Having someone else level the dependencies for you? Huge. I'd be interest if this tool can help Spring Boot too, though the runtime downloading of dependencies is not without problems.
- HiJon89 10y agoAgreed, we might not have done it if we had to resort to having the application download its own dependencies at startup. In our case, our Mesos scheduler, Singularity, handles S3 artifacts at deploy time for us. Previously we gave it a single S3 URL for the fat JAR, but now we just give it a list of artifacts (the app plus its dependencies) and it handles everything for us so it's not much more complexity and ended up being really easy to integrate into our deploy process. By the time the app starts up, all of its dependencies are guaranteed to be present (if an S3 download failed, the deploy would have failed) so it's totally transparent to the application.
- jacques_chester 10y agoThat makes sense. I'm used to having to worry about disconnected environments (I worked on Cloud Foundry buildpacks for a while), for which Spring Boot's JARs work a treat. In a fully connected environment this approach looks promising. If I bump into any of the Spring folks I will mention it.