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

http://akka.io

http://lightbend.com

http://kto.so

http://geecon.org

http://java.pl

http://krakowscala.pl

http://sckrk.com

http://gdgkrakow.pl

http://www.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 JourneyFrom Past, through Current, to the Future…!

https://www.lightbend.com/akka-five-year-anniversary

Paststarting 2009


”The actor model in computer science is a m a t h e m a t i c a l m o d e l o f c o n c u r r e n t computation that treats actors as the universal primitives of concurrent computation. ”

Wikipedia

The Actor Model

https://en.wikipedia.org/wiki/Computer_science

https://en.wikipedia.org/wiki/Mathematical_model

https://en.wikipedia.org/wiki/Concurrent_computation

https://en.wikipedia.org/wiki/Concurrent_computation

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 threadsor different nodes in cluster.

API remains the same - and always async.

Why does it matter?

Could be different threadsor 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

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

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 differences. Don’t over-focus on numbers.

All details here: https://github.com/eishay/jvm-serializers/wiki

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

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 define your own serializers.

most* – due to wire compatibility some messages, wheresome 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.confextensions = [“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

http://doc.akka.io/docs/akka/2.0/scala/futures.html

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

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 fleet is throttling?

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





“slamming the breaks”



We’ll re-visit this specific 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


Cluster Sharding

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



bit.ly/why-reactive

How to think about these techniques?

http://bit.ly/why-reactive

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]

http://doc.akka.io/docs/akka/2.4/scala/stream/stream-customize.html#graphstage-scala




HTTP Entity as a: Source[ByteString, _]







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

Event sourcing your Actors

Present & near Future2016~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)

CRDTs spread using Gossip

Summary of CRDTs

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

“Stream”

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] Airflow “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 infinite datasets (“streams”)

• “Streams are NOT collections.”

• Processed element-by-element• Element could mean “byte” • More usefully though it means a specific 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 finite 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

http://reactive-streams.org

Reactive StreamsMore 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 & TCKdevelopment, and implementations.

1.0 released on April 28th 2015,with 5+ accompanying implementations.

2015Included in JDK9 via JEP-266 “More Concurrency Updates”

download.java.net/java/jdk9/docs/api/java/util/concurrent/Flow.html

http://openjdk.java.net/jeps/266

http://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 overflows?

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

Reactive Streams: goals1) Avoiding unbounded buffering across async boundaries


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

HTTPS - the usual waterfall

HTTP/2

HTTP/2

HTTP(S)/1.1

HTTP/2

(before performance optimisations (sic))

Play + Akka HTTP => HTTP/2

+ TLS configuration

https://github.com/playframework/play-scala-tls-example/pull/30

http/2HTTP+ =

https://github.com/playframework/play-scala-tls-example/pull/30

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.

http://playframework.github.io/prune/

Sub-journey to Akka Typed

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:- Reflection, 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” difficult to solve


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

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

Akka Typed

try it now, 2.5.2from repo.akka.io/snapshots

2 styles, 100% awesome.Full Java & Scala API, as usual.

Actor.mutable – similar to current Actors, Behavior is a classActor.immutable – more functional style, recommended

http://repo.akka.io/snapshots

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

Untyped

Akka Typed

Actor.immutable

Akka TypedActor.immutable (Scala)


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 confirms Scala’s design.

…but, until then we provide you with helpers and DSLs:

http://mail.openjdk.java.net/pipermail/amber-spec-experts/2017-April/000033.html


Actor.immutable (Java)

Akka Typed

try it now, 2.5.99-TYPED-M1from 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

http://repo.akka.io/snapshots

http://doc.akka.io/docs/akka/snapshot/scala/typed.html

http://blog.akka.io/typed/2017/05/05/typed-intro

http://blog.akka.io/typed/2017/05/06/typed-coexistence

http://blog.akka.io/typed/2017/05/08/typed-mutable-vs-immutable

http://blog.akka.io/typed/2017/05/12/typed-protocols

http://akka.io/blog/2017/05/16/supervision

http://akka.io/blog/2017/05/19/signals

http://akka.io/blog/2017/05/26/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/

Akka Streams core principles:

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

Akk

a St

ream

s(a

lloca

tion

free

)

Pooled envelopes

Pooled ByteBuffersDeserialize allocates

Pooled ByteBuffersno allocations

Caches for ActorRefs etcno allocations in steady state

Artery: ActorRef Compression

Compression triggered for “heavy hitters”,so “most chatty” Actors to maximise benefit.

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 CenterCustomers 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-fiddle 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

developer.lightbend.com

http://developer.lightbend.com

Tracing & Monitoring distributed systems

Monitoring Akka

developer.lightbend.com/docs/monitoring/latest/home.html+

DataDog || StatsD || Graphite || …anything!

http://developer.lightbend.com/docs/monitoring/latest/home.html

Monitoring Akka

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

Monitoring AkkaRemember where Artery Compression kicks in?

(“Top senders” / “Top receivers”)

Tracing Akka with Jaeger or ZipkinUber Jaeger

Twitter Zipkin

Tracing Akka with Jaeger or Zipkin

Lightbend Monitoringhttps://developer.lightbend.com/docs/cinnamon/latest/extensions/opentracing.html

https://developer.lightbend.com/docs/cinnamon/latest/extensions/opentracing.html

Tracing across nodes

Lightbend Monitoringhttps://developer.lightbend.com/docs/cinnamon/latest/extensions/opentracing.html

Already tracing across network transparently,Akka HTTP coming soon, as will Futures.

https://developer.lightbend.com/docs/cinnamon/latest/extensions/opentracing.html

Monitoring Akka

“What is failing in the system?”Lightbend OpsClarity

External initiatives

IntelliJ support for Akka!

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:

http://getakka.net/

http://akka-js.org/

Open Source projects using Akkaindex.scala-lang.org

http://index.scala-lang.org

Summing up…

Summing up

With all the foundational building blocks prepared…

“The best is yet to come.”

Happy hAkking!

Thanks everyone

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

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

http://akka.io

http://github.com/akka


http://reactivesocket.io

https://groups.google.com/group/akka-user

http://gitter.im/akka/dev

http://gitter.im/akka/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 buildingreactive apps since more than 6 years.

Obligatory “read my book!” slide :-)

http://bit.ly/why-reactive

Metal Gear Solid illustrationsby Lap Pun Cheung

http://www.lpcheung.com/metal-gear-solid/

Hand drawn illustrations:by myself, CC-BY-NC

Artwork links

http://www.lpcheung.com/metal-gear-solid/

Thanks! Questions?

ktoso @ lightbend.comtwitter: ktosopl

github: ktosoteam blog: blog.akka.io

home: akka.iomyself: kto.so

http://twitter.com/ktosopl

http://github.com/ktoso

http://blog.akka.io

http://akka.io

http://kto.so

state of akka 2017 - the best is yet to come

Technology