Issue October 2016 | presented by www.jaxenter.

com #53

The digital magazine for enterprise developers

Reactive
Programming
with Scala, Lagom, Spark, Akka and Play

Interview with Scala creator Martin Odersky

The state of Scala

The Lagom Framework

Lagom gives the developer a clear path
©istockphoto.com/moorsky

DevOpsCon 2016: Our mission statement

This is how we interpret modern DevOps
 Editorial

Reactive programming is
gaining momentum

“We believe that a coherent approach to systems architec- If the definition “stream of events” does not satisfy your
ture is needed, and we believe that all necessary aspects are thirst for knowledge, get ready to find out what reactive pro-
already recognized individually: we want systems that are Re- gramming means to our experts in Scala, Lagom, Spark, Akka
sponsive, Resilient, Elastic and Message Driven. We call these and Play. Plus, we talked to Scala creator Martin Odersky
Reactive Systems.” – The Reactive Manifesto about the impending Scala 2.12, the current state of this pro-
Why should anyone adopt reactive programming? Because gramming language and the technical innovations that await
it allows you to make code more concise and focus on im- us.
portant aspects such as the interdependence of events which Thirsty for more? Open the magazine and see what we have
describe the business logic. Reactive programming means dif- prepared for you.
ferent things to different people and we are not trying to rein-
vent the wheel or define this concept. Instead we are allowing Gabriela Motroc, Editor
our authors to prove how Scala, Lagom, Spark, Akka and
Play co-exist and work together to create a reactive universe.

“The current state of Scala” 4 Big Data becomes Fast Data 21

Index

Interview with Martin Odersky SMACK – Next generation Big Data

Jochen Mader
Reactive microservices with Scala 6
and Akka “Expert checklist – Why Scala 24
Event-driven architecture and not Java?”
Vaughn Vernon
Interview with Heiko Seeberger, Daniel Westheide,
Daniela Sfregola, Julien Tournay, Markus Hauck and Ivan Kusalic
What’s new in Akka? 10
All you need to know about development DevOpsCon 2016: Our mission  26
and direction
Dr. Roland Kuhn
statement. This is how we
interpret modern DevOps
Dedicated to doing the right thing 12 Modern DevOps – Connecting business
Akka: The Swiss army knife of reactive and IT
systems on the JVM Sebastian Meyen

Manuel Bernhardt
“Checklist: Why are microservices  29
Compile-time dependency injection 14 important for you? – Part 3”
in the Play framework Interview with Daniel Bryant

How to gain more control with compile-time

dependency injection
Marius Soutier

The Lagom Framework 17

Lagom gives the developer a clear path
Lutz Hühnken

www.JAXenter.com | October 2016 2

 Hot or Not

Angular 2 is shy no more

It’s been two years since Google announced plans for Angular 2 and now the
full-platform successor to Angular 1 is finally here. Angular 2.0.0 was released on
September 14, 2016, one day after the team launched the last release candidate.
According to the official statement, “Angular 1 first solved the problem of how to
develop for an emerging web. Six years later, the challenges faced by today’s ap-
plication developers, and the sophistication of the devices that applications must
support, have both changed immensely”. Angular is now “ready for the world”,
said Google’s Julie Kremer.

BOSH 2.0 – Happy NetBeans is pack-

as a clam ing its bags and
Those who attended the Cloud moving to Apache
Foundry Summit Europe 2016 in late
September may have noticed that a NetBeans is moving to Apache in the
certain project was mentioned over hope that a change of scenery will help
and over again: BOSH, an open source boost the number of contributions
tool chain for release engineering, from various organizations. NetBeans
deployment and lifecycle management Dream Team members reacted dif-
of large-scale distributed services. ferently to the news, with one saying
Version 2.0 (the logo of the project is a that Apache should not be the final
clam) is coming soon and will include destination of NetBeans. According
the following: property validation, to Bill Pataky, Oracle’s Vice President
availability zones, global networking, of Mobile Development Program and
cloud config, config server and links, Developer Tools, Oracle developers
according to Alexander Lomov, Cloud will be involved in at least two Apache
Foundry Engineer at Altoros. NetBeans releases.

Docker fork: Will it happen?

Discussions about a possible Docker fork first appeared in late August, when Google’s
Craig McLuckie took to Twitter to reveal his thoughts about the need for “a contain-
er runtime and format standard to emerge beyond the (current) scope of OCI”, but he
was not the only one to throw a rock at Docker. Google Kubernetes evangelist Kelsey
Hightower took to Twitter to wonder whether “Docker deserves to be the stewards of
an open container standard.” Meanwhile, Benjamin Wootton, co-founder of Contino,
opined that “the Docker fork talk is a storm in a teacup” and Viktor Farcic, Senior Con-
sultant at CloudBees, declared that “Docker 1.12 is probably the most important release
since 1.0.”

Java 9 leaves us hanging

Mark Reinhold, the Chief Architect of the Java Platform Group at Oracle, announced in a
message on the OpenJDK mailing list in mid-September that the schedule for Java 9 may
be delayed to July 2017. A few days later he told the JavaOne audience that Java 9 “will
be coming soon – but not as soon as you'd probably hoped”. However, he also pointed
out that Java 9 is not only about Jigsaw, although it is the headline of the release. Rein-
hold also mentioned in the message on the OpenJDK mailing list that even though the
team has made significant progress on Project Jigsaw, it “needs more time”. If the JDK 9
schedule does not receive another extension, Java 9 should be launched in July 2017.

www.JAXenter.com | October 2016 3

 Interview

Interview with Martin Odersky

“The current state of Scala”

James Strachan, the creator of Groovy, once said that if into the cornerstone of most Scala libraries. I believe they will
somebody had shown him Martin Odersky’s “Programming become even more important in the future.
in Scala” book back in 2003, he would have probably never
created Groovy. Scala’s star is still shining bright – we invited JAXmag: In your opinion, what are the most important tech-
Martin Odersky, the creator of Scala, to talk about the im- nical milestones for this programming language?
pending 2.12 version, the current state of this programming Odersky: The most important step was no doubt Scala 2.8,
language and the technical innovations that await us. which came out in 2010. With 2.8 we had for the first time a
Martin Odersky designed Scala in 2001. Now version 2.12 uniform collections library, refined rules for implicit resolu-
is in development and version 3.0 is just around the corner. tion, and type inference. After that, Scala 2.10 was also a big
Even James Gosling, the creator of Java once said that if he step because it introduced meta-programming in Scala.
were to choose “a language to use today other than Java, it
would be Scala.” We talked to the creator of Scala about the JAXmag: Were there also milestones in relation to the dis-
current state of this programming language, what to expect semination of the language? The community around Scala
from version 2.12 and more. was formed rather fast and important projects and compa-
nies adopted it quickly. What contributed to the expansion
JAX Magazine: It’s been 15 years since the work on Scala be- of this language?
gan at the École polytechnique fédérale de Lausanne (EPFL). Odersky: Adoption has by and large steadily increased for
If we look back at how Scala looked like more than a de­cade the last eight years, but there were nevertheless a few drivers
ago, one cannot help but wonder: What is the difference be- which led to rapid adoption in certain areas. The first leap
tween the original concept and design of Scala and the cur- was adoption of Scala by Twitter and other new web com-
rent state of this programming language? panies, starting in 2008. The second leap was widespread
Martin Odersky: Scala was designed to show that a fusion adoption of reactive programming, notably around Akka and
of functional and object-oriented programming is possible Play, starting around 2011. The third leap was the success of
and practical. That’s still its primary role. What has changed Scala in big and fast data scenarios as well as data science,
is that at the time it came out FP was regarded as an academic driven by Spark, Kafka, and many other frameworks.
niche. So it was difficult to make the case that FP should be
needed in a mainstream language. XML literals were add-
ed to the language as a specific use case, because we knew Portrait
that traditional OO techniques had a hard time dealing with Martin Odersky created the Scala programming language and is a
XML trees. Nowadays the tide has turned. Functional pro- professor in the programming research group at EPFL, the leading
gramming has become respectable, in some areas even main- technical university in Switzerland. He authored “Programming in
stream, and it’s sometimes harder to make the case for good Scala”, the best-selling book on Scala. Previously he has held po-
object-oriented design. sitions at IBM Research, Yale University, University of Karlsruhe and
In terms of language features I believe the biggest develop-
University of South Australia, after having obtained his doctorate
ment has been the refinements we did to implicit parameter
from ETH Zürich as a student of Niklaus Wirth, the creator of Pascal.
search. Implicits evolved from a somewhat ad-hoc feature

www.JAXenter.com | October 2016 4

 Interview

JAXmag: An entire stack was formed around Scala; it con- without too much disruption. For one, we are working on
sists of Akka, Play, Lagom, Apache Spark and others. What sophisticated rewrite tools that allow code to evolve to new
role do this stack – and the so-called reactive programming standards. We are also planning to use TASTY, a platform
paradigm –play in the Scala community and especially in independent interchange format, to avoid binary compati-
Lightbend? bility problems through automatic code adaption to specific
Odersky: Developing and supporting this technology stack platforms and versions.
is at the core of what Lightbend does. The stack covers ev­
erything from web frameworks to big data backends, with JAXmag: Is there already a release roadmap for Scala 3.0?
special emphasis on reactive programming and microservices Odersky: No, not yet. We want to keep some flexibility in
in distributed scenarios. That’s where these technologies are deciding what to ship before we determine when to ship it.
very successful. A large part of the Scala community uses this
stack, but there are of course also many other frameworks to JAXmag: Scala was explicitly designed as a language which
choose from. should be adopted in research, but should also have an in-
dustrial use. Is the gap between industry and research really
JAXmag: Right now Scala 2.12 is in development. What is that big? There has been criticism with regard to the fact
this release all about? that a developer/architect’s job has little to do with what is
Odersky: The main purpose of 2.12 is to optimize Scala for taught in universities.
use on Java 8. Java 8 introduced lambdas and default meth- Odersky: I can’t speak for other universities. But I find that
ods for interfaces. Both are very useful to streamline Scala our students at EPFL have no problems finding interesting
code generation and make the code size smaller. work in which they can apply what they have learned during
their studies. Scala certainly helps since it has a healthy job
JAXmag: Scala 3.0 is fast approaching. Can you offer us market.
some insight into the technical innovations that await us?
Odersky: It’s too early to talk about that yet. The next ma- JAXmag: What area of research is still insufficiently taken
jor version will be Scala 2.13, which will concentrate on mod- into consideration in today’s mainstream languages?
ernizing and modularizing some of the core libraries. Odersky: Functional programming is just catching up in
industry. I think one of the next big developments will be
JAXmag: Will Scala 3.0 differ greatly from the 2.x line of de- the refinement of type systems to describe ever more pre-
velopment, as it is often the case with major versions or will cise properties of programs. This has been researched for
it be a natural evolution of 2.x? a while, and more progress is needed to make this really
Odersky: Scala has been quite stable over the last five years. practical. But I predict that this development end will pick
We hope that by the time Scala 3.0 comes out we will have the up speed in the future.
necessary technologies in place to make some bigger changes

Advert

Cloud Native Platform Extensible

for Rich
Content Architecture
with 150+ plug-ins
Flexible
REST API

Management
exposing 250+
extension points JSON as data format
for bandwidth
efficiency

Highly Scalable
Content Model
horizontally scalable
query engine and
data persistence

Flexible. Extensible. Scalable.

www.JAXenter.com | October 2016 5
 Scala

Event-driven architecture

Reactive microservices
with Scala and Akka
In this article, Vaughn Vernon will teach you a first-approach method to designing microservices, giving
you a workable foundation to build on. He introduces you to reactive software development, and sum-
marizes how you can use Scala and Akka as a go-to toolkit for developing reactive microservices.

