State of Akka 2017 - The best is yet to come

Konrad `ktoso` Malawski @ Scala Days CPH 2017
State of Akka @ 2017
The best is yet to come

Konrad `ktoso` Malawski @ Scala Days CPH 2017
Disclaimer:
Parts of this talk is about
under-development “experimental” APIs
which may change slightly.
This is not a strict roadmap,
it is a general outline where we’re headed.

Konrad `ktoso` Malawski
Akka Team,
Reactive Streams TCK,
Scala SLIP Committee member

Konrad `@ktosopl` Malawski
work: akka.io lightbend.com
personal blog: http://kto.so
communities: geecon.org Java.pl / KrakowScala.pl sckrk.com GDGKrakow.pl lambdakrk.pl

The underlying motto of all our development
“Can we do better than that?”

The underlying motto of all our development
“Can we do better than that?”
and sometimes…
“Been there, done that.”

A Journey
From Past,
through Current,
to the Future…!

https://www.lightbend.com/akka-ﬁve-year-anniversary
Past
starting 2009

https://www.lightbend.com/akka-ﬁve-year-anniversary

”The actor model in computer science is a
mathematical model of concurrent
computation that treats actors as the universal
primitives of concurrent computation. ”
Wikipedia
The Actor Model

and acts on them by:
• Sending messages
• Changing its state / behaviour
• Creating more actors
receives messages
An Actor

A concurrency and distribution construct.
an addressable, location-transparent, entity.
An Actor
Actors talk directly to each other.
An ActorSystem is truly peer-to-peer, not client-server.

An Actor
(current 2.x API, not the ancient one :-))

An Actor
Java API “feels native”, Java8 Lambdas, no Scala “leaking”

A simple Actor interaction
Could be different threads
or different nodes in cluster.
API remains the same - and always async.

Why does it matter?
Could be different threads
or different nodes in cluster.
API remains the same - and always async.
http://www.anandtech.com/show/11464/intel-announces-skylakex-bringing-18core-hcc-silicon-to-consumers-for-1999

Actors are never “exposed”, ActorRefs are.

Get “introduced”, interact directly.

Binary > Textual Protocols
“The Internet is running in debug mode.”
— Rüdiger Möller
http://java-is-the-new-c.blogspot.de/2014/10/why-protocols-are-messy-concept.html

MediaContent {
media = Media {
uri = “http://conference.com/key.mpg"
title = "Keynote"
width = 640
height = 480
format = "video/mpg4"
duration = 18000000
size = 58982400
bitrate = 262144
persons = ["Bill Gates", "Steve Jobs"]
player = JAVA
copyright = null
}
}
images = [
Image {
uri = “http://conference.com/key_large.jpg"
title = "Keynote"
width = 1024
height = 768
size = LARGE
}
Image {
uri = “http://conference.com/key_small.jpg"
title = "Keynote"
width = 320
height = 240
size = SMALL
}
]
Not only JSON: Example data

create ser deser total size
protostuff 68 433 634 1067ns 239bytes
protobuf 121 1173 719 1891 239
kryo-serializer 53 1480 1331 2810 286
thrift 95 1455 731 2186 349
. . .
json/jackson/manual 52 1039 1228 2267 468
json/jackson/databind 54 1164 1866 3030 485
json/gson/databind 56 4667 4403 9070 486
xml/xstream+c-aalto 54 3310 6732 10042 525
xml/JAXB 54 4354 141333 145686 719
java-built-in 53 5046 23279 28325 889
Why Binary?
Slide only to illustrate order-of-magniture diﬀerences. Don’t over-focus on numbers.
All details here: https://github.com/eishay/jvm-serializers/wiki

