[HN Gopher] On the future of Akka and Lightbend
___________________________________________________________________
On the future of Akka and Lightbend
Author : yiksanchan
Score : 64 points
Date : 2021-11-05 06:26 UTC (2 days ago)
(HTM) web link (discuss.lightbend.com)
(TXT) w3m dump (discuss.lightbend.com)
| nekitamo wrote:
| It's a shame that the Play framework is being abandoned. v1 had a
| lot of great ideas, but v2 kind of jumped off the cliff into
| Scala lala-land, where it got lost in the weeds. It never really
| recovered.
|
| If you're looking for a straightforward Java framework similar to
| Play v1 check out Ninja:
|
| https://www.ninjaframework.org/
|
| For me at least, it hits a sweet spot of enabling fast productive
| development and maintainable code.
| eropple wrote:
| I really enjoyed Play V1. I got some stuff done with V2, but
| (and I say this as somebody who really liked Scala at the time)
| I think it absolutely disappeared into the morass and never
| came back.
|
| Ninja is pretty cool. It works well with Kotlin, which is what
| I reach for today with the JVM, but tbh the easy path today is
| pretty much Spring Boot so I have some trouble rationalizing
| using anything else.
| mwcampbell wrote:
| > tbh the easy path today is pretty much Spring Boot so I
| have some trouble rationalizing using anything else.
|
| My main reservation with Spring is the heavy dependence on
| runtime reflection. I'd like to see a Java web framework
| designed for conventional server-rendered web applications
| (as opposed to API backends), with authentication, CSRF
| protection, form validation, and so forth, but without heavy
| use of runtime reflection for wiring up objects.
|
| Edit: Also, especially given that Project Loom is on its way,
| I think a blocking API like Ninja or Spring MVC is best.
| debarshri wrote:
| I'm not sure if you have heard about java spark [1]. Back
| in the day, around 2-3 years ago we used to implemented all
| our java service in java spark.
|
| [1] https://sparkjava.com
| vips7L wrote:
| Quarkus does all of its wiring at compile time.
| AheadOfTime295 wrote:
| The recent focus on Akka is in line with Lightbend securing a
| 25MM funding round last year, and the ensuing layoffs of Scala
| engineers https://news.ycombinator.com/item?id=22842166
| zz865 wrote:
| Biggest problem I had with Akka was that it was that it worked
| better with Scala than Java. As Java recently has re-taken most
| of Scala's momentum its a bit awkward fit.
| vips7L wrote:
| Same story with Lightbends Play Framework. Using it from Java
| is abysmal.
| KptMarchewa wrote:
| Using anything build in Scala from Java is abysmal. Have fun
| with no default parameters, creating Seq$.MODULE$ everywhere
| etc. I'm not from US, so I've never have seen so much dollars
| anywhere.
| hardlianotion wrote:
| I agree, it is a mess.
|
| I had a little success by simplifying the interop layer. If
| you can wrap your scala code in simple classes that expose
| only Java-compatible structure, then you can remove
| additional complexity of java into scala interop.
| nodejs_rulez_1 wrote:
| Same story with .NET - less and less reasons for F# to exist
| with each new version of C#. Only F# doesn't even bring any new
| useful frameworks to the table.
| bostonsre wrote:
| Has anyone had great success with akka? It seems like it could
| definitely solve some problems elegantly. My team has had trouble
| with maintainability due to complexity (not clear if that's
| inherent in akka or just with how we implemented it). It can be
| somewhat managed by senior engineers but has seemed to be
| difficult for junior engineers to effectively maintain akka code.
| amdelamar wrote:
| My team had migrated about 35 codebases from a mix of Play,
| Scalatra, Ruby, and Python, to Akka HTTP. The unification
| definitely made it easier for juniors to start work on
| unfamiliar codebases, but the same could be said if we unified
| on something else. That being said, a portion of the services
| did make use of Akka streams & actors and we've found a lot of
| success there that otherwise would've been complex code with
| locks or synchronized blocks. Stuff that I'd rather not have to
| onboard engineers with or review their PRs and miss an
| unlock(). It's probably a steeper learning curve by teaching
| them about actors and futures, but it means they'll be writing
| safer code by design, and reviewing their PRs becomes easier
| for me.
|
| Just make sure the actors are small and have one focus. When
| they get too large and do too much is when they become unwieldy
| and difficult to maintain.
| AnotherGoodName wrote:
| No. In fact the Play Framework 1.x (before it went to Akka) was
| simple perfection. Like Ruby on Rails but with so many
| improvements. Super simple but fast, performant and not really
| lacking anything a web framework needs (coordinating background
| periodic jobs between servers required setting a config file
| but it wasn't a big deal).
|
| In play framework 1 a new API method could be the following
|
| >@Check("administrator") // Authentication scopes allowed for
| this method
|
| >public static String returnHeading(int id) {
|
| > return createQuery("select heading from Article where id=%",
| id).getResult();
|
| >}
|
| See how little boilerplate i have? A junior dev can work with
| this without shooting their own foot. I used to have clients
| come into the office and ask for a new API method and I'd type
| out the API in Play Framework 1.x, type the tests (the
| framework had a great foundation for unit and integration
| tests) check that the SQL was sane and deploy in half a day.
| There's nothing more i want. It scaled well horizontally too.
| You just had haproxy/nginx in front of multiple servers.
|
| Now you might say "But what if you had a web request that took
| days and needed all cores on all servers to communicate with
| each other as they concurrently worked on this mammoth task" to
| which I'd say shut the fuck up.
|
| Play Framework 2.x is when the Play framework adopted Akka. I'm
| going to be mean and takes Lightbends hello world using Akka as
| a taste for those unaware of what this beast is:
| https://youtu.be/rIFqJxMJ1MM?t=428
|
| I'm just going to copy paste some stuff from the Akka wiki to
| rub it in.
|
| Akka supports multiple programming models for concurrency, but
| it emphasizes actor-based concurrency and the eventsourced
| library provides event-driven architecture (see also domain-
| driven design) support for Akka actors. Akka has a modular
| structure, with a core module providing actors. Other modules
| are available to add features such as network distribution of
| actors, cluster support, Command and Event Sourcing,
| integration with various third-party systems (e.g. Apache
| Camel, ZeroMQ), and even support for other concurrency models
| such as Futures and Agents blah blah blah blah blah.
|
| Sorry I'm being rude but surely even the people making Akka can
| see the issues? There might be a use case for Akka. But a
| webserver for a startup is not a use case. Play Framework was
| built as a web framework and Play Framework 2.x seemed to focus
| in on a limitation that practically no one would encounter and
| make everything about that one use case. Play Framework 2.x
| overcomplicated the entire stack and gave no benefit. There's a
| reason Play Framework 1.x is being maintained and patched
| still. The complication from 2.x and Akka is not worth it at
| all.
| angelzen wrote:
| Not familiar with Akka of Play2, but you articulated the
| point of overcomplicating the task of returning a simple
| response to a simple request via a litany of rarely useful
| concepts quite clearly.
|
| OTOH, I wish popular web frameworks had a clearly documented
| 'no magic' option that doesn't critically depend on global
| methods and decorators. Again, not familiar with Play1 other
| than your example, but I recently did spent too much time
| wrangling a moderate backend build on with python/flask as a
| beginner going through the learning curve. After the first 5
| minutes of 'look ma, I have a running server', the
| overreliance of globals became an unpleasant annoyance
| impeding test writing, with surprises abounding.
| edejong wrote:
| In the past I have designed, implemented and brought into
| production many Akka based systems with medior and senior
| teams. Most of these were akka-streams based.
|
| The Akka actor model requires a different mode of thinking
| which can cause problems for experienced engineers. Ideas such
| as 'let it crash' and at-most-once-delivery are not trivial.
| Basically systems design based on resilience instead of
| robustness.
|
| When Actor based systems are well designed, they can be
| extremely powerful, scalable, resilient and adaptable.
|
| Small nitpick. I found that akka-streams missed many useful
| primitives. For our toolkit, I designed flows with retry-logic,
| flows with cache lines and flows with metric measurements
| (sending data to Datadog).
| coreyoconnor wrote:
| I've had good success with akka at multiple companies. At
| Protenus the core ETL is based on akka streams. Which has
| worked great. No notable issues. Tho we don't run in clustered
| mode.
|
| At glngn we didn't use akka streams (outside of akka http) but
| did use event sourced, persistent entities powered by akka
| typed in clustered mode. Deployed to k8s. Which definitely took
| effort to set up nicely and enable smooth deployments. Our
| clusters were not huge so many problems did not show up (split
| brain).
|
| I haven't used other systems that provided an equivalent to
| akka typed persistent entities. I can't compare akka in that
| sense. However the event sourced persistent entities model is
| really, really effective. Definitely a different paradigm: some
| stuff is trivial that would otherwise be a trial.
|
| I suspect many of the benefits could be achieved by using
| something like Kafka feeding non clustered nodes. But never
| tried.
| drewhk wrote:
| I used to work on the Akka Team, mostly on streams, but I was
| doing different stuff elsewhere in the last years, not
| touching Akka much. To be honest, I am quite emotionally
| distanced nowadays from Akka...
|
| That said, it still feels good reading success stories from
| people who used it. Thanks, you made my day!
| lvice wrote:
| I've now worked for about six months on a Akka.NET codebase. I
| find it a very elegant high-performance framework that gives
| you a lot of flexibility in how you want to solve a wide range
| problems.
|
| This being said, I've been burned already several times by the
| complexity and its raw power. The codebase tends to become
| verbose and difficult to navigate (everything being an
| ActorRef). Debugging is difficult and coding is challenging for
| junior engineers, as you said. I found it very unforgiving to
| mistakes, and it's easy to shoot yourself in the foot if you
| use the abstractions without knowing very well what's going on
| under the hood. Edge cases can be very tricky to manage.
|
| I'm still very conflicted about it. One one side the services
| powered by Akka are quite stable and performant, but I'm not
| sure the complexity justifies the means.
| emodendroket wrote:
| Doesn't .NET now have a very similar core library anyway?
| vips7L wrote:
| Only thing I can think of is the Task Parallel Library but
| I'm not sure how that compares to Actors.
| aliswe wrote:
| Not at all, what I know. well it runs stuff in parallel
| but i believe thats where the similarities end.
| emodendroket wrote:
| That jogged my memory; what I was thinking of was TPL
| Dataflow. https://docs.microsoft.com/en-
| us/dotnet/standard/parallel-pr...
|
| > The Task Parallel Library (TPL) provides dataflow
| components to help increase the robustness of
| concurrency-enabled applications. These dataflow
| components are collectively referred to as the TPL
| Dataflow Library. This dataflow model promotes actor-
| based programming by providing in-process message passing
| for coarse-grained dataflow and pipelining tasks. The
| dataflow components build on the types and scheduling
| infrastructure of the TPL and integrate with the C#,
| Visual Basic, and F# language support for asynchronous
| programming.
| nickkell wrote:
| You might be thinking of Orleans, but it's not exactly
| core.
| guhidalg wrote:
| We use Orleans on my team and it has been 99% worth it.
| The 1% is mostly problems due to bad configuration,
| easily remedied.
| CuriousSkeptic wrote:
| Besides Orleans there is also the Service Fabric SDK and
| now also Dapr
| superfist wrote:
| Please take a look on Proto.Actor (C# version). Very elegant
| and lightweight solution.
| rad_gruchalski wrote:
| The version for go is awesome.
| dastbe wrote:
| i've seen at least two cloud services using akka for a
| component that required long-lived stateful connection
| management. while i think both ended up being successful
| because of akka, it required retrofitting a lot of libraries
| that already existed to fit the actor paradigm, as well as
| requiring at least one person who really understood akka.
|
| id also say some decisions around akka monitoring and how that
| has related to lightbends monetization makes it more difficult
| than it should be to build observability around the internals
| of akka, ex. emitting metrics on actor queue depth.
___________________________________________________________________
(page generated 2021-11-07 23:01 UTC)