by Vaughn Vernon Should we find a better balance here? Consider the case when
data that is spread across different subsystems must reflect
Do you ever get the impression that our industry is one of some kind of harmony. Some hold to the strong opinion that
extremes? Sometimes I get that impression. Many seem to all such dependent data must be transactionally consistent;
be polarized in their opinions about various aspects of how that is, up-to-date across all subsystems all at once (Figure 1).
software should be written or how it should work, whereas What about you? Do you agree with that? Do some of
I think we could find a better balance based on the problem your software systems use global transactions in this way
space that we face. to bring data on multiple subsystems into harmony all at
One example that I am thinking of is the common opinion once? If so, why? Is it the business stakeholders who have
that data must be persisted using ACID transactions. Don’t insisted on this approach? Or was it a university professor
get me wrong. It’s not that I think that ACID transactions who lectured you on why global transactional consistency
are not useful. They are useful, but they are often overused. is necessary? Or was it a database vendor who sold you
on this service-level agreement? The most impor-
tant opinion of these three is that of the business. It
should be real business drivers that determine when
data must be transactionally consistent. So, when
was the last time you asked the business about its
data’s consistency requirements, and what did the
business say?
If we all took a look back to the time before most
businesses were run by computers, we would find a
very different picture of data consistency. Back then
almost nothing was consistent. It could take hours
or even days for some business transactions to be
carried out to completion. Paper-based systems re-
quired physically carrying forms from one person’s
desk or work area to another. In those days even
a reasonable degree of data consistency was com-
pletely impossible. What is more, it didn’t result in
problems. You know what? If today you got an au-
thentic business answer to the question of necessary
data consistency, you would very likely learn that
a lot of data doesn’t require up-to-the-millisecond
consistency. And yet, extreme viewpoints in our in-
dustry will still push many developers to strive for
Figure 1: Global transaction transactional consistency everywhere.

www.JAXenter.com | October 2016 6

 Scala

Figure 3: Monolith vs. microservices

of “micro” status must be no more than 400 lines of code

also seems imbalanced. Take for example segmenting an
existing monolith system into components of no more than
400-lines each and deploying all of them. At 400 lines of
code, you are probably talking in terms of just one en-
Figure 2: Isolated transaction
tity type per microservice. You could actually end up
If you want to use microservices, you are going to need to with hundreds or even thousands of these very small micro­
embrace eventual consistency. Understand that the business service components. What kind of problems could your
will likely not be opposed, even if your university professor teams face in trying to administer all those microservices?
and your database sales representative will be. I explain how The hardware and network infrastructure alone would be
this works later in this article. very complex. It could be quite difficult to create and main-
There’s another extreme that has cropped up recently. It’s tain such as system, say the least.
service size, and specifically with regard to the use of “micro­ Still, if we strike a balance in terms of “micro” we might
services”. What is a microservice anyway, and how does “mi- find a “measurement” of service size that is not only logical,
cro” qualify the size of a service? Some guidance says: 100, but actually business driven. Since I am a big proponent of
400, and 1,000. What? Yes, I have seen and heard that a mi- the Domain-Driven Design (DDD) approach to developing
croservice should be no more than 100 lines of code. Others software, what I am suggesting here is to use two of the most
say no more than 400 lines of code. And some are a bit more important concepts of DDD to determine the size of a micros-
liberal at 1,000 lines of code. So, who is correct? ervice: Bounded Context and the Ubiquitous Language.
I am not sure that any of those extremes provide good guid- If you have read the book “Building Microservices” by
ance as to the size of a microservice. For example, if someone Sam Newman, you already know that Sam says that a micro-
agrees with the rule that a microservice should be no more service should be defined by a Bounded Context. Sam and I
than 400 lines of code, and I create a microservice that is 537 are in agreement. But actually saying that a microservice is a
lines of code, does that mean that my microservice is too big? Bounded Context doesn’t exactly state what the size should
If so, why? Is there something magical about 400 lines of code be. That’s because the size of a Bounded Context is determin­
that makes a service just right? ed by its Ubiquitous Language. Thus, if you want to know
On the other hand, some will take the opposite extreme the size of your Bounded Context (and microservice), you
view that software systems should be developed as mono- have to ask your Ubiquitous Language. It is the combination
liths. In such a case you could expect that nearly every sub- of the business experts and software developers working to-
system that is required to support the core of the system will gether that determines the Language of the Bounded Context.
be housed in a single code base. When you deploy this system It’s important to understand that using business language
you must deploy all subsystems with it. If even one subsystem drivers means that all
changes in a non-intrusive way to the other subsystems, the linguistically cohesive
whole system must be deployed for the users to see the effects components will live
of one isolated change. Clearly there seem to be disadvantages in the same Bounded
with this approach, but is 400 lines of code the answer? Context. Those that
I think that the emphasis on the word “micro” should are not linguistically
convey more the meaning that your team should not be cohesive with one
creating a monolith, but instead a number of smaller in- Bounded Context
dependent services that work together to accomplish some thus belong in anoth-
significant business goal. But to say that a service that is er. Figure 4: Bounded context

www.JAXenter.com | October 2016 7

 Scala

Figure 5: Different bounded contexts Figure 6: Lightbend patform components

What I find is a Bounded Context that is truly constrained Reactive software is ...
by an actual business-driven Ubiquitous Language is quite Reactive software is defined as having these four key charac-
small. It’s typically bigger than one entity (although it may be teristics:
just one), but also much, much smaller than a monolith. It’s
impossible to state an exact number, because the unique busi- • Responsive
ness domain drives the full scope of the Ubiquitous Language. • Resilient
But to throw out a number, many Bounded Contexts could be • Elastic
between 5 and 10 entity types total. Possibly 20 entity types is • Message driven
a large Bounded Context. So, a Bounded Context is small, yes
“micro” in size, especially when compared with a monolith. A responsive system is one that responds to user requests
Now, if you think about dividing a monolith system into a and background integrations in an impressive way. Using the
number of Bounded Contexts, the deployment topology isn’t Lightbend platform, you and your users will be impressed
so extreme. by the responsiveness that can be achieved. Often a well-de-
At a minimum I think that this is a good place to start if signed microservice can handle write-based single requests in
your team is determined to break up a legacy monolith into 20 milliseconds or less, and even roughly half that time is not
a number of microservices; that is, use Bounded Context and uncommon.
Ubiquitous Language as your first step into microservices and Systems based on the Actor model using Akka can be de-
you will go a long way away from the monolith. signed with incredible resilience. Using supervisor hierarchies
means that the parental chain of components are re-
sponsible for detecting and correcting failures, leav-
Listing 1 ing clients to be concerned only about what service
they require. Unlike code that is written in Java that
class Product(productId: String) extends PersistentActor { override def persistenceId = productId throws exceptions, clients of actor-based services
var state: Option[ProductState] = None never have to concern themselves with dealing with
override def receiveCommand: Receive = { failures from the actor from which they are request-
case command: CreateProduct => ing service. Instead clients only have to understand
val event = ProductCreated(productId, command.name, command.description) the request-response contract that they have with a
persist(event) { persistedEvent => given service, and possibly retry requests if no re-
updateWith(persistedEvent) sponse if given in some time frame.
sender ! CreateProductResult( An elastic microservices platform is one that
} can scale up and down and out and in as de-
... } mands require. One example is an Akka cluster
productId, that scaled to 2,400 nodes without degradation.
command.name, Yet, elastic also means that when you don’t need
command.description, 2,400 nodes, only what you currently need is allo-
command.requestDiscussion) cated. You will probably find that when running
override def receiveRecover: Receive = { Akka and other components of the Lightbend re-
case event: ProductCreated => updateWith(event) ... active platform, you will become accustomed to
} using far fewer servers than you would with other
def updateWith(event: ProductCreated) { platforms (e.g. JEE). This is because Akka’s con-
state = Some(ProductState(event.name, event.description, false, None)) currency capabilities enable your microservices to
}} make non-blocking use of each server’s full com-
puting resources at all times.

www.JAXenter.com | October 2016 8

 Scala

Figure 7: Event-driven architecture

The Actor model with Akka is message driven to the core. can be published to the broader range of microservices that
To request a service of an actor, you send it a message that is must react to and integrate with the event originating micro-
delivered to it asynchronously. To respond to a request from service.
a client, the service actor sends a message to the client, which What I am describing here is a event-driven architecture,
again is delivered asynchronously. With the Lightbend plat- one that is entirely reactive. The actors within each micros-
form, even the web components operate in an asynchronous ervice make the one reactive, and the microservices that con-
way. When saving actor persistent state, the persistence mech- sume events from the others are also reactive. This is where
anism is generally designed as an asynchronous component, eventual consistency in separate transactions come into play.
meaning that even database interactions are either completely When other microservices see the events they create and/or
asynchronous or block only minimally. In fact, the point is modify the state that they own in their context, making the
that the actor that has requested persistence will not cause its whole system agree in time.
thread to block while waiting for the database to do its thing. I have written three books on developing these kinds mi-
Asynchronous messaging makes all of this possible. croservices based on Domain-Driven Design, and I also teach
two workshops on these topics. I encourage you to read my
Reactive components books and contact me for more information on how you can
At each logical layer of the architecture, expect to find the put this practical microservices architecture to work in your
following Lightbend platform components and microservice enterprise.
components that your team employs or develops (Figure 6).
For example, an Akka-based persistent actor looks like this
(Listing 1).
This is a component based on event sourcing. The Prod-
uct entity receives commands and emits events. The events Vaughn Vernon is a veteran software craftsman, with more than 30 years of
are used to constitute the state of the entity, both as the experience in software design, development, and architecture. He is a thought
commands are processed and when the entity is stopped leader in simplifying software design and implementation using innovative
methods. Vaughn is the author of the books “Implementing Domain-Driven
and removed from memory and then recovered from its Design”, “Reactive Messaging Patterns with the Actor Model”, and “Do-
past events. main-Driven Design Distilled”, all published by Addison-Wesley. Vaughn speaks and
Now with those events we can derive other benefits. First presents at conferences internationally, he consults, and has taught his “IDDD” Work-
shop and “Go Reactive with Akka” workshop around the globe to hundreds of develop-
we can project the events into the views that users need to see, ers. He is also the founder of “For Comprehension”, a training and consulting company,
by creating use-case-optimized queries. Secondly, the events found at http://ForComprehension.com. You may follow him on Twitter: @VaughnVernon.

www.JAXenter.com | October 2016 9

 Akka

All you need to know about development and direction

What’s new in Akka?

Last year, Akka won the JAX Innovation Award for Most Innovative Open Source Tech – we’re still very
proud of this recognition! – and one thing I can say is that winning the award did not make us pause
or slow down. A lot is happening in and around Akka as we will see in this whirlwind tour through the
ecosystem.

by Dr. Roland Kuhn formulating responses. In order to allow more people to con-
tribute efficiently – and in order to allow the HTTP modules
Before we begin, a personal note: On March 7 this year, to evolve at a faster pace than the very stable Akka core – the
­Patrik Nordwall took over the Akka Tech Lead duties be- high-level HTTP modules are moving out of the core Akka
cause I co-founded Actyx, a startup that helps small and mid- repository into a separate new home under the Akka organi-
sized manufacturing companies to reap the benefits of digital zation on github. For more details see the 2.4.9 release notes
technologies – sometimes classified as Industry 4.0. I remain and the discussion on the akka-meta repository [3].
very interested in Akka and I continue to develop some parts Apropos contributions: since the addition of Streams &
as we’ll see in this article, but I no longer speak for Lightbend. HTTP, we have seen a marked increase in the breadth of our
The biggest development within Akka since 2.3.0 (March contributor base. Every minor release contains the work of
2014) has for sure been the Reactive Streams  [1] initiative circa 40 community members. Contributing has never been
and Akka Streams. The former is now slated for inclusion in easier, not only because the high-level features of Streams &
Java 9 under the name Flow [2] and it forms the basis for the HTTP are more accessible, I think it is also due to the use of
inner workings of the latter: Akka Streams is fully Reactive Gitter for nearly all team communication.
Streams-compliant. Streaming data pipelines are becoming There is also vivid exchange with authors of integration
ever more common and satisfy a rising demand of proper- libraries that connect Akka Streams to data sources and sinks
ly rate-controlled processing facilities – gone are the days of like message brokers, files, databases, etc. In order to foster
OutOfMemoryErrors resulting from one overwhelmed ac- this growing ecosystem, an umbrella project named Alpakka
tor’s mailbox. [4] has been created, similar in spirit but of course currently
Streams were first developed on a very long-lived feature a lot less powerful than Apache Camel. Everyone is invited
branch and versioned separately. Their experimental phase to think up and implement new integrations – this is your
ended when they were released as part of Akka 2.4.2 in Feb- chance to give back to the community. These are currently
ruary 2016. In parallel, Spray – the lean and expressive HTTP best targeted at the Akka Stream Contrib repository, but the
library – has been rewritten on top of Akka Streams, a new team is thinking about opening a special Alpakka dedicated
foundation for reliable and efficient processing of large pay- repository as well.
loads. The resulting Akka HTTP modules present one of the Another project that will have deep impact on how you use
most modern HTTP stacks available today, which is perfect- Akka is going on under the hood and driven by the core team
ly positioned for implementing the HTTP/2 standard that is – its codename is Artery. This new remote messaging stack
swiftly gaining popularity: HTTP/2 connections are optimized is based on the Aeron [5] library and on Akka Streams and
for streaming several independent requests and responses at delivers vastly improved throughput and latency for sending
the same time. Konrad Malawski (maintainer of the Akka messages across the network – just be sure to not use Java Se-
HTTP modules) and Johannes Rudolph (co-author of Spray rialization, which is just too slow to keep up. The goal of this
and now member of the Akka core team at Lightbend) have rewrite of the basis for clustering is not only improved per-
started a proof-of-concept implementation for HTTP/2 sup- formance, the main impetus behind it is to use the expressive
port in September and I’m excited to see the results. power and safety of Streams to simplify the implementation
The 2.4.9 release has brought its performance up to the and eventually provide verified cross-version stability and
level of Spray or even beyond, and the Java and Scala APIs compatibility. The current status (as of Sep 19, 2016) is that
are merely being polished a bit more to straighten out a few milestone 4 is available for you to try out and give feedback
remaining wrinkles. The surface area covered by an HTTP on [6]. Within the next few months Artery will replace the old
implementation as complete and expressive as this one is remoting implementation and become the default.
enormous: the user-facing API has more than 26,000 lines The last project to talk about is the one that I am deeply in-
of Scala code, defining all those media types, encodings and volved in. Akka Typed has been included since version 2.4.0
other headers as well as the directives for routing requests and as a sketch of how to achieve type-safety in actor interactions

www.JAXenter.com | October 2016 10

 Akka

in a fashion that is simple to understand, without compiler very cumbersome or impossible before. Think about an ac-
magic, and inherently built for great and easy test coverage. In tor that speaks some protocol with its clients, in the simplest
a nutshell, it consists of a generic ActorRef that only accepts a case request–response. In order to compute the response the
certain well-specified type of messages, plus a generic Behav- actor might have to converse with a handful of other actors
ior (i.e. actor implementation) that only expects inputs of a in a multi-message exchange. Previously you would imple-
given type. It is the third attempt in this direction within Akka ment that by manually stashing all unexpected messages
and I firmly believe that this is the one that works. Recently, and switching between different behaviors using context.be-
also due to the intention to use this at Actyx, I have created come(). With the upcoming Akka Typed DSL [9] it becomes
an entirely new implementation of the actor mechanics for possible to write down a sequence of send and receive actions
the Akka Typed package, making it available alongside the using a Process abstraction, where processes can be composed
adapter that offers the new features as an emulation layer on to run in sequence or in parallel within the same actor. This
top of the untyped akka-actor package. greatly simplifies the code structure because it disentangles
Based on the experience collected over the past six years the different aspects of an actor’s behavior and sorts them
from developing Akka, we decided to remove features that into cohesive strands that each fulfill their separate purposes.
greatly complicate the internal code while not delivering suf- All this is currently still in the research phase, so feedback is
ficient benefit to all users. The full list has been discussed on very much welcome and needed to get it ready soon.
akka-meta [7]; highlights are the configurability of mailboxes Oh, and one last thing: at Actyx we are currently working
and remote deployment. Together with the relocation of the on an improved version of distributed data structures (for the
execution of supervisor strategies into the child actors them- curious: an implementation of δCRDTs) that can be used in-
selves this has led to a huge reduction in code size, while the dependently of Akka Cluster. If that turns out to be successful,
user-facing feature set has only been trimmed slightly. we will open-source this as a cousin to Akka Distributed Data.
Special focus has been devoted to pervasive testabili-
ty, both of the implementation and of user-level code. The Dr. Roland Kuhn is CTO and co-founder of Actyx, author of Reactive De-
main difference to untyped actors in this regard is that be- sign Patterns, a co-author of the Reactive Manifesto, co-teacher of the
havior and execution are fully decoupled now, you can cre- Coursera course “Principles of Reactive Programming”, and a passionate
open-source hakker. Previously he led the Akka project at Lightbend.
ate your actor behaviors directly within tests and exercise
them synchronously without using a special TestActorRef or
CallingThread­Dispatcher. This allows convenient validation
of internal logic as well as deterministic stimulation with ex-
ternal inputs. A mock ActorContext can be used to check that
child actors are created correctly, all other effects like watch-
ing/unwatching are accessible as well.
The new implementation is quite a bit faster than the old
one, reducing actor messaging overhead by 20–30 percent
even though the mailbox implementation is not yet optimized.
Once the full potential has been realized, it will be possible to
achieve allocation-free actor messaging. The current breadth
of the implementation covers only local actors without per-
sistence, the plan is to add a custom Materializer for Akka
Streams and reuse Artery in order to have a new basis for the
existing clustering code.
One aspect that I find extremely exciting about Akka Typed
is that it opens up actor interactions to even more static ver-
ification than is afforded by a type-selective ActorRef. Cur-
rent research within the ABCD group [8] has the potential to
enable an actor-based implementation of a verified commu- References
nication protocol to be checked for conformance to the spec-
ification by the Scala compiler (here it might be that Java’s [1] http://www.reactive-streams.org/
type system is not expressive enough to achieve the full fea- [2] http://download.java.net/java/jdk9/docs/api/java/util/concurrent/Flow.html
ture set). This would mean that many bugs would be caught [3] https://github.com/akka/akka-meta/issues/27
without even running a single test, the compiler will tell you [4] http://blog.akka.io/integrations/2016/08/23/intro-alpakka
that you forgot to send a certain message or that you expected
[5] https://github.com/real-logic/Aeron
to receive a message that will never arrive.
[6] https://groups.google.com/forum/#!topic/akka-user/V0DH_e8w7M0
Enabling the compiler to see these actions means represent-
ing them in the type-system and lifting the description of what [7] https://github.com/akka/akka-meta/issues/18
an actor does into a sequence of actions that can be inspected. [8] http://groups.inf.ed.ac.uk/abcd/
This is a powerful tool even without the protocol verification, [9] See my presentation at scala.world, slides at http://www.slideshare.net/
it allows actor behaviors to be composed in ways that were rolandkuhn/distributed-systems-vs-compositionality

www.JAXenter.com | October 2016 11

 Akka

Akka: The Swiss army knife of reactive systems on the JVM

Dedicated to doing the

right thing
Akka is in many ways a very innovative and yet robust technology. Now that it has become generally ac-
cepted that microservice-oriented architectures are a good idea, Akka will play an even more important
role in the reactive system at large and already serves as a foundation for other reactive technologies
such as the Play Framework and Lagom.

by Manuel Bernhardt child actor by specifying a supervisor strategy. Depending on

the type of exception, the failing actor (and if necessary, all of
Akka is one of the most mature technologies available on the its siblings) is then either resumed, restarted or stopped – and
JVM for building reactive applications. It builds on top of the in some cases, the failure is escalated higher in the hierarchy
actor-based concurrency model and is inspired by Erlang (in until someone knows what to do. This separation of failure
fact, the initial name of the project was Scala OTP). The in- handling logic and business logic is a key concept in Akka’s
fluence of the Akka project on the reactive ecosystem is rather design: failure is embraced and treated as a first-class citizen,
significant: Jonas Bonér (Akka’s creator) and Roland Kuhn rather than an afterthought.
(Akka’s former project lead at Lightbend) are the co-authors
of the Reactive Manifesto. The Reactive Streams initiative has Designed from the ground up for distributed systems
been significantly supported by the Akka team. Akka actors are designed in such a way that the physical lo-
cation of an actor should not influence how it can be inter-
Actors as the unit of computation acted with. This concept, known as location transparency, is
Akka applications are comprised of actors that are arranged of paramount importance when it comes to building reactive
in a hierarchy and send messages to each other. An actor’s be- applications which need to be distributed in order to be resil-
havior describes what happens when an actor receives a mes- ient through redundancy and capable to scale out when the
sage: it can alter its state, create a new child actor, forward load demands it. Paradoxically then, distribution itself is a
the message to another actor, reply to the sender or ignore it necessary evil which lies at the root of many failures since
altogether. It is through this set of interactions between actors networks are shaky constructs that fail all the time.
that advanced concurrent applications can be written without Akka promotes a few simple principles to embrace net-
the headaches brought in by thread-based concurrency such work-induced failure: distributed systems are prone to fail-
as unwanted race conditions, data races, deadlocks and live- ure due to their very nature and Akka does not try to hide
locks which are very hard to reason about even for seasoned this behavior. In fact, the Akka team’s mantra is “No Mag-
developers. Akka explicitly takes these pains away by provid- ic”, always making it explicit to its users which guarantees
ing an abstraction at a higher level – but not high enough to Akka can give and what they need to be aware of. First of
hide the fact that the application is concurrent, a trend seen all, messages should be sent in the asynchronous fire-and-for-
in many application servers and frameworks and which has get mode in which the sender does not explicitly wait for an
turned out to be hurtful rather than helpful. answer but later reacts to an answer, using correlation iden-
The actor hierarchy is the secret ingredient that makes Akka tifiers when necessary. Second, first-class failure handling is
applications resilient to failure: each parent actor supervises provided through the previously described actor supervision.
their children, being responsible for what happens in case Third, Akka is explicit as to what guarantees it can give in
of crash. The supervisor decides what happens to the failing terms of message delivery. It provides best mechanism to col-

www.JAXenter.com | October 2016 12

 Akka

lect locally undelivered messages, the so-called “dead letters”, periment first with APIs and implementations (Akka Streams,
providing a means to inspect why certain messages do not for example, has seen as many as six complete rewrites over
make it to their sender, at least locally. However, this mecha- the source of three years before it was deemed good enough).
nism does not work across network boundaries where the use This is also why, when working with Akka, you should al-
of acknowledgements is required to guarantee at-least-once ways be mindful of extensions tagged as experimental in
delivery semantics. In order to build distributed applications, the documentation: there is a real chance that the APIs will
Akka offers some very useful extensions. change significantly over time, which is not necessarily a bad
thing in itself but something to be aware of nonetheless.
Akka persistence, Akka cluster and Akka HTTP Last but not least, Akka has a very active community and
Akka Persistence allows actors to recover their state after a an excellent documentation – so good, in fact, that it is rather
crash. Persistent actors have a journal that allow them to re- difficult to do better when writing a book about it. I can only
play events after a crash; they can also make use of snapshots recommend downloading the PDF and reading the documen-
to speed up the recovery. Journal entries and snapshots can tation as a whole when getting started with the project to get
be stored in a variety of backends such as Cassandra, Kafka, a sense of what pieces are already provided by the toolkit and
Redis, Couchbase and many more. which concepts to be aware of. Happy hAkking!
Akka Cluster lets an actor system run on several nodes
and handles basic concerns such as node lifecycle and lo-
cation-independent message routing. In combination with
Akka Persistance, it provides at-least-once delivery semantics
for messages sent across the wire. It uses a lightweight gossip
protocol for detecting when nodes are failing. Lightbend’s
commercial offering also adds the Split Brain Resolver (SBR)
extension that allows to handle correctly in the face of net-
work partitions, where it may not be trivial to decide which
nodes should be removed and which ones should survive.
Akka HTTP offers client and server capabilities for HTTP
and WebSockets including DSLs for describing URI-based
routing.

One level higher and an interface to the world: Akka

Streams
After several years of building and maintaining actor-based
systems with Akka, it became clear that actors may some-
times still be too low-level of a concept, especially when it
comes to describing advanced scenarios including control
flow and failure handling. Akka Streams represent an answer
to this insofar as they allow to describe sophisticated flow
manipulation “machines” through a rich set of combinators.
Rather than limiting itself to the Akka universe, Akka streams
implement the Reactive Streams API for non-blocking asyn-
chronous stream manipulation on the JVM. Thanks to this,
applications built with Akka Streams can seamlessly inter-
operate with other technologies implementing the Reactive
Streams API.

A drive for quality and innovation

Akka is in many ways a very innovative and yet robust tech-
nology. Now that it has become generally accepted that mi-
croservice-oriented architectures are a good idea – better, at
least, than the vast, monolithic and unmaintainable enterprise
Manuel Bernhardt is a passionate engineer, author, speaker and con-
systems that so many companies are stuck with (and because sultant who has a keen interest in the science of building and operating
of), Akka will play an even more important role in the reac- networked applications that run smoothly despite their distributed nature.
tive system at large and already serves as a foundation for Since 2008, he has guided and trained enterprise teams on the trans-
formation to distributed computing. In recent years he is focusing primar-
other reactive technologies such as the Play Framework and ily on production systems that embrace the reactive application architecture, using
Lagom. Scala, Play Framework and Akka to this end. Manuel likes to travel and is a frequent
In my opinion, it is this dedication to “doing the right speaker at international conferences. He lives in Vienna where he is a co-organizer
of the Scala Vienna User Group. Next to thinking, talking about and fiddling with
thing” that makes Akka such an exciting project and great computers he likes to spend time with his family, run, scuba-dive and read. You can
technology to work with. The Akka team does not fear to ex- find out more about Manuel’s recent work at http://manuel.bernhardt.io.

www.JAXenter.com | October 2016 13

 Play

How to gain more control with compile-time dependency injection

Compile-time dependen-
cy injection in the Play
framework
Play introduced Dependency Injection (DI) in version 2.4 to reduce global state, and make it easier to
write isolated, reusable, and testable code by instantiating components on each reload and by provid-
ing stop hooks. In this article, Marius Soutier explains what compile-time dependency injection in the
Play framework is all about.

by Marius Soutier As Scala developers, however, we don’t like to rely on reflec-

tion, runtime instantiation or to worry about eager bindings.
The Play framework used to have a lot of global state, most Luckily, Play also provides a compile-time DI mechanism.
and for all the current running application that contains In its simplest form, compile-time DI, or any DI for that
things such as the configuration, access to plugins etc. An- matter, means passing dependencies to a constructor or a
other strange thing was the Global object, a singleton used function. All of your dependencies are declared as construc-
not only to register startup and shutdown hooks but also to tor parameters in your classes, be it controllers, actors, or
override error handlers. All of this leaked into the application any other class. When your Play app launches the Applica-
lifecycle and the plugin system. For example, you had to de- tion Loader, which replaces the Global object, it prepares all
fine a plugin priority and make sure external components are dependencies and instantiates your classes by passing their
instantiated lazily and closed after an app restart in develop- dependencies into their constructor. The link from controllers
ment mode. Lastly, global state makes it harder to test your to route handling is made by creating a generated router that
application in a clean way. maps routes to instantiated controllers – again, via their con-
Play introduced Dependency Injection (DI) in version 2.4 structors. From that, the Application Loader assembles and
(Note: this article is up-to-date with Play 2.5) to reduce (Note: provides the current Application.
global state is not completely gone yet, but will be gradually All parts of Play, now called components, support com-
removed in the next versions) global state, and make it easier pile-time DI by providing a trait which ends with Compo-
to write isolated, reusable, and testable code by instantiating nents (Note: a lightweight version of the cake pattern) and
components on each reload and by providing stop hooks. builds on three basic dependencies: ApplicationLifecycle,
Configuration, Environment.
Runtime DI ApplicationLifecycle allows your component to register
The runtime DI mechanism defined by Java Specification Re- a stop hook. Configuration is the TypesafeConfig that you
quest 330, with its reference implementation Guice, has been would previously get from a running application. Environ-
selected as the default DI framework in Play. This makes it ment is a collection of methods that revolve around your
rather straightforward to start writing new Play applications running Play app, such as the classloader, the current mode
without worrying too much about DI, as components are (development, test, or production), and obtaining classpath
injected automatically by using the @Inject annotation. The resources. By extending BuiltInComponentsFromContext,
official documentation on runtime DI is pretty complete so I you get these three provided by Play.
will not go into detail about it. Let’s say we have a small app with one Application con-
troller that needs to make a web service call. Now instead of
Compile-time DI importing Play’s WS which required the current application,
Guice as a standard mechanism makes sense for a framework we mix in a trait at the application loader level and pass a
that offers a first-class Java API. concrete WS instance to the controller.

www.JAXenter.com | October 2016 14

 Play

The controller in turn depends on WSClient – which is just

Listing 1 a trait:
package com.mariussoutier.example
class Application(ws: WSClient) extends Controller {...}

import play.api.{ApplicationLoader, BuiltInComponentsFromContext}

Finally, we need to tell Play to use our Application Loader in
import play.api.libs.ws.ning.NingWSComponents application.conf:
import play.api.routing.Router
import router.Routes // Routes are generated from the routes file play.application.loader="com.mariussoutier.example.AppLoader"

class AppLoader extends ApplicationLoader { While we now have more boilerplate to write, this way of
override def load(context: Context): Application = new building our application has several advantages:
AppComponents(context).application
} • Dependencies on components are more explicit
• We avoid using the current Application
class AppComponents(context: Context) extends BuiltInComponentsFromContext( • We can easily switch to a mocked WS implementation
 context) with NingWSComponents { when writing tests
// NingWSComponents has a lazy val wsClient • When we refer to a new controller in the routes file, the
lazy val applicationController = new controllers.Application(wsClient) compiler will tell us that Routes is missing a dependency
lazy val assets = new controllers.Assets(httpErrorHandler)

override def router: Router = new Routes(httpErrorHandler,

Testing
applicationController) Since we control how our application components are assem-
}
bled, it’s easy to create an ApplicationLoader for our tests.
ScalaTest supports compile-time DI with its OneAppPer-
Suite trait.

Plugins
Listing 2 Play plugins are now deprecated and replaced by DI com-
ponent, which means the entire plugin system is gone, along
class FakeApplicationComponents(context: Context) extends with its configuration file and priorities.
 BuiltInComponentsFromContext(context) { You just provide a component which ideally should be
val mockWsClient = ... // You can use Mockito or https://github.com/leanovate/ compatible with both runtime and compile-time DI. For this,
// play-mockws you typically write a generic API trait and implement it using
lazy val applicationController = new controllers.Application(mockWsClient) a Module or a JSR-330 Provider class, and a components trait
lazy val assets = new controllers.Assets(httpErrorHandler) for compile-time DI.
A basic example to get started is the ActorSystemProvider
override def router: Router = new Routes(httpErrorHandler, in Play itself which is also used in compile-time DI via Akka-
applicationController) Components.
}
Conclusion
By using compile-time dependency injection we gain more
control over how our application is assembled, making it
more testable. Writing isolated and testable components is
Listing 3 now straightforward and no longer requires an elaborate
import org.scalatestplus.play.{OneAppPerSuite, PlaySpec} plug­in system. Plus, we don't have to worry about referring
class ApplicationTest extends PlaySpec with OneAppPerSuite { to an application too early.
override implicit lazy val app: api.Application = { You can find a full example in my PlayBasics repository un-
val appLoader = new FakeAppLoader der https://github.com/mariussoutier/PlayBasics/tree/master/
val context = ApplicationLoader.createContext(
DependencyInjection.
new Environment(new File("."), ApplicationLoader.getClass.getClassLoader,
Mode.Test)
) Marius Soutier is an independent data engineer. He consults companies
appLoader.load(context) on how to best design, build and deploy reactive web applications and
realtime big data systems using Scala, Playframework, Kafka, and Spark.
}
@mariussoutier
}
www.mariussoutier.com/blog

www.JAXenter.com | October 2016 15

Do you speak ours?

We are the leading planning and

performance management platform.

Whatever language you speak—

in person and in code—we want to talk.

Check out our company page on

Stack Overflow or visit anaplan.com
 Lagom

Lagom gives the developer a clear path

The Lagom Framework

Radically different, but nonetheless easy – that is the dichotomy the new open source microservice
framework Lagom is trying to create. What are the features that differentiate it from other frameworks?
How easy is it to handle? What does the name actually mean?

by Lutz Hühnken they – the project’s services, a service registry, an API gate-
way, and even the database Cassandra (in the embedded
The question regarding the meaning of the name is not easy to version) – are launched through the Maven plug-in. It is not
answer since one cannot literally translate the Swedish idiom necessary to set up services or a database outside of the pro-
Lagom. According to Wikipedia, the meaning is: “Enough, ject. Lagom stresses the importance to offer the developer an
sufficient, adequate, just right.” In our case, this is not sup- environment which feels interactive – check out the project
posed to be a self-praise but a critical statement to the concept and get going. This includes the fact that code changes will
of microservices. Instead of focusing on “micro” and stub- come into effect right after a reload, without the need for a
bornly following a “the less code, the better” concept, Lagom build/deploy/restart cycle.
suggests that we think of a concept of “Bounded Context”
from the Domain-Driven Design to find the boundaries for The services API — typesafe and asynchronously
a service. The conceptual proximity of domain driven design As it can be seen from the folder structure, every service is
and microservices can be found in different locations in the divided into an implementation (“-”) and an API definition
Lagom framework. (“-”). The latter defines
the HTTP interface of the
Getting started with Lagom service programmatical-
Listing 2
The easiest way to develop an application with Lagom is with ly, as shown in Listing  3.
the help of a Maven project template: With the help of a build- $ http localhost:9000/api/hello/
er, the service description Lagom
$ mvn archetype:generate -DarchetypeGroupId=com.lightbend.lagom \ will be created, in which HTTP/1.1 200 OK
-DarchetypeArtifactId=maven-archetype-lagom-java \ the requested path will be Content-Type: text/plain
-DarchetypeVersion=1.1.0 mapped on a method call.
This interface is not Hello, Lagom!
After the questions regarding names have been answered and only the template for im-
you switch into the newly-created directory, you will find the plementation; Lagom also
directory structure as displayed in the Listing 1. generates an appropriate Listing 3
As it should be for microservices, not one, but already two client library. In other
services were generated. After all, the interaction and com- Lagom services, this can public interface HelloService extends
munication between services are at least as important as the be injected via dependen-  Service {
implementation of a single on (and frequently the bigger cy injection with Google’s
challenge). Here are the services “hello” Guice. This way, a type- ServiceCall&ltNotUsed, String&gt
and “stream”; each implementation is safe interface is provided  hello(String id);
Listing 1 divided into two subprojects (“api” and when the respective service
“impl”). To launch the application, a is selected. The manual default Descriptor descriptor() {
cassandra-config
simple mvn lagom:runAll is enough. Af- construction of an HTML return named("hello").withCalls(
hello-api
ter a few downloads, should be running request and the direct use pathCall("/api/hello/:id",
hello-impl
at Port 9000. This can be easily checked of a generic http client can this::hello),
integration-tests
with a command line tool like HTTPIE be omitted. );
pom.xml
(Listing 2). Still, it is not mandatory }
stream-api
One particularity that all components to use the client library be- }
stream-impl
needed in the development have is that cause the framework maps

www.JAXenter.com | October 2016 17

 Lagom

the method calls on HTTP calls, which may also be called we ask an unnecessary amount of idle time from our appli-
directly, especially by non-Lagom-services. cation: If it’s likely that we won’t be getting a response, why
By the way, our little “hello” method doesn’t deliver the should we wait for a timeout? Furthermore, there would be
response directly, but a ServiceCall. This is a functional in- requests accumulating to the service. As soon as it becomes
terface. That is to say we do not create a simple object but a available again, it will be bombarded with pending requests
function – the function which shall be executed by the corre- to such an extent that it will be brought to its knees immedi-
sponding request. We deliver the types as type parameters for ately. A reliable solution for this problem is the circuit break-
the request (since user GET call doesn’t submit any data, in er pattern. A circuit breaker knows three states:
this case “NotUsed”) and the response (in our case a simple
String). The processing of the request is always asynchronous • As long as everything is running without errors, it is
– the outcome of our function must be a CompletionStage. closed.
Lagom extensively uses Java 8 features. A simple implemen- • If a defined limit of errors (timeouts, exceptions) is
tation would look like this (Listing 4). reached, it will be open for a defined period of time. Addi-
For a simple GET request, the gain of the service descrip- tional requests will fail with a “CircuitBreakerException”.
tors is limited. It gets more interesting when we want to send For the client there won’t be additional waiting time and
events between services asynchronously. We can achieve the external service won’t even notice the request.
this in Lagom by choosing different type parameters for the • As soon as the set time period runs out, the circuit breaker
ServiceCall. If our request and response types are defined as will switch into the state “half open”. Now there will be
source (a type from the Akka streams library), as shown in one request passed through. If it is successful, the circuit
Listing  5, the framework will initialize a WebSocket link. breaker will be closed- the external system seems to be
Here the service abstraction can score since it simplifies work- available again. If it fails, the next round with the state
ing with the WebSockets. As far as future versions are con- “open” begins.
cerned, there are plans to support the additional “publish/
subscribe” pattern so that messages can be placed on a bus Such circuit breakers are already integrated into the Lagom
and other services can subscribe to it. service client. The parameters are adjustable with the config-
uration file.
Circuit breaker built-in
Let us assume that our service requests information per HTTP Lagom persistence
request at another service. This doesn’t respond within the One aspect which proves that Lagom is very different from
expected timeframe, which means there will be a timeout. Re- other micro frameworks is the integration of a framework for
quests to this server shouldn’t be repeated constantly because Event Sourcing and CQRS. For many developers, working
with a relational databaseis still the “default case”, possibly
in connection with an ORM tool. Even this can be imple-
Listing 4 mented in Lagom, but the user is steered into another direc-
public class HelloServiceImpl implements HelloService { tion. The standard in Lagom is the use of “Persistent Entities”
@Override ( corresponding to “Aggregate Roots” in Domain-Driven de-
public ServiceCall&ltNotUsed, String&gt hello(String id) { sign). These Persistent Entities receive messages (commands).
return request -&gt { Listing 6 shows exactly how this is presented in the code.
CompletableFuture.completedFuture("Hello, " + id); Our quite simple entity allows us to change the welcome text
}; for our service. We extend the superclass PersistentEntity
} which expects three type parameters: the command type, the
} event type, and the type of the state. In our case we define the
command as a class UseGreetingMessage, which implements
the interface HelloCommand and its instances are immuta-
ble. For type-saving purposes, one can go back to commands,
Listing 5 events and states from the library Immutables. To save your-
self some keystrokes, you can leverage a library such as Im-
public interface StreamService extends Service {
mutables for your commands, events and states.
The way our entity responds to commands is defined by
ServiceCall&ltSource&ltString, NotUsed&gt, Source&ltString, NotUsed&gt&gt
a behavior. This can change at runtime. This way the enti-
stream();
ties can implement finite-state machines – the replacement of
one behavior with another at the runtime correlates with the
@Override
transition of the machines into another state. The framework
default Descriptor descriptor() {
obtains the initial behavior via initialBevahior. To construct
return named("stream").withCalls(namedCall("stream", this::stream));
this, we will make use of the builder pattern.
}
First, we define a CommandHandler as our command. If a
}
command is valid and demands the entity to be changed, for
example, in case it sets an attribute to a new value, the change

www.JAXenter.com | October 2016 18

 Lagom

won’t occur immediately. Instead, an event will be created, Separate writing and reading
saved and emitted. The EventHandler of the persistent entity While it is easy in SQL databases to request any informa-
which we also added with the builder to the behavior, reacts tion from the data model, it is impossible in the case of Event
to the event and executes the actual change. Sourcing. We can only access our entity and request the state
A significant difference to an “Update” in a relational data- with the primary key. Since we only have an Event Log and
base is that the current state of the persistent entity does not not a relational data model, queries through secondary indi-
necessarily have to be saved. This will be merely held in mem- ces are impossible to make.
ory (Memory Image). In case it becomes necessary to restore To enable this, the CQRS architecture (Command Que-
the state, e.g. after a restart of the application, this will be ry Responsibility Segregation, for further reading: A CQRS
reconstructed through a playback of the events. The optional Journey , https://msdn.microsoft.com/en-us/library/jj554200.
saving of the current state in called “Snapshot” in the model aspx) is applied. The basic principle here is that different data
and does not replace the Event history, but solely represents models are used for reading and writing. In our case this
a “pre-processing”. If an entity experienced thousands of means that our Event Log is the write side.. It can be used to
changes of state during its lifetime, there is no need to play reconstruct our entities, but we won’t perform any queries
back all the events from the very beginning. It is possible to on this. Instead, we also generate a read sidefrom the events.
shortcut by starting with the latest snapshot and repeating Lagom is already offering an ReadSideProcessor. Every event
only the following events. which occurs in combination with a class of PersistentEntities
The strict specifications that Lagom gives for the types and will also be processed and used to create the read side. This
the structure of the behavior are meant to ease the conversion is optimized for reading and doesn’t allow for direct writing.
to this principle, called Event Sourcing, for developers. The This architectural approach does not only offer technical
idea is that I am forced to specify a clear protocol for each advantages, since in many application cases the read and
entity: Which commands can be processed, which events can writing frequency are very different and they are scaled inde-
be triggered and which values define the state of my class? pendently with this method. It also enables some new possi-
bilities. As a consequence of never deleting the saved events, it
Clustering included is possible to add new structures on the read side, the so-called
The number of Persistent Entities that I can use is not limited projections. These can be filled with the historical events and
by the main memory of a single server. Rather, every Lagom thus can give information not only in the future but also from
application can be used as a distributed application. During the the past.
start of an additional instance I only have to add the address CQRS allows the use of different technologies on the read
of an already running instance, after that it will register there side, adjusted to the Use Case. It is conceivable while not sup-
and form a cluster with the present instances. The Persistent ported by Lagom yet, that one can build an SQL read sideand
Entities are administered by the framework and will be dis- continue the use of available tooling, but simultaneously feed-
tributed automatically within the cluster (Cluster Sharding). If ing an ElasticSearch database for the quick search and to send
nodes are added to or removed from the cluster, the framework the events for analysis to Spark Streaming. It is important to
will redistribute the instances. Likewise, it can restore instances keep in mind that the read sidewill be refreshed asynchro-
which were removed from the memory (Passivation). nously, with latency (“Eventual Consistency” between the
By the way, the built-in feature to keep the application state write and the read side). Strong consistency is only available
in the memory this way and also to scale this hasn’t been de- in this model on the level of the PersistentEntity.
veloped for Lagom originally. For this, Lagom relies on Akka. Finally, it is also possible to code Lagom without Lagom
This has definitely been used in mission-critical applications , Persistence. It is not mandatory to use Event Sourcing; the de-
therefore any concerns regarding the reliability of the young velopment of “stateless” – Services, or “CRUD” applications
framework are not well-founded. (Create, Read, Update, Delete) with a SQL database in the

Listing 6
public class HelloEntity extends PersistentEntity& snapshotState.orElse(new HelloState("Hello", /*
 ltHelloCommand, HelloEvent, HelloState&gt { LocalDateTime.now().toString()))); * Event handler for GreetingMessageChanged.
*/
@Override /* b.setEventHandler(GreetingMessageChanged.class,
public Behavior initialBehavior(Optional& * Command handler for UseGreetingMessage. evt -&gt new HelloState(evt.message,
 ltHelloState&gt snapshotState) { */ LocalDateTime.now().toString()));
b.setCommandHandler(UseGreetingMessage.class,
/*  (cmd, ctx) -&gt return b.build();
* The behavior defines how the entity reacts on ctx.thenPersist(new }
* commands. GreetingMessageChanged(cmd.message), }
*/ evt -&gt ctx.reply(Done.getInstance())));
BehaviorBuilder b = newBehaviorBuilder(

www.JAXenter.com | October 2016 19

 Lagom

backend is also possible. But if someone is interested in Event language always comes the fear of a temporary decrease in
Sourcing and CQRS, in scalable, distributed systems, Lagom productivity because developers cannot revert to familiar
can help them gain access into the topic. practices and resources. It is the same in our case.
Lagom is trying to prevent this by giving the developer a
Immutable values — Immutables clear path. If I follow the documentation of the textbook ap-
As mentioned earlier, the single commands, events and in- proach for service implementation and persistence in Lagom,
stances of the state must be immutable. Immutable data struc- I will be able to build a reactive system – completely based
tures are an important concept from the functional coding, on messaging and being able to cluster, maybe even without
especially in the area of concurrency. Let us assume a method realizing it.
gets passed a list of numbers. The result is a value that is In the relatively new area of microservices, standards are
calculated from the list (maybe a meridian of the numbers of yet to be established. We will have to see which frameworks
the list). By reasoning about this or maybe in some cases even can stand the test of time. In contrast with old acquaintances
through mathematical proof, you may state that a function is from Java EE and Spring, Lagom instills new life into this and
correct and will always deliver the same output for the same is putting a whole different architecture in the balance. Those
input. who wish to try something new and are interested in scalable
But what if the delivered list is e.g. an ArrayList – how can distributed systems will find Lagom helpful.
we be sure? Fix is only the reference that is delivered. But
what if another part of the program that is executed in paral-
lel has the same reference? And adds some values to the list?
In asynchronous systems that are based on sending the com-
mands, it is essential that a command must not be changed
after it has been sent. To rely on the fact that the developer
will be careful would be negligent.
Lagom uses third party libraries for this. For the commands
it binds Immutables, for collections pCollections. If I add a
value to a collection from this library, the original collection
will remain unchanged and I will receive a new instance with
an additional value.

Deployment
Microservices provide a challenge not just for the developer
but also for the ongoing operation. In many companies the
deployment processes are still set up for the installation of
.war or .ear files for application servers. But microservices
are running standalone and are often packed into (Docker)
containers and administered by the so-called service orches-
tration tools like Kubernetes or Docker Swarm.
Lagom requires such an environment, too. But it does not
depend on a certain container standard (like Docker). It re-
quires the runtime environment to have a registry which is
searchable through other services. To be accessible, it must
make an implementation of the Lagom ServiceLocator API
available.
Unfortunately, at the moment it is only available for the
commercial closed-source product ConductR. The open
source community is working on the implementation for Ku-
bernetes and Consul. Alternatively, a ServiceLocator based
on static configuration can be used, but this is not recom-
mended for production use.

Conclusion
Lagom follows an interesting path and is a remarkable
framework. It’s fundamentally different in its technical base:
Everything is asynchronous, it is based on sending commands
and persisting is done per Event Sourcing. This brings tre- Lutz Hühnken is Solutions Architect at Lightbend. He is an experienced
mendous advantages for the scalability of services – but for software architect, project manager and team leader, with a history of
successful projects in systems integration, internet/e-commerce and
most developers (including everybody from the Java EE area), server-side application development in general.
this means rethinking. With the change of a programming

www.JAXenter.com | October 2016 20

 Apache Spar

SMACK – Next generation Big Data

Big Data becomes

Fast Data
Big Data is changing. Buzzwords such as Hadoop, Storm, Pig and Hive are not the darlings of the
industry anymore – they are being replaced by a powerful duo: Fast Data and SMACK. Such a fast
change in such a (relatively) young ecosystem begs the following question: What is wrong with the cur-
rent approach? What is the difference between Fast and Big Data? And what is SMACK?

by Jochen Mader to the capability of a system to deliver results in a set time-

frame. Breaking controllers, medical devices and many parts
Google retired MapReduce at I/O 2014: By then, one had al- of satellites need to be Real Time-capable to prevent catastro-
ready switched to the new Dataflow framework and removed phes. A brake needs to react quickly when a pedal is pushed,
the existing MapReduce jobs. This announcement caused a stir otherwise the driver will get a serious problem. It’s not about
since Hadoop and its ecosystem were still seen as ‘innovative’. “the answer comes as quickly as possible”, but about “the an-
After a few apocalyptic blog posts and some vigorous debate, swer will come within the time span”. Much more appropriate
calm was restored. Many companies dipped their toes into would be the term Near Time to describe what Big Data and
the Big Data universe but learned a valuable lesson, namely Fast Data applications are trying to become.
that the limits of many technologies are too restricted for the With Near Time, incoming Data  (1) is consumed by two
desired periods of analysis. A new concept was needed. The layers. Within the Batch Layer, long distant runner analysis is
following article will show you how Big Data (on Hadoop) being processed on the deployed raw data. The results of this
became Fast Data (with SMACK). analysis will be provided to the Serving layer (4), where they
can be demanded by clients. The Speed Layer (3) relinquishes
At the beginning there was Lambda performance hungry persistence solutions and fulfills most of
Over the years, the big data world evolved into a confusing its duty in the main memory. Since it can never get hold of all
zoo of interwoven frameworks and infrastructure compo- data at the same time, it must focus on a subset. Certain results
nents. HDFS, Ceph, ZooKeeper, HBase, Storm, Kafka, Big, can thus be determined a lot faster. In the end, the aggregates
Hive etc. Many of these components are highly specialized will also move into the serving layer and can be related to the
and depict only a subset of the intended functionality. Only results of the batch layer. On closer inspection, the bidirection-
their – not very unproblematic – combination allows for the al relation between serving and speed layer stands out. Certain
execution of more complicated use cases. Over time, it has values can be accessed as distributed in-memory data struc-
been shown that many frameworks can be divided into two tures e.g. distributed counters and can be gripped live.
different groups: On the one side we have the frameworks
that respond immediately (passage: “Real Time”). This cate- Redundant logic can be problematic
gory contains Storm, Samza, different CEP engines, but also In these three layers, many technically elaborated frame-
reactive frameworks like Akka, Vert.x or Quasar. The other works have been established and have bred success in re-
group consists of frameworks that require some time to re- cent years. But growing success triggers bigger requirements.
spond. Here everything is based upon MapReduce, e.g. Pig New analysis should always be formulated faster and in a
or Hive. Since both groups usually appeared together, a cer- more flexible way. Results needed to be seen in different res-
tain style of architecture came into being. This triggered the olutions: second, minute, hour, or day. MapReduce quickly
name Lambda Architecture [1] by Nathan Marz (Figure 1). reached the limit of what is possible. Thanks to its flexibility
and significantly lower response times, more and more analy-
Real Time sis moved into the speed layer. However, this did not result in
Unfortunately, most people understand something totally dif- less logic in the batch layer. Since the in-memory processing
ferently when they hear the name Real Time. This terms refers is limited by the size of the main memory, many studies still

www.JAXenter.com | October 2016 21

 Apache Spar

But even Spark has its limits. Tools for data de-
livery and persistency are still necessary. This is
where we can resort to the experience of recent
years.

Enter the SMACK

One often hears of Spark in conjunction with
the SMACK stack – the combination of known
technologies from different areas of Big Data
analysis into a powerful base framework. The
acronym SMACK stands for Spark, Mesos,
Akka, Cassandra, and Kafka.
At first glance, one might assume that some-
body has opened the hipster technologies box.
Figure 1: Lambda architecture I suppose you have at least heard of any of the
aforementioned frameworks before. But I would neverthe-
need to be carried out in batches. The often incompatible less like to explain the tasks they fulfill in the stack context
programming modules meant that a lot of logic needed to briefly.
be implemented several times. Such redundancies could lead Apache Mesos [2] is a kernel for distributed systems. It rep-
to severely different results when evaluating the same data resents an abstraction layer over a cluster of machines. Rather
sources. At this point, it is clear why a unified programming than deploying an application on one note, it is, alongside one
model which covers large areas of the analysis is desirable. requirement description (number of CPUs, required RAM
etc.), passed to Mesos and distributed to appropriate ma-
The birth of Fast Data chines. That way, several thousand machines can be specifi-
In 2010, the AMPLab at the University of California, Berke- cally utilized pretty easy. Mesos is the central nervous system
ley published a new open source analysis tool which should of the stack. Every component of the SMACK stack is avail-
solve this exact problem. Spark was donated to the Apache able in Mesos and perfectly integrated into its resource man-
Software Foundation in 2013 and has undergone an impres- agement. In addition, the commercial version Mesosphere is
sive development ever since. In essence, everything regard- already available on Amazon AWS and Microsoft Azure. A
ing Spark revolves around the so-called Distributed Resilient convenient cloud data center can thus be built in record time.
Data Sets (RDD): distributed, resilient, parallelized data The reactive framework Akka [3] is based on the known
structures. These can be used in conjunction with many dif- author model from Erlang. In recent years, Akka has evolved
ferent modules: into one of the leading frameworks for distributed, resilient
applications. In this context, it is mainly used in ingestion
• Processing of graphs (GraphX) range and as access layer in the serving layer.
• Spark SQL, to deal with data from various structured data Another member of the Apache ecosystem is Cassandra [4].
sources (Hive, JDBC, Parquet etc.) Cassandra is a distributed, resilient, scalable database capable
• Streaming (Kafka, HDFS, Flume, ZeroMQ, Twitter) of storing gigantic amounts of data. It supports the distribution
• Machine Learning based on MLib across multiple data centers and survives the concurrent failure
of multiple notes. In this case, it is used as primary data storage.
Besides Scala, Spark also supports Python and R. This makes Apache Kafka [5] is often considered a distributed messag-
it easier for data scientists to use it if they are familiar with ing system – and that is true for the most part. In fact, it is
one of the two. As you can see from the above-mentioned list, nothing more than a distributed commit log. Its simple struc-
Spark is a fairly connection joyous framework and is thus ture allows users to transfer huge amounts of data between a
able to combine many of the existing data sources in a unified number of systems, and thereby to scale linearly.
API. The resulting analysis framework has prevailed rapidly. When put together, they form a solid base for Fast Data
The combination of structured data sources and streams infrastructures (Figure 2): Akka (1) consumes incoming data
makes it possible to combine much of the speed layer with the like MQTT events, click streams or binaries and writes it di-
batch layer into a single interface. Analysis can be performed rectly into corresponding topics in Kafka (2). Now that the
in almost any resolution. Spark jobs can even be deployed and data persists, we can decide how fast we want to get different
developed by non-developers in an astounding timeframe. answers. Various Spark jobs (3) consume the data and inter-
The arguments for Spark are quite clear: pret it into different resolutions:

• Scalability – to deal with millions of data sets • Raw data persistency: A job that writes incoming raw data
• Fast enough to provide answers in Near Time to S3, HDFS or Ceph, and prepares it for later processing.
• Suitable to implement analyses of any duration • Speed Layer: Implementation of “quick win”-analyses,
• A unified, comprehensible programming model to handle whose results are measured in seconds.
various data sources • Batch Layer: Long-termanalysis or machine learning

www.JAXenter.com | October 2016 22

 Apache Spar

Figure 2: The SMACK stack: a solid base for Fast Data infrastructures

Results are written to HDFS (5) and Cassandra (4), and can which they are being used. Existing components will, thanks
be used as input for other jobs. In the end, there is Akka again to Spark, be usable within one unified programming model.
as HTTP layer to display the data e.g. as a web interface. Spark is just a tool. Much more important are the goals be-
hind the catchphrase “Fast Data”:
Automation clinches
In addition to technical core components, automation is a key • Low entry barrier for Data Scientists
point in determining the success or failure of a real Fast Data • Differences between Speed and Batch Layer will disappear
platform. And Mesos already provides many important basic • Exploratory analyses will be significantly easier
components for that. Nevertheless, we will continue to need • The deployment of new jobs will be easier and faster
tools like Terraform, Ansible, Kubernetes and comprehensive • Existing infrastructure is easier to use
monitoring infrastructures. At this point it should be clear
where I am heading: Without DevOps, it is difficult to achieve SMACK offers a combination of all those goals and relies
the goals set. Cooperation between developer and operator on proven technologies. The key lies in their use and in their
is essential for a system, which is intended to elastically scale highly automated combination. The result is a platform which
and work on hundreds of machines. is hard to beat in its flexibility.

To Scala or not
Scala is notoriously the parting of the ways. However, I want
this article to deliberately initiate another debate on language
features. In this particular case, the normative power of real-
ity slams because every framework used is either written in
Scala or is very Scala-like:

• Akka: written in Scala; primary API in Scala, but also

available in Java
• Spark: written in Scala; primary API available in Scala,
Python and R
• Kafka: written in Scala; integrated into Spark and little
direct coding is necessary (however, since 0.9 primary Java
API)
• Cassandra: written in Scala; Interaction primarily takes
place via CQL and Spark integration

A SMACK developer will not get past Scala code. Scala is the
pragmatic choice if you want to succeed with the stack.

Conclusion Jochen Mader is a lead IT consultant at the codecentric AG. He also

Hadoop is not dead. In the future, HDFS, YARN, Zoo- speaks at conferences, is the author of a broad range of articles and is
Keeper and Co. will still remain important components of interested in everything that makes software development exciting.
our Big Data world. However, what changes is the way in @codepitbull

www.JAXenter.com | October 2016 23

 Interview

Interview with Heiko Seeberger, Daniel Westheide, Daniela Sfregola,

Julien Tournay, Markus Hauck and Ivan Kusalic

“Expert checklist –
Why Scala and not Java?”

Which is the most popular JVM language and where are we heading to? We asked six Scala develop-
ers to weigh in on the state of Scala and answer some questions regarding the past, present and fu-
ture of this programming language.

JAX Magazine: Why are you a Scala developer? What fasci-

nates you personally about Scala? Portraits
Heiko Seeberger: What fascinates me about Scala is the pos-
Heiko Seeberger is a Fellow at codecentric. He has been
sibility to write code that is not only concise, but also compre-
a Scala enthusiast ever since he came to know this
hensive. The best examples for that are the case classes that
depict immutable value objects with “built-in” implementa- fascinating language in 2008. Deeply interested in
tions of equals and hashCode and the pattern matching which distributed computing he became a contributor to the
is basically “switch on steroids”. In Akka, these features are amazing Akka project in 2010. Heiko tweets as @hseeberger and
used to define how actors react to messages (Listing 1). blogs under www.heikoseeberger.de.
If you want to implement this example into Java code, you Daniel Westheide works as a Senior Consultant at innoQ
would hava to switch the one line case classes with multiple Germany and has been developing server applications on
line classes including fields, getters and implementations for the JVM for the past seven years. He is interested in
functional programming and distributed systems. Daniel
Listing 1 is the author of the e-book “The Neophyte’s Guide to Scala”.

```
Markus Hauck works as an IT consultant and Scala
case class User(id: Long, name: String, email: Email)
trainer at codecentric. His passion lies in functional
programming and expressive type systems.
case object GetUsers
Ivan Kusalic is a software engineer working for HERE, a
case class AddUser(name: String, email: Email)
Nokia business in Berlin. He is an active member of
case class RemoveUser(id: Long)
Berlin’s Software Craftsmanship community. Ivan is
coorganising SoCraTes 2015, International Software
class UserRepository extends Actor {
Craftsmanship and Testing Conference.
...
override def receive = { Daniela Sfregola is tech leader at PayTouch.
case GetUsers      => // do stuff
case AddUser(n, e) => // do stuff
case RemoveUser(i) => // do stuff
} Julien Tournay is CTO at @mfg_labs and author of jto/
... validation.
}
```

www.JAXenter.com | October 2016 24

 Interview

‘equals’ and ‘hashCode’. And instead of pattern matching you EE or the Spring ecosystem. The projects developed by Light-
would have to work with ‘instanceof’ and type casts. Even bend share a vision of what they think Scala should be. They try
though some modern IDEs help you with that, the resulting to make everything they build usable to Java developers. For
code is much more verbose and ambiguous. Unlike Scala, example you can use Play without writing a single line of Scala
Java is not as focused on the "What." code. Of course there’s a trade-off here. Developing for both
JAXmag: Why Scala and not Java? In your opinion, what languages requires more time. It can also be hard to design an
are the reasons to chose Scala over Java? API that is usable by a Java developer, while not impacting the
Daniel Westheide: In addition to the often mentioned design of its Scala counterpart.
powerful type system, there is an entire list of reasons why But just like the fact that Java is not limited to projects devel-
I would choose Scala over Java: I would like to emphasize oped by Oracle (Spring is an excellent example of that), Scala is
two reasons which are somehow connected to each other. not limited to Lightbend’s initiatives. The work done by Type-
First of all, with Scala you are able to define algebraic data level is especially interesting to me. They are pulling Scala into
types. The other benefit is pattern matching which allows more functional ways and are also building a coherent ecosys-
you to work with readable code and the aforementioned tem. I think people coming to Scala from a Java background
data types. The following example shows both pattern will probably start using Lightbend’s technologies and move
matching and algebraic data types in action. We define an some projects to Typelevel after a few months – once they’ve
algebraic data type session and discriminate between the become comfortable with more functional ideas.
session of a logged in user and an anonymous session. We
then use pattern matching to return either a personalized JAXmag: For what kind of applications can we use the stack?
suggestion or a general one (Listing 2). Markus Hauck: The stack is really useful for creating ap-
plications that have to react very fast and / or scale to big
JAXmag: Some people say that after Java 8 introduced lamb- amounts of data. At the same time, it is modular enough to
da expressions, Scala lost a bit of its appeal because func- give the user the opportunity to choose and use only those
tional programming is now also possible directly in Java. parts they really need.
What’s your take on that?
Daniela Sfregola: I don’t think Scala lost its charm after JAXmag: Work has begun on Scala 2.12 . What do you find
lambda functions were introduced in Java 8. Quite the oppo- most interesting in this release?
site actually! Java is still missing a lot of features that Scala Ivan Kusalic: I’m really interested in the style checker –
can offer such as implicits, for-comprehensions, traits, type Scala syntax is very flexible which is actually great, but as a
inference, case classes, easy currency support, immutable col- consequence it requires extra effort to have consistency in a
lections….and much more! Introducing lambda expressions bigger codebase. In my team we currently take care of that in
in Java 8 is an opportunity for OO developers to start tasting code reviews, but it takes a while for new team members to
the power of functional programming – before going all the increase the speed.
way to the dark force with languages like Scala or Haskell.
JAXmag: Could you name something that you still miss
JAXmag: An entire stack was formed around Scala; it con- in Scala and would like to be implemented in the next re-
sists of Akka, Play, Lagom, Apache Spark and others. How lease(es)?
can we define this stack? Is it an alternative model for Java Heiko Seeberger: Scala has been around for awhile and has
EE or Spring? Is it a loose set of interesting technologies or collected some burdens. Martin Odersky, the creator of Scala,
is there a closer relationship between these technologies? is currently working on the next major release: 3.0. Some of
Julien Tournay: It’s true that the Scala open-source commu- the old things will be dropped once the 3.0 version is released.
nity is very active. Spark is of course a huge driver of Scala’s
adoption. The technologies you’re mentioning are mostly de- JAXmag: Should Scala move more in the direction of a main-
veloped by Lightbend, the company behind the Scala language. stream language like Java in the future (and possibly value
Java EE and Spring are both large ecosystems so yes, projects more things like backwards compatibility)? Or would you
in the Scala ecosystem are competing with projects in the Java rather welcome more innovative features (which could pos-
sibly break backwards compatibility)?
Julien Tournay: Backward compatibility is extremely im-
Listing 2 portant and one should be wary of breaking it at a language
level. The Python community has learned this the hard way
sealed trait Session since the release of Python 3.0 – which, after all these years,
case class LoggedInAs(userId: String) extends Session has failed to exceed Python 2. Overall I hope the Scala lan-
case object Anonymous extends Session guage will continue to evolve and improve. I follow the work
def showRecommendations(session: Session): List[Recommendation] = session Dotty does (the next major version of Scala) with a lot of
 match { interest.
case LoggedInAs(userId) => personalizedRecommendationsFor(userId) Read the full interview on www.JAXenter.com.
case Anonymous => trendingArticles
}

www.JAXenter.com | October 2016 25

 DevOps

Modern DevOps – Connecting business and IT

DevOpsCon 2016: Our

mission statement. This
is how we interpret mod-
ern DevOps
DevOpsCon 2016 will take place in Munich between 5–8 December. What is the idea behind DevOps­
Con? How does this conference bring together a broad range of topics such as Continuous Delivery to
Microservices, Cloud, Container and Corporate Culture? Program-Chair Sebastian Meyen will give you
some insights in this article.

by Sebastian Meyen shares, others are already making steps toward an open,
hard-to-plan future. Consistent digitalisation and high-per-
Modern DevOps: Connecting business and IT: Bringing teams formance IT-structures are imperative – as demonstrated by
from different fields together in a good way is rarely easy, renowned companies such as Netflix, Spotify, and Uber.
when those teams are involved in the same business process- What exactly are the driving forces in business towards a
es but do not work together directly. That’s why a group of DevOps culture (Figure 1)? Allow me to start by naming some
people led by Patrick Debois suggested a new concept back in (although certainly not all) buzzwords:
2009: DevOps. They offered a solution to tackle the problem
which exists in both development (Devs) and administrative
(Ops) level. The DevOps movement developed substantially
and made fundamental changes to basic concepts in IT and
their roles in organizations.

Business-driven DevOps
Originating from the idea of making processes in conven-
tional IT settings – classic on-premise-server, separated dev-
and ops-departments – smoother, the DevOps movement is
now mostly concerned with consistent digitalisation and ar-
eas with a high pressure to innovate.
Powered by the internet, many industries are subjected to
an increasing pressure to change. While some are still look-
ing back half-heartedly at their losses in traditional market Figure 1: DevOps culture

www.JAXenter.com | October 2016 26

 DevOps

• Globalization results in increased competition in almost all developers) to try something new because they know a path
industries. once taken can always be corrected if new insights suggest so
• The internet is more than just a modern marketing and is part of the world we live in right now.
sales platform for traditional fields of business. It has the Continuous Delivery is putting gentle pressure on develop-
power to transform classic business models, modify them ers to optimize their software for smooth deployment. Devel-
or make them obsolete altogether. opers will put more thought into architectural concerns and
• Disruption is not an exception, but will be the norm in technical details that are important for deployment when they
most markets. The ability to innovate will, therefore be- are responsible for transferring applications to real life, rather
come the key to success for companies. than just take responsibility for applications in test environ-
• Therefore, markets cannot be perceived as stable, mak- ments.
ing long-term planning obsolete. Iterative strategies and
many changes will become essential for companies’ success. Microservices
Microservices are modeled with one goal in mind: to reduce
complexity in software systems. The theory reads as follows:
Five factors of DevOps By “cutting” software into small “bites”, inherent complexity
Modern DevOps does more than just bring together Devs and can be reduced. This revelation is added to the long history of
Ops; it aims to integrate business and IT across teams and ideas on modularity of software in IT (from object-oriented
systems. We would like to discuss the relationship between programming and component orientation to SOA and even
business and IT with speakers from around the world at our modularizations like OSGi and Jigsaw.)
Dev­OpsCon conference which takes place between 5–8 Decem- Dependencies between parts of the system, being responsi-
ber. ble for problems around complexity, are eliminated this way;
I will now try to outline the most important movements when working with microservices, they can be resolved by
which can bring a sustainable change towards DevOps if using APIs: When you change a service, you are obligated to
brought together. I would also like to talk about what inspired consider “neighbouring services” to ensure the API stays con-
us – myself and Peter Rossbach – to design the program of our sistent. You need to keep this important goal in mind through-
DevOps conference. If we want to make extensive changes, the out all development and deployment activities. If you have to
gradual improvement of conventional systems is not enough. change an interface, it’s easier to explicitly tell all neighbouring
We need to focus on the following aspects: services and initiate a cooperative plan to kick off the change.
There is no need to use the same technologies for all micro-
1. Continous Delivery services (one can be written in Java, another in Ruby on Rails,
2. Microservices the next one in Go in the cloud …). Many experts see this as an
3. Cloud Platforms advantage. We are merely mentioning this aspect as a side note;
4. Container Technology its relevance to the DevOps perspective is not a major one.
5. Business Culture It is important to mention that microservices should not be
seen simply as a new style of architecture which can replace
Let’s take a closer look at each of these five factors and how other architectures and lead to better technical results. Micro-
they come together. services represent a new solution not only for technology but
also for the organisation. It makes sense to use microservices
Continuous Delivery when you wish to change certain things beyond technology.
Continuous Delivery – automating each and every aspect of These encompass:
delivery – has been an important aspect for online companies
for quite a while. Bringing bugfixes, modifications and new 1. Autonomous, self-organising teams, each taking full
features into production as fast as possible without taking too responsibility for one (micro-)service.
big a risk represents a very important goal. 2. Technical considerations are not the driving force
Such companies usually don’t bring new software releases behind the design of such services; functional con-
into production every six months; they don’t just do that every siderations are (explaining the vast popularity of do-
month or even every day but in most cases several times a day! main-driven design in the field of microservices).
Why is it that many small releases are better suited for such 3. “You build it, you run it”, this quote by Werner Vogels
teams than just a few big ones? Because this prevents large (CEO at Amazon Web Services) is a description of the
backlogs from building up in the first place. Pending work? responsibilities of microservice teams. They are not just
Doesn’t fit into the mindset of continuous delivery propo- responsible for developing an application, but also for
nents. Important changes to usability or improvements to per- its full lifecycle, meaning deployment, monitoring, bug
formance don’t have to wait until the next big release, they are fixing, optimizations, further development …
put into production immediately. Even if that code does not 4. Furthermore, microservice teams are often cross-func-
stay the same too long, these modifications can also be rolled tional – that is to say, there might be operations/plat-
out without delay. form experts in the team, in addition to application
This culture of welcoming well thought-through exper- developers; quite often domain experts, marketing spe-
iments, encouraging all contributors (not just application cialists and designers join the team too.

www.JAXenter.com | October 2016 27

 DevOps

5. Microservices are beneficial in the long run only to such releases frequencies, IT can be seen as an agile and ductile
organizations which are seeing them not just as some medium instead of a rigid shell that needs huge investments
technical innovation, but as a way to follow their busi- to initiate change.
ness goals. Microservices facilitate such automated deployments by
substantially reducing volume and complexity of the arte-
facts to deploy. They help companies focus on business goals,
Cloud meaning that they do not let software infrastructures defined
Modern cloud platforms represent more than an opportunity in the past decide the layout and focus of departments; in-
to transfer applications to public data centres. In fact, they are stead, they help companies focus on goals and services that
offering plenty of technical services which are challenging the make sense business wise.
conventional ways of building and using software. Furthermore, crossfunctional microservice teams promise
Where can the consequences of this cloud paradigm be seen to nullify classic boundaries between specialty departments/
in reality? You need to put some serious effort into deploying marketing/design/development/operations and, therefore,
an application in classic environments: You must choose an encourage different stakeholders to collaborate in a lively,
operating system and set it up, add application servers, da- multidisciplinary way focussed on the success of the product.
tabase, manage users and permissions, configure a firewall, When teams, put together like this, cultivate a communication
manage compatibilities and dependencies. Having done all culture in the spirit of Agile, without constraints from hierar-
this, the application itself finally needs to be configured and chic structures, iterative development of products guided by
adjusted to any given production environment. (changing) customer needs is being facilitated. An agile infra-
Modern cloud environments such as Amazon Web Services, structure as defined by DevOps can supply a likewise iterative
Microsoft Azure or Google Cloud Platform make this process IT.
substantially easier. Complicated infrastructures from the tra- Cloud platforms help such iterative businesses on a technical
ditional on-premise-world are almost trivial in comparison! level as solely software-based infrastructures; Docker contain-
Data management, user and permissions management (iden- ers are helpful too. Those make deployment and changes to the
tity), networks, management and monitoring, scaling are at infrastructure a no-brainer and could potentially dispose of the
hand as services in such environments. Calling one of those image of IT being the “party pooper” in business development
services takes just seconds to complete. once and for all.

Container Final thoughts

Container technologies, made popular by Docker, solve a In our understanding, modern DevOps will work only when
long-standing problem of the software world in an elegant combined with the techniques presented in this article. The
way: How can you make software running in one system con- topics – Continuous Delivery, Microservices, Clouds, Dock-
text run easily in another system context? er, Business Culture – might be subject to controversial dis-
Containers separate software from factors like operating cussions; certainly there are many important topics to be
system versions, library-conflicts or network topologies, mak- mentioned.
ing the “transfer” of an app from the test environment into Furthermore, not all of the ingredients mentioned above are
production system less “painful” than before. needed to build a “real” DevOps. In fact, I’ve heard of true
What is the difference between Docker or CoreOS (to also Continuous Delivery miracles that are based on one ­single
mention the alternative container platform besides Docker) and mega-monolith (instead of microservices) and of intelligent
traditional virtualization? Classic virtualization systems bundle applications of microservices completely without clouds and
not just the application, but also the corresponding operation container.
system and further components into a package. Therefore, a There is no “true DevOps”, just as there is no one author-
machine needs to run three operating systems in addition to its itative definition of DevOps. Defining DevOps as being the
primary OS when running three virtualization instances. description of a movement that forces us to rethink our basic
Docker and CoreOS virtualize only the application plus se- understanding of IT, should do for now (and, of course, will
lected libraries while using shared access to services from the be discussed at our DevOpsCon, that did not gain the motto
system kernel. This leads to decreased start-up times in com- of “Rethink IT” by chance).
parison to classic VMware instances. With those, start-up I’m looking forward to many sessions, keynotes, and work-
takes up to minutes; with Docker, it takes seconds. Because shops, as well as lots of enthralling impulses and enlightening
of these properties, Docker virtually invites developers to split conversations. All of our speakers are well-versed in DevOps
complex applications into small bites in microservices style. environments, some as infrastructure experts, some as appli-
cation developers in the cloud, others as transformation con-
Business culture sultants for companies.
None of the above will start a revolution in IT on its own.
Taken together they are able to change the tune unequivo- Will I see you at DevOpsCon?
cally.
Continuous Delivery opens up new mental spaces in com-
panies to shape their digital business. In the light of high

www.JAXenter.com | October 2016 28

 Interview

Interview with Daniel Bryant

“Checklist: Why are microser-

vices important for you? –
Part 3”

No software architect can resist the temptation to talk lar, the ability to rapidly change a system without unintended
about their experience with microservices. We asked an ex- consequences. This means that as customer requirements (or
pert to talk about the benefits and challenges of microservices, the market) changes, the software delivery team can quickly
when people should not use them and what impact they have react and adapt the software to meet these new requirements,
on an organization. In this interview Daniel Bryant, Chief and do so without worrying that a small change will create
Scientist at OpenCredo, agreed to talk about his likes and unforeseen issues (or require large amounts of testing to pre-
dislikes about microservices. Here are his answers. vent regression). The properties of a microservice-based sys-
tem that enable this benefit include:
JAX Magazine: Why did you start using microservices?
Daniel Bryant: I first started using an architectural pattern • Understandable and well-defined cohesive services based
that was similar to what we now call microservices on a pro- around a business function (i.e. bounded contexts)
ject in 2011. The reason we chose to use a service-oriented • Well-defined service interfaces (APIs)
approach was due to the early identification of separate areas • The ability to make assertions about functionality
of functionality within the overall requirements. We also had throughout the system stack, at a local and global level
several teams involved in creating the software (spread across (e.g. component tests, contract tests, and end-to-end tests)
the UK and also Europe), and we believed that dividing the
system into well-defined services with clear interfaces would
allow us to more efficiently work together on the project. Portrait
The development of separate services, each with its own
interface, functionality, and responsibilities, meant that once Daniel Bryant is the Chief Scientist at OpenCredo. His current work
the teams understood and designed the overall system-level includes enabling agility within organizations by introducing better
requirements and interactions, we could minimize the need requirement gathering and planning techniques, focusing on the
for constant inter-team communication. Well-defined service relevance of architecture within agile development, and facilitat-
contexts and less communication meant that we delivered ing continuous integration/delivery. Daniel’s current technical
valuable software more quickly than if we had all been work- expertise focuses on “DevOps” tooling, cloud/container platforms
ing (and coordinating) within a single codebase. and microservice implementations. He is also a leader within the
London Java Community (LJC), contributes to several open source
JAXmag: What is the most important benefit of microservices? projects, writes for well-known technical websites such as InfoQ,
Bryant: When a microservice architecture is implemented DZone and Voxxed, and regularly presents at international confer-
correctly, the most important benefit is agility – in particu- ences such as QCon, JavaOne and Devoxx.

www.JAXenter.com | October 2016 29

 Interview

JAXmag: Have microservices helped you achieve your goals? tionality – then the potential impact on an organisation is mas-
Bryant: The use of the microservice architectural style has sive (particularly for a traditional enterprise), as business teams
definitely helped in several projects I have been involved due to will have to re-organise away from horizontally functional silos
the reasons mentioned in the previous answer. I work mostly (e.g. finance, marketing, PMs BAs, developers, QAs) to vertical-
as a consultant, and so am in the privileged position to see lots ly integrated cross-functional teams (e.g. the conversion uptake
of different projects. Although microservices aren’t a panacea team, or the user signup team). Many people have already writ-
(and I haven’t used them in every project), they are a very useful ten about Conway’s Law, and so I won’t cover this here, but
pattern in my “architectural toolbox”, and I have used them I’ve witnessed the results enough time to know that this is a real
to help teams I work with understand fundamental software thing. In fact, it’s worth noting that many of the pioneers in the
development paradigms/qualities like coupling and cohesion. microservice space started developing architectures that we now
recognise as microservices because of business requirements for
JAXmag: What do you think should be the optimal size of a agility, team autonomy and decreased time-to-market.
microservice? Many people have already written about Conway’s Law,
and so I won’t cover this here, but I’ve witnessed the results
Bryant: As a consultant, I like to say “context is vital”, and
enough time to know that this is a real thing. In fact, it’s
so I believe there is no optimal size for a microservice. My rec-
worth noting that many of the pioneers in the microservice
ommendations are to keep services focused around a cohesive
space started developing architectures that we now recognise
business function (e.g. user service, payment service etc), en-
as microservices because of business requirements for agility,
sure that the team can use a ubiquitous language within each
team autonomy and decreased time-to-market. This wasn’t
service (i.e. a concept within a service means only one thing
necessarily a top-down edict to componentize systems like
– for example a “user” within a payment service is simply an
there was with the traditional SOA approach.
identifier for a payer), and make sure that a developer can
readily understand the service context and code after a couple
of hours of investigation.

JAXmag: What is the biggest challenge of microservices? “In my opinion, micro-

Bryant: One of the primary challenges is not getting caught
in the hype. Resist the temptation to build everything as a services are technology
microservice – it is simply an architectural style, and like all
such styles, has strengths and weaknesses. agnostic.”
Another primary challenge includes testing – microservice
systems inherently have more dependencies that must be
managed, and testing the interactions between services can
be challenging. This is why I have been working with the JAXmag: When should you not use microservices?
SpectoLabs team on the development of various tools to sup- Bryant: I get asked this question quite a lot, and it is diffi-
port the testing of microservice-based systems. We have an cult to give a definitive answer. However, situations where
open source “service virtualisation” and API simulation tool microservices may not be beneficial include:
named Hoverfly, which includes a JUnit Rule for use within a
typical Java testing process and CI pipeline.
• Working with a simple application domain
JAXmag: What technology do you think is the most impor- • Developing software with a small number of people in the
tant as far as microservices are concerned? team
Bryant: In my opinion, microservices are technology agnos- • No problem/solution or product/market fit e.g. you are a
tic, and the pattern can be applied with any programming lan- startup that is still exploring your business domain and
guage. Implementing microservices does, however, increase the how to make money
need for a good platform i.e. deployment/runtime fabric, such • When the organisation is not embracing DevOps principles
as Cloud Foundry, Kubernetes or AWS EC2. Although I like (i.e. see Martin Fowler’s MicroservicePrequisites article).
to encourage developers to cultivate “mechanical sympathy”
and understand key properties of the deployment fabric, I also
believe they shouldn’t have to be overly concerned with things JAXmag: What are your guiding principles in the division of
like process scheduling, configuration and service discovery. an application into microservices?
Container technology, such as Docker, rkt and LXD, is also Bryant: Firstly, make sure you understand your domain. I
quite complementary to microservices, and these homogenise am a big fan of Domain-Driven Design, and so readily rec-
the deployment and runtime packages, but I don’t think this ommend the use of Context Mapping in order to fully under-
is essential for microservice development. stand (and model) your application domain. I’m also finding
the technique of Event Storming increasingly useful to help
JAXmag: How much do microservices influence an organisa- build a dynamic (event-driven) picture of the system over and
tion? Can they leave the organisation unchanged? above the static picture provided by Context Mapping. Once
Bryant: If the spirit of the microservice architectural style is you have modelled your domain, I typically find that natural
fully embraced — creating services based around business func- service boundaries emerge.

www.JAXenter.com | October 2016 30

 Interview

Other techniques include the use of code analysis, both • Is the organisation’s leadership well-aligned and are teams
in terms of complexity (e.g. cyclomatic complexity or more capable of working together effectively; is the organisation
crudely, lines of code) and churn (e.g. code change over time, “operationally” healthy – are they embracing “DevOps”
as shown by VCS logs), and the identification of natural fric- principles, and do they have a well-functioning continuous
tion points (e.g. interfaces, potential seams, locations where delivery build pipeline
data is transformed). Adam Tornhill’s book “Your Code as • Are developers/QA being well trained on architectural
a Crime Scene” is an excellent resource here, as is Michael patterns, domain modelling, and technologies;
Feather’s “Working Effectively with Legacy Code”. • Is there a process for feedback and learning e.g. retrospec-
tives, career development programs etc.
JAXmag: Should every microservice be written in the same
language or is it possible to use more languages?
Bryant: I like the idea of polyglotism, both at the language
and data store level, as this embraces my personal philoso-
phy of using the “right tool for the job”. However, context
is again key here, and if an organisation is struggling with
understanding core architectural patterns or using (and oper-
ating) a single language platform, then adding more into the
stack will only cause more trouble.

JAXmag: What aspects should you take into consideration

before using microservices?
Bryant: As a consultant, I like to conduct organisational
“health checks” before embracing any new architectural style
or software development technology. These health checks
would typically cover things like:

• Is the business/organisational strategy well understood i.e.

do the development team know the overall mission and
goals, and also understand why they are doing what they
are doing

Imprint
Publisher
Software & Support Media GmbH Sales Clerk:
Anika Stock
Editorial Office Address +49 (0) 69 630089-22
Software & Support Media [email protected]
Schwedlerstraße 8
60314 Frankfurt, Germany Entire contents copyright © 2016 Software & Support Media GmbH. All rights reserved. No
www.jaxenter.com part of this publication may be reproduced, redistributed, posted online, or reused by any
means in any form, including print, electronic, photocopy, internal network, Web or any other
Editor in Chief: Sebastian Meyen method, without prior written permission of Software & Support Media GmbH.
Editors: Gabriela Motroc, Hartmut Schlosser
Authors: Manuel Bernhardt, Lutz Hühnken, Dr. Roland Kuhn, Jochen Mader,
The views expressed are solely those of the authors and do not reflect the views or position
of their firm, any of their clients, or Publisher. Regarding the information, Publisher disc-
Marius Soutier, Vaughn Vernon
laims all warranties as to the accuracy, completeness, or adequacy of any information, and
Interviews: Daniel Bryant, Markus Hauck, Ivan Kusalic, Martin Odersky, is not responsible for any errors, omissions, in­adequacies, misuse, or the consequences of
Heiko Seeberger, Daniela Sfregola, Julien Tournay, Daniel Westheide using any information provided by Pub­lisher. Rights of disposal of rewarded articles belong
Copy Editor: Nicole Bechtel, Jennifer Diener to Publisher. All mentioned trademarks and service marks are copyrighted by their respective
Creative Director:
Jens Mainz owners.
Layout: Flora Feher

www.JAXenter.com | October 2016 31