Avoid Java Serialization
----sr--model.Order----h#-----J--idL--customert--Lmodel/Customer;L--descriptiont--Ljava/lang/String;L--
orderLinest--Ljava/util/List;L--totalCostt--Ljava/math/BigDecimal;xp--------ppsr--java.util.ArrayListx-----
a----I--sizexp----w-----sr--model.OrderLine--&-1-S----I--lineNumberL--costq-~--L--descriptionq-~--L--ordert--
Lmodel/Order;xp----sr--java.math.BigDecimalT--W--(O---I--scaleL--intValt--Ljava/math/BigInteger;xr--
java.lang.Number-----------xp----sr--java.math.BigInteger-----;-----I--bitCountI--bitLengthI--
firstNonzeroByteNumI--lowestSetBitI--signum[--magnitudet--[Bxq-~----------------------ur--[B------T----xp----
xxpq-~--xq-~--
Java Serialization
final case class Order(id: Long, description: String, totalCost: BigDecimal,
orderLines: ArrayList[OrderLines], customer: Customer)
<order id="0" totalCost="0"><orderLines lineNumber="1" cost="0"><order>0</order></orderLines></order>XML…!
{"order":{"id":0,"totalCost":0,"orderLines":[{"lineNumber":1,"cost":0,"order":0}]}}JSON…!
------java-util-ArrayLis-----model-OrderLin----java-math-BigDecima---------model-Orde-----Kryo…!
Excellent post by James Sutherland @
http://java-persistence-performance.blogspot.com/2013/08/optimizing-java-serialization-java-vs.html

Akka uses ProtocolBuffers
for (most*) it’s messages by default.
To completely disable Java Serialization do:
akka.actor.allow-java-serialization = false
(which switches Akka to protobuf completely)
User messages you deﬁne your own serializers.
most* – due to wire compatibility some messages, where
some messages did use JavSer in the past

Good serializers include (but are not limited to):
Kryo, Google Protocol Buffers, SBE,Thrift, JSON if you really want
// dependencies
"com.github.romix.akka" %% "akka-kryo-serialization" % "0.4.0"
// application.conf
extensions = [“com.romix.akka.serialization.kryo.KryoSerializationExtension$"]
 
serializers {  
java = "akka.serialization.JavaSerializer"
kryo = "com.romix.akka.serialization.kryo.KryoSerializer"  
}
akka.actor.serialization-bindings {
“com.mycompany.Example”: kryo
. . .
}
[info] ForkJoinActorBenchmark.pingPong java avgt 10 25.464 ± 1.175 us/op
[info] ForkJoinActorBenchmark.pingPong kryo avgt 10 4.348 ± 4.346 us/op
[info] ForkJoinActorBenchmark.pingPong off avgt 10 0.967 ± 0.657 us/op

Sidenote:
Akka + Binary Compatibility?

Our binary compatibility story
http://doc.akka.io/docs/akka/current/scala/common/binary-compatibility-rules.html

2.3.1x [2015-09] ->
2.4.x [2015-08] ->
2.5.x [2017-04] -> ...
2.7.x [???] ->
2.8.x [???] ->
3.x [far out still, no need to break APIs]

Binary compatibility != Wire compatibility
/* but we’ll get to that! (hint: Artery) */

History of Futures
In Days before Futures got standardised in Scala (~2012).
Their design was heavily influenced by: Akka, Finagle & Scalaz & more…
Archival version @ 2012
http://doc.akka.io/docs/akka/2.0/scala/futures.html
SIP-14 - Futures and Promises
By: Philipp Haller, Aleksandar Prokopec, Heather Miller, Viktor Klang, Roland Kuhn, and Vojin Jovanovic

http://docs.scala-lang.org/sips/completed/futures-promises.html

“Best practices are solutions
to yesterdays problems.”
https://twitter.com/FrankBuytendijk/status/795555578592555008
Circuit breaking as substitute of flow-control

See also, Nitesh Kant, Netflix @ Reactive Summit
https://www.youtube.com/watch?v=5FE6xnH5Lak

HTTP/1.1 503 Service Unavailable
Throttling as represented by 503 responses. Client will back-off… but how?
What if most of the ﬂeet is throttling?

http://doc.akka.io/docs/akka/2.4/common/circuitbreaker.html

“slamming the breaks”

We’ll re-visit this speciﬁc case in a bit :-)
“slamming the breaks”

Are absolutely useful!
Still… “Can do better than that?”
Circuit Breakers

This will lead to the creation
of Akka Streams and Reactive Streams!
We can do better.

The heart of Distributed Systems,
built using Akka.
Akka Cluster

Akka cluster provides membership
and fault-tolerance for distributed Actors.
- Membership is implemented as epidemic gossip.
- No single point of failure, “Leader” can move to  
any of the nodes (deterministically)
- Battle hardened since many years
- Known to scale to 2400 nodes.
Akka Cluster
https://cloudplatform.googleblog.com/2014/01/large-akka-cluster-on-google-compute.html

Failure detection using simple heartbeats
often not good enough for production. You can:
- Use Akka Split Brain Resolver (commercial),  
multiple split brain scenario resolution strategies
- “Keep majority”, “Keep oldest”, “Static Quorum”
- Perform manual downing  
(a safe bet, good if OPS or automated via Nagios etc)
- Roll your own, all required APIs are public
Failure detection is pluggable
https://cloudplatform.googleblog.com/2014/01/large-akka-cluster-on-google-compute.html

bit.ly/why-reactive
How to think about these techniques?

Back then known as “Spray”,
we joined up and started working
on a streaming-first HTTP server.
Akka HTTP

- Fully Typed HTTP model
- So good, other projects use it instead of rolling their own!
(http4s uses Spray’s model.) 
- Streaming-focused HTTP server
- Built from the ground up on Akka Streams
- Full Java API (unlike Spray)
- Streaming with WebSockets!
Key features of Akka HTTP

Streaming in Akka HTTP
http://doc.akka.io/docs/akka/2.4/scala/stream/stream-customize.html#graphstage-scala
“Framed entity streaming”
http://doc.akka.io/docs/akka/2.4/java/http/routing-dsl/source-streaming-support.html
HttpServer as a:
Flow[HttpRequest, HttpResponse]

HttpServer as a:
HTTP Entity as a:
Source[ByteString, _]

HttpServer as a:
HTTP Entity as a:
Source[ByteString, _]
Websocket connection as a:
Flow[ws.Message, ws.Message]

High level Routing API:

Low-level API (e.g. what Play uses):

Akka Persistence
EventSourcing your Actors

Event sourcing your Actors
Receive commands.
Store events.
Optional: Create queries / views

Present & near Future
2016~2017+

Distributed Data
Conflict-Free Data-Types

CAP theorem reminder
Akka Persistence Akka DData

CAP theorem reminder
Akka DDataAkka Persistence

Using Distributed Data
The focus is on “spreading the data”,
not on the “single entity” like it is in Persistence.

Distributed Data visualised
You supply a write consistency level which has the following meaning:
• WriteLocal the value will immediately only be written to the local replica, and
later disseminated with gossip
• WriteTo(n) the value will immediately be written to at least n replicas, including
the local replica
• WriteMajority the value will immediately be written to a majority of replicas, i.e.
at least N/2 + 1 replicas, where N is the number of nodes in the cluster (or cluster
role group)
• WriteAll the value will immediately be written to all nodes in the cluster (or all
nodes in the cluster role group)

Summary of CRDTs
• Counters: GCounter, PNCounter
• Sets: GSet, ORSet
• Maps: ORMap, ORMultiMap, LWWMap, PNCounterMap
• Registers: LWWRegister, Flag

Suddenly everyone jumped on the word “Stream”.
Akka Streams / Reactive Streams started end-of-2013.
“Streams”
* when put in “” the word does not appear in project name, but is present in examples / style of APIs / wording.

Suddenly everyone jumped on the word “Stream”.
Akka Streams / Reactive Streams started end-of-2013.
The word “Stream” is used in many contexts/meanings
Akka Streams
Reactive Streams
RxJava “streams”*
Spark Streaming
Apache Storm “streams”*
Java Steams (JDK8)
Reactor “streams”*
Kafka Streams
ztellman / Manifold (Clojure)
* when put in “” the word does not appear in project name, but is present in examples / style of APIs / wording.
Apache GearPump “streams”
Apache [I] Streams (!)
Apache [I] Beam “streams”
Apache [I] Quarks “streams”
Apache [I] Airﬂow “streams” (dead?)
Apache [I] Samza
Scala Stream
Scalaz Streams, now known as FS2
Swave.io
Java InputStream / OutputStream / … :-)
2017年: 安定版。リアクティブストリーム付きの JDK9。

“Stream”
What does it mean?!
• Possibly inﬁnite datasets (“streams”)
• “Streams are NOT collections.”
• Processed element-by-element
• Element could mean “byte”
• More usefully though it means a speciﬁc type “T”
• Asynchronous processing
• Asynchronous boundaries (between threads)
• Network boundaries (between machines)
2017年: 安定版。リアクティブストリーム付きの JDK9。

Where does Akka Stream fit?
Akka Streams specifically fits,
if you answer yes to any of these:
• Should it take on public traffic?
• Processing in hot path for requests?
• Integrate various technologies?
• Protect services from over-load?
• Introspection, debugging, excellent Akka integration?
• (vs. other reactive-stream impls.)

How do I pick which “streaming” I need?
Kafka serves best as a transport
for pub-sub across services.
• Note that Kafka Streams (db ops are on the node
is rather, different than the Reactive Kafka client
• Great for cross-service communication  
instead of HTTP Request / Reply
Kafka はサービス間の pub-sub 通信に向いている

HTTP の代わりにサービス間の通信に使う

How do I pick which “streaming” I need?
Spark has vast libraries for ML or join etc ops.
• It’s the “hadoop replacement”.
• Spark Streaming is windowed-batches
• Latency anywhere up from 0.5~1second
• Great for cross-service communication  
instead of HTTP Req/Reply
Spark は機械学習系が充実している

Oh yeah, there’s JDK8 “Stream” too!
Terrible naming decision IMHO, since Java’s .stream()
• Geared for collections
• Best for ﬁnite and known-up-front data
• Lazy, sync/async (async rarely used)
• Very (!) hard to extend
It’s the opposite what we talk about in Streaming
systems!
It’s more:“bulk collection operations”
Also known as… Scala collections API (i.e. Iterator
JDK8 の Stream はイテレータ的なもの

What about JDK9 “Flow”?
JDK9 introduces java.util.concurrent.Flow
• Is a 1:1 copy of the Reactive Streams interfaces
• On purpose, for people to be able to impl. it
• Does not provide useful implementations
• Is only the inter-op interfaces
• Libraries like Akka Streams implement RS, 
and expose useful APIs for you to use.
JDK9 の Flow はリアクティブ・ストリーム

A fundamental building block.
Not end-user API by itself.
reactive-streams.org
Reactive Streams

Reactive Streams
More of an SPI (Service Provider Interface),
than API.
reactive-streams.org

The specification.
Reactive Streams
Origins of

Reactive Streams - story: 2013’s impls
2014–2015:
Reactive Streams Spec & TCK
development, and implementations.
1.0 released on April 28th 2015,
with 5+ accompanying implementations.
2015
Included in JDK9 via JEP-266 “More Concurrency Updates”
download.java.net/java/jdk9/docs/api/java/util/concurrent/Flow.html

But what does it do!?
Reactive Streams

Fast Publisher[T] Slow Subscriber[T]
Push model

Subscriber usually has some kind of buffer.
Push model

What if the buffer overﬂows?
Push model

Kernel does this!
Routers do this!
(TCP)
Use bounded buffer,
drop messages + require re-sending
Push model

Reactive Streams explained
Reactive Streams
explained in 1 slide

Fast Publisher will send at-most 3
elements. This is pull-based-
backpressure.
Reactive Streams: “dynamic push/pull”

JEP-266 – soon…!
public final class Flow {
private Flow() {} // uninstantiable
@FunctionalInterface
public static interface Publisher<T> {
public void subscribe(Subscriber<? super T> subscriber);
}
public static interface Subscriber<T> {
public void onSubscribe(Subscription subscription);
public void onNext(T item);
public void onError(Throwable throwable);
public void onComplete();
}
public static interface Subscription {
public void request(long n);
public void cancel();
}
public static interface Processor<T,R> extends Subscriber<T>, Publisher<R> {
}
}

Reactive Streams: goals
1) Avoiding unbounded buffering across async boundaries
2) Inter-op interfaces between various libraries

Argh, implementing a correct
RS Publisher or Subscriber is so hard!

Argh, implementing a correct RS Publisher
or Subscriber is so hard!

Argh, implementing a correct
RS Publisher or Subscriber is so hard!
You should be using
Akka Streams instead!

Akka Streams in 20 seconds:
val firstString: Future[String] = 
Source.single(1) 
.map(_.toString()) 
.runWith(Sink.head)

Source.single(1).map(i => i.toString).runWith(Sink.head())
// types: _
Source[Int, NotUsed]
Flow[Int, String, NotUsed]
Sink[String, Future[String]]

// types: _
Source[Int, NotUsed]
Flow[Int, String, NotUsed]
Sink[String, Future[String]]
Source.single(1).map(i => i.toString).runWith(Sink.head())

natively in Akka HTTP/2
HTTP/2

HTTP/2
1.9M May 15 08:02 bigimage.jpg
995K May 15 08:16 bigimage2.jpg

HTTP/2
HTTP(S)/1.1
HTTP/2
(before performance optimisations (sic))

Play + Akka HTTP => HTTP/2
+ TLS conﬁguration
https://github.com/playframework/play-scala-tls-example/pull/30
http/2HTTP+ =

Akka HTTP as default backend for Play
Goal is not to “beat Netty*”
but to keep perf
while adding features.
Future:
- Shared Typed HTTP Model
- Shared Monitoring
- Shared performance work
TL;DR; == Shared efforts
* We <3 Netty.
http://playframework.github.io/prune/
Ofc: Netty backend remains available.

The journey to Akka Typed
Ancient API, deprecated“Typed Actor” API
Goal was to expose what Java developers knew.

Old “TypedActor” experimental in 2.3, removed
Upsides:
- Easily bridge to “non-Akka” / “non-Reactive” apps
- type-safe
- “easy” (not necessarily a good thing)
Downsides:
- Reﬂection, 10x slow-down compared to UntypedActor
- “RPC”-ish, not true to the core messaging
- Not true to Akka’s core principle: Messaging

“Typed Channels” experimental in 2.3, removed

“Typed Channels” experimental in 2.3, removed
Upsides:
- completely type-safe
- very expressive
Downsides:
- Too complex, many new operators
- Had to rely on scala macros
- “sender” difﬁcult to solve

http://axel22.github.io/resources/docs/reactors.pdf

Akka Typed
try it now, 2.5.2
from repo.akka.io/snapshots
2 styles, 100% awesome.
Full Java & Scala API, as usual.
Actor.mutable – similar to current Actors, Behavior is a class
Actor.immutable – more functional style, recommended

Akka Typed
Main user-facing changes:
ActorRef[T] typed ActorRefs.
Core concept is Behavior[T]
which can be freely composed.
You always “become(Behavior)”, by returning Behavior.
sender() is gone,
not possible to type it well.
sender was trouble anyway, so that’s good!

Akka Typed
Untyped
=>
Actor.mutable

Akka Typed
Actor.immutable (Scala)

Akka Typed
Don’t worry, Java will eventually get pattern matching:
http://mail.openjdk.java.net/pipermail/amber-spec-experts/2017-April/000033.html
Java adopting Scala features conﬁrms Scala’s design.
…but, until then we provide you with helpers and DSLs:

Akka Typed
Actor.immutable (Java)

Akka Typed
try it now, 2.5.99-TYPED-M1
from repo.akka.io/snapshots
Learn more:
from the docs:
http://doc.akka.io/docs/akka/snapshot/scala/typed.html
and the blog:
1. Akka Typed: Hello World in the new API
2. Akka Typed: Coexistence
3. Akka Typed: Mutable vs. Immutable
4. Akka Typed: Protocols
5. Akka Typed: Supervision
6. Akka Typed: Lifecycle and Watch
7. Akka Typed: Timers

A community for Streams connectors
Alpakka – a community for Stream connectors
Alp

Alpakka – a community for Stream connectors
http://developer.lightbend.com/docs/alpakka/current/

Ecosystem that solves problems
> (is greater than)
solving all the problems ourselves

Way more than just “we changed the transport.”
New Remoting:
Artery

Artery
Next generation remoting layer for Akka.
• Aeron (UDP) based instead of TCP,
• Advanced automatic ActorRef Compression
• Dedicated “lanes” for certain messages / destinations
• Almost alloc-free in steady-state (except deserialization)

Remoting feature matrix
Remoting “classic” Artery Remoting
Protocol
TCP
TLS+TCP
UDP
(Aeron)
Large messages Troublesome Dedicated lanes
Heartbeat and
System Messages
Prioritised Dedicated lanes
Benchmarked*
throughput
70k msg/s
700k+ msg/s
(up to 1m msg/s)
* benchmark setup: 5-to-5 actors, 100byte payload message
(excluding envelope size),Amazon EC2 M4-X2Large instances

How to use Artery?
single option,
no new artifacts

“Steady state” operation almost alloc-free
Serialize Deserialize
compression compression
package readpackage write
AkkaStreams
(allocationfree)
Pooled envelopes
Pooled ByteBuffers
Deserialize allocates
Pooled ByteBuffers
no allocations
Caches for ActorRefs etc
no allocations in steady state

Artery: ActorRef Compression
Compression triggered for “heavy hitters”,
so “most chatty” Actors to maximise beneﬁt.
Triggers automatically & transparently.

Artery: ActorRef / Manifest Compression

Artery: ActorRef / Manifest Compression
In this case ActorRef compression reduced the size of a small
envelope size by 74% - from 162 to 42 bytes (sic!).

Multi Data Center
Customers increasingly have global-scale apps,
so we’re looking into advanced Multi-DataCenter scenarios.

Multi Data Center
These are just ideas.
Talk to me, we’re gathering use cases.
- Active + Active ???
- Locality aware Cluster Sharding ???
- Entity “owner” Datacenter ???
- Talk to us about your use cases :)
- …?

Wait, there’s more!
(things I couldn’t fit on the map)

New docs engine
New QuickStart, ScalaFiddle…

Lightbend Paradox - docs engine
We know, we know:“Yet another docs engine”
Built-in scala-ﬁddle support
Akka.js => run Akka docs examples in browser

Lightbend Paradox - docs engine
Much much easier to contribute now.
Zero dependencies just type “paradox”
Markdown instead of restructured text!
Built in capabilities to link github / scaladoc
Simple way to build multi-prog-lang docs @scala/@java

Lightbend “kickstart”
Replacing Activator

Tracing & Monitoring
distributed systems

Monitoring Akka
developer.lightbend.com/docs/monitoring/latest/home.html
+
DataDog || StatsD || Graphite || …anything!

Monitoring Akka
e.g.
DataDog || StatsD || Graphite || …anything!

Monitoring Akka
Remember where Artery Compression kicks in?
(“Top senders” / “Top receivers”)

Tracing Akka with Jaeger or Zipkin
Uber Jaeger
Twitter Zipkin

Tracing Akka with Jaeger or Zipkin
Lightbend Monitoring
https://developer.lightbend.com/docs/cinnamon/latest/extensions/opentracing.html

Tracing across nodes
Lightbend Monitoring
https://developer.lightbend.com/docs/cinnamon/latest/extensions/opentracing.html
Already tracing across network transparently,
Akka HTTP coming soon, as will Futures.

Monitoring Akka
“What is failing in the system?”
Lightbend OpsClarity

Ports to other platforms
Not supported by Lightbend, community projects.
http://getakka.net/ http://akka-js.org/
A sign that Akka is interesting and worth porting:

Open Source projects using Akka
index.scala-lang.org

Summing up
With all the foundational building blocks prepared…
“The best is yet to come.”

Thanks everyone
Committers from the Community!
Jan Pustelnik
Krzysiek Ciesielski,
Alexey Romanchuk,
Heiko Seeberger,
Josep Prat,
Jan Ypma,
André Rüdiger,
Jonas Fonseca
…
and hundreds of contributors
Thanks!

We <3 contributions
•Easy to contribute:
• https://github.com/akka/akka/issues?q=is%3Aissue+is%3Aopen+label%3Aeasy-to-contribute
• https://github.com/akka/akka/issues?q=is%3Aissue+is%3Aopen+label%3A%22nice-to-have+%28low-prio%29%22
•Akka: akka.io && github.com/akka
•Reactive Streams: reactive-streams.org
•Reactive Socket: reactivesocket.io
• Mailing list:
• https://groups.google.com/group/akka-user
•Public chat rooms:
•http://gitter.im/akka/dev developing Akka
• http://gitter.im/akka/akka using Akka

Free e-book and printed report.
bit.ly/why-reactive
Covers what reactive actually is.
Implementing in existing architectures.
Thoughts from the team that’s building
reactive apps since more than 6 years.
Obligatory “read my book!” slide :-)

Metal Gear Solid illustrations
by Lap Pun Cheung
http://www.lpcheung.com/metal-gear-solid/
Hand drawn illustrations:
by myself, CC-BY-NC
Artwork links

Thanks!
Questions?
ktoso @ lightbend.com
twitter: ktosopl
github: ktoso
team blog: blog.akka.io
home: akka.io
myself: kto.so

State of Akka 2017 - The best is yet to come

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a State of Akka 2017 - The best is yet to come

Similar a State of Akka 2017 - The best is yet to come (20)

Más de Konrad Malawski

Más de Konrad Malawski (11)

Último

Último (20)

State of Akka 2017 - The best is yet to come