dropwizard vs spring boot - glenn engstrandglennengstrand.info › media ›...

Dropwizardvs

Spring Bootby Glenn Engstrand

There is a growing trend inJava to hide complexity with

annotation based designpatterns.

If you are planning onwriting some microservicesin Java, then you are mostprobably wondering whetherto use Dropwizard or SpringBoot. If so, then this blog isfor you. Although the titlesays Spring Boot, what I amreally evaluating here isversion 5 of the SpringFramework which includesBoot, Web, Core, Data, andTest. Whenever I evaluate atechnology stack, I write anews feed microservice inthat technology thencompare that to featureidentical microserviceswritten in other technologystacks. Today, I will becomparing the news feedmicroservices written inSpring Boot vs Dropwizard.

According to Google Trends,those two technologies wereequal in popularity backwhen Spring Boot was firstreleased in 2014. Since then,interest in Dropwizard hasremained the same whileSpring Boot interest hassteadily increased. Perhapsthis is because the SpringFramework is backed byPivotal Software which(according to the S-1 thatthey filed prior to their April2018 IPO) spent $221million in sales andmarketing in the previousyear. The Dropwizard projectis maintained by individualcontributors with nomarketing budget; however,they do get somesponsorship from Jetbrains. Iremember attending varioustech conferences over theyears and seeing theoccasional presentation forSpring Boot on the schedulebut never for Dropwizard.

Copyright © 2019 Glenn Engstrand p. 2 of 7 pp

feed 8 (Spring Boot) class

libraries and their

dependencies

Architecture

Since both technologies are forwriting servlet container basedmicroservices in Java, thearchitecture is very similar.Both microservices accessMySql, Redis, Cassandra, andElasticsearch since that is partof the functional requirements.I am a big believer in ModelDriven Software Developmentand Swagger is a very populartechnology for generatingmicroservice boilerplate codewith MDSD. I started usingSwagger with the Dropwizardimplementation and havecontinued to use it includingthe Spring Bootimplementation.

It makes a lot of sense todevelop microservices insuch a way as to deploy andtest them while they arerunning in a Kubernetescluster. For the actual loadtests, I do use the cloudmanaged solutions fromeither Amazon or Google. Iuse minikube whendeveloping and testing eachmicroservice on my laptop.As a minimum requirementfor adoption, each candidatetechnology has to be able tofunction in thoseenvironments.

An important part of evaluating any new microservicetechnology is to investigate how it performs under load andthat means having the capability to measure its performance.I used to use Kafka to capture performance data but it is noteasy to deploy Kafka on Kubernetes (although it is gettingeasier). Since then, I have switched over to measuringperformance with an API gateway approach. The load testapplication makes its calls to the microservice through a fullreverse proxy that also makes asynchronous calls to anotherservice with the performance data for the call to themicroservice under evaluation. That second service batchesup the performance data then periodically updatesElasticsearch with that data in a format that is easy forKibana to analyze and present.


Design

Ever since Kong has pivoted from APIgateway to service mesh, it has

underperformed in terms of throughput.

Originally, I used Kong as theAPI gateway. It used to do agreat job at that but startedunderperforming once version1 was released. I can onlyspeculate as to why. Kong hasrecently pivoted to becoming aservice mesh for Kubernetes.Perhaps it has lost focus on itsoriginal purpose of being anAPI gateway?

I had to replace Kong witha service that is a drop inreplacement to how Kongwas being used here. Iended up coding a 100 linecustom proxy in golang.The Go programminglanguage feels like a better,more modern C and it haslots of great support forhighly concurrent HTTPservers and clients.

Since both projects are startedusing similar Swaggertemplates and since bothtechnology stacks are similarin architecture, it only standsto reason that there would bea lot of similarities in thedesign of both microservices.They are both organized intoresources, services, and dataaccess. Resource classessurface the API calls. Servicesare responsible for thebusiness rules and foraggregating and caching data.Data Access Objects are usedto access the underlying databases. Both Dropwizard andSpring Boot use annotatedinterfaces where methodintercepting proxies delegatefunctionality based onmetadata.

The Spring Boot service usesSpring DI which is includedin Core. Spring is a littlemore opinionated than Guicein that it defaults to usingthe singleton pattern andsupports the notion ofcomponent scans. Instead ofa component scan, Guicedepends on a module systemwhere interfaces areexplicitly bound toimplementations during theconfiguration phase at timeof system start. TheDropwizard framework ishard coded to use Jetty asthe servlet containerwhereas Spring uses thatcomponent scan in order tofigure out which servletcontainer to run under. Itsupports Tomcat, Jetty, andUndertow. When load testingthe Spring Boot service, Iused Jetty in order for it tobe more comparable to theDropwizard service. I alsoran the load test with theSpring Boot serviceconfigured to use Tomcatand the difference inperformance was negligible.

There are plenty of differencestoo. While Dropwizard servicescan use Spring DI, thisDropwizard service usesGoogle Guice for DependencyInjection.


Spring Boot

The most profound difference is inhow the two technologies handledata access. Java applications tendto have a lot of plumbing codearound data access, particularlywith relational databases due totheir stateful connections and due tothe impedance mismatch betweenrelational data and objectorientation. Dropwizard addressesthis with its own datasource factoryand by incorporating another opensource project called JDBI.Dropwizard db manages the poolingof JDBC connections. JDBI providesa relatively lightweight mappingbetween relational datasets andobjects.

With non-relational databases, you are on your own and willmost probably just use whatever libraries are available forJava.

Spring data takes a more heavyweight approach by providingrepositories for both relational and non-relational databases.The repository for MySql calls JPA (Java Persistence API)using Hibernate as the implementation. I used therepositories for all of the underlying databases except forElasticsearch because, at the time of this evaluation, theSpring Data repository for Elasticsearch depends on thenative transport client instead of the high level REST client.The native transport client requires that you use a recentversion of Elasticsearch which is too memory intensive to runon minikube (my laptop has only 6 GB RAM of which only 4 isavailable to run 9 pods).

The Elasticsearchfolks recommendthe high levelREST clientanyway and willsoon deprecatethe nativetransport client.


Unit Tests

Code Size

Lightweight (Dropwizard)apps load faster and are

easier to debug thanheavyweight (Spring Boot)

apps.

There is an ongoing debate onhow much code coverage thatunit tests should strive for.Some believe that unit testsshould just focus on coveringservices with mocked DAOsand let functional tests coverthe rest. Others believe thatunit tests should coverresource classes too.Dropwizard provides supportfor those who are in the lattercamp. I side with the formerso I didn’t use the Dropwizardtesting module. Spring testallows you to easily injectmocked dependencies viaannotation with its testconfiguration annotation.

It takes a lot of LoC (Lines ofCode) to do almost anythingin Java. How does thisDropwizard service compareagainst the SpringFramework service in termsof the size of each projectrespectively? At the time ofthis evaluation, theDropwizard microservice iscomposed of 35 classes with atotal of 3,266 LoC. Thelargest class is the Redisclass (most probably becauseof the Hystrix integration)with 233 LoC. The SpringBoot microservice iscomposed of 41 classes with atotal of 2,296 LoC. Thelargest class is a Swaggergenerated support class of232 LoC.

Remember that both projectsstart with some Swaggergenerated code. Let’s removeboth that code and the unittests from consideration andlook only at hand writtencode that implements eachservice. Dropwizard has1 ,857 LoC and Spring Boothas 774 LoC.

Like I said earlier, one of thebiggest complaints againstJava in general is itsverboseness.


Spring Boot

Whenexceptions getslogged in thecode, stacktraces forlightweightapps will beshorter thanthe stacktraces forheavyweightapps. Sincethere are fewerlines of theapplication logto study, itmight take lesstime for thedeveloper todebuglightweightapps thanheavyweightapps.

This is what I mean by lightweight vsheavyweight. Does it really matter?Lightweight apps load faster thanheavyweight apps. A faster load time mightlead to a shorter outage when Kubernetesstarts restarting pods in order to reset adestabilized cluster.

How can the Spring Bootmicroservice implement the samerequirements as the Dropwizardmicroservice in so much less code?Like I said early in the designsection, both technologies useannotation based design patterns.Dropwizard uses it a little but theSpring Framework uses it a lot. Inorder to accomplish that, theSpring Boot microservice has a lotmore dependencies oninfrastructure based components.The uber jar for the Dropwizardmicroservice is 24 GB in size andholds 16 K classes. The uber jar forthe Spring Boot microservice is 71GB in size including 191 other jarstotalling almost 45 K classes


Load Test Results andOverall Summary

Spring Boot

In conclusion, the SpringFramework is moreenterprise focused thanDropwizard. The SpringBoot microservice had 30%less code and 60% less handwritten code but also ranwith 31% lower throughput.If managing complexity (formore predictable releases)is your primary concern,then consider choosingSpring Boot. If efficiencyand resource utilization ismore important (i.e. asmaller cloud bill), then gowith Dropwizard. If you stillwant to use Spring Boot butin a more efficient way, thensimply refrain from loadingor using Spring Data and beokay with writing morecode.

How do the two microservicesperform under identical load? Iused my standard load testconfiguration which is 3 threadsforever creating 10 users,friending each user on average3 times then posting 10outbound stories (of 150 wordseach) for each user. I had torerun the Dropwizard testbecause of the need to establisha new baseline since I replacedKong with that custom proxy. Ilet both tests run for 2 hours,then collect and analyze theperformance data. Averagethroughput for outbound postrequests to the Dropwizardmicroservice was 18,907 perminute. Latency was 4 ms onaverage and 10 ms on the 99thpercentile. For Spring Boot,average throughput was 13,068RPM and latency was 3.5 ms onaverage and 8 ms on the 99thpercentile.

dropwizard vs spring boot - glenn engstrandglennengstrand.info › media ›...

Documents