Scala services in action
1 like419 views
The document summarizes a talk given on Scala services frameworks. It introduces Play, HTTP4s, Spray/Akka HTTP, Finch, and Lagom frameworks. It discusses criteria for evaluating frameworks like routing, pluggability, and deployment. It provides high-level overviews of each framework, noting pros and cons. Design, build, support and extension aspects are summarized for each. Finally, it maps frameworks to developer personas and adoption curves, noting where each may be good fits based on priorities like rapid prototyping, functional programming, or enterprise needs.
![FP and Microservices
Immutability
Composability
Functions as 1st class citizens
Laziness
Types
=> Isolated and Disposable
=> Composable units
=> Refinement services, Bounded Ctx
=> Serverless
=> ???
K
- ??? might be Session Types in the future ? Remote[T] ?](https://image.slidesharecdn.com/scalaservicesinaction-161216003720/85/Scala-services-in-action-5-320.jpg)
![Finch
S
● Provides a DSL on top of Twitter’s Finagle webserver framework
● Allows plugging in of different libs for JSON, auth etc, but uses things like
Circe by default
● Models services as something called an Endpoint[T] that can handle
requests and reply with responses monadic
● Functional by design, to allow for AND / OR or mapping of functions over
Endpoints](https://image.slidesharecdn.com/scalaservicesinaction-161216003720/85/Scala-services-in-action-39-320.jpg)
![Spectrums
L
i
b
r
a
r
y
F
r
a
m
e
w
o
r
k
M
o
n
o
l
i
t
h
Mature / Emerging
[Team / Org]
Flexibility vs Time to market
K
● Lots of ways to measure and compare
● Monolith <> Library.. Size and preconfiguration available.
Frameworks/frameliths in the middle
● Eval against maturity of the team and organisation. Tolerance for risk.
● Is time to market or ability to change a running system most valuable ?
● Monolith style generally quicker to get ot of the door, but debt is in later
modification or isolated scale.](https://image.slidesharecdn.com/scalaservicesinaction-161216003720/85/Scala-services-in-action-45-320.jpg)
Scala services in action
- 1. Scala Services in Action Kingsley Davies Sofia Cole @kings13y @sofiacole35
- 2. In the beginning... K Who we are and why we are giving this talk.. - Originally asked to review and write pieces for US publisher - Have a few years experience working with different frameworks in Scala - Painful Play 2.3 -> 2.5 upgrade. There must be better ways..
- 3. Mapping all the things www.sli.do event code: #7277 S MENTION SLI.DO FIRST SO PEOPLE HAVE TIME TO USE THE CODE We’ll look at: - What you expect from microservices - What you expect from a service framework - How these frameworks deliver on these expectations - How they compare in the context of use and users. - There’s code, but this is more overview
- 4. What are microservices? K ● Microservices are all about scale. ● Scale challenges come in several forms, from federating and distributing work, to deploying and horizontally scaling individual artefacts to just adding specific features to a system. ● Design and build in terms of functional and isolated components is the basic goal when implementing a microservices strategy.
- 5. FP and Microservices Immutability Composability Functions as 1st class citizens Laziness Types => Isolated and Disposable => Composable units => Refinement services, Bounded Ctx => Serverless => ??? K - ??? might be Session Types in the future ? Remote[T] ?
- 6. The Pizza of Awesome - microservice delivery Design Build Support Extend K Microservices lifecycle: ● Design ● Build (+ Deploy) ● Support (+ Monitor) ● Extend
- 7. Criteria and caveats Testing Performance Documentation support Pluggability, Deploy ¯_(ツ)_/¯ …. Routing Pluggability (auth, persist) (Un-)Marshalling Deploy Monitoring K What from a framework ● Routing ● Pluggable auth, persistence etc.. ● Marshalling / unmarshalling ● Deployment, and monitoring support ● Cycle time (impedance mismatch from idea to delivery) ● It’s a shallow swim, not a deep dive.. Not covering ● Testing in depth ● Performance
- 9. Play S ● ● ● ○ ○ ● ● Play is claims to but Json at the forefront, something we’ll be taking a look at, and is Restful by default ● Website is good
- 10. S CON - Runtime Errors! (GUICE!)
- 11. S Con - Compiles after its first request as default - bit annoying
- 12. } S CON - Default application.conf is overwhelming (Slide needs work - basically want to get across how stupidly long the file is)
- 13. S PRO - Super simple to get going - here are the routes as defined in conf/routes
- 14. S PRO - Fantastic built in UI
- 15. S PRO - Json formatters - easiest one to introduce an optional ID in the json
- 16. S … add this to your build.sbt
- 17. S And you write your methods straight into your controller!
- 18. Design Build Support Extend S Design - Green with caveat of Guice. Little boilerplate, 0 to service very quickly Build - If we’ve given Design slack for Guice, I’m inclined not too here. If you go for Guice, there is going to be work to make sure everyone is up to speed and comfortable.And you’re saying goodbye to relying on the compiler. There’s also that the compile time for Play is really quite long. Comes with everything - really heavy duty. Support - Production support by Lightbend. Proven to be reliable by it’s use in many companies using Scala. Dozens of example to download straight from the website and also uses activator which is a tool to explore tutorials. Extend - Upgrading from 2.3 - 2.5 Kingley
- 19. http4s K ● Functional client/server wrapper around http ● Variety of options to deploy to different containers ● Async using Scalaz tasks and streams ● Typelevel ● v lightweight (similar to Servlets.. Looks slightly close to node js)
- 20. val service = HttpService { case GET -> Root / “hello” => Ok(“Hello there”) } K
- 21. K ● Service code can end up quite noisy for a single service endpoints.. This is both good and bad.. ● JSON with argonaut and codecs felt a bit too boilerplate like..
- 22. Design Build Support Extend K Design - Nice and lightweight. Very little ‘noise’ code between design and impl Build - Feels very minimal.. Sometimes too minimal.. (like node etc..) Not my preferred level of abstraction. Support - Nice flex around deployment options - No admin endpoints available out of the box/lib Extend - Interesting as small enough to be readily up for extension. Possible candidate to provide (custom/implicit) types over the wire for client and server
- 23. Spray AND akka-http S ● Decided to review these together because… ○ No roadmap to upgrade spray to scala 2.12… see ■ https://twitter.com/oxbow_lakes/status/796311657 203068928 ○ Open-source ○ Layers on top of Akka and Scala ○ Asynchronous ○ Actor-based ○ Fast ○ Lightweight ○ Fault-tolerant ○ Scalable ○ Responsive
- 24. S Spray support - saw this page A LOT
- 25. Spray akka-http S Actors are annoying
- 26. Spray akka-http S ● Quite similar however you no longer need to deal with the Success and Failure case that onComplete forces you to do deal with and the akka http still gives you nice messages if there is an error ● Spent far too long when I first worked with these routes on the implicit conversion to Json. unlike play, you don’t need to be explicit and say something like .toJson. Also I found that implicits got mixed up when I was using different ones in different routes ● Also took too long to figure out how to return futures - spray you have to deal with them differently - not to worry in akka-http - seems to figure this out by itself (have a look at this more Sofia!)
- 27. Spray akka-http S ● When you miss a tilda something weird happens and isn’t always obvious before you know ● The route/routes following the missing tilda works but not the one before...
- 28. Design Build Support Extend S Spray …. Then … Design - Quick and clear on what to do to go from 0 to go. Boiler plate is there but minimal and once you’re comfortable with nested routes it does speed up development Build - Implicits make the routes slightly magic which stalled me for a little while. People dislike the routes and the runtime tilda problem Support - Not great, probably the biggest and most important reason not to do it Extend - Error messages are not always helpful, but once you’re comfortable with the codebase and framework everything is thumbs up
- 29. Design Build Support Extend S Swap to akka-http which will be much better wooooo good news that’s spray is dying Design -FAST Quick and clear on what to do to go from 0 to go. Boiler plate is there but minimal and once you’re comfortable with nested routes it does speed up development. Also use of magnets to attach behaviour to to routes. Build - Implicits make the routes slightly magic which stalled me for a little while. People dislike the routes and the runtime tilda problem Support - large and active community exists around Akka as well as a number of dashboard tools be available for akka. Typically use of kamon is wired in for supporting the production env Extend - Given the level of commercial and enterprise support for akka, extension is reasonably simple.
- 30. Lagom K ● Framework aggregating a number of other open source projects to support 4 phases of mircroservices ● Non blocking and asynch ● For distributed systems
- 31. Play Akka Cassandra (kafka + JDBC) K ● Play (for routes and guice: DI + Inter Mu Comms) ● Akka (processing: streams, cluster and persistence)
- 32. Service Locator & Gateway Meta vs Impl Event Sourcing Command Query Responsibility Segregation K ● Service Locator and Gateways ○ Locator: http://localhost:8000/services ○ Gateway on 9000, through which services can be addressed ● Separation of code and meta ○ Distinct separation between implementation code and ‘code about code’ ■ E.g. Descriptor information, service interface code, Marshalling code etc.. ● Event Sourcing ○ State is recreated by replaying a sequence of events ○ Events are atomic ○ No need for persistence impedance mismatch. Objects need not be persisted. ● CQRS ○ Sorta required for ES, as no data model to readily query ○ Using 1 model to update information and another to read information ○ Commands affect create, update, delete ○ Different materialised views possible
- 33. Persistent Entity Command / State / Event Commands -> Events -> Persist K ● Setup of a lagom project ● And overview of main classes that come out of the box used to create persistence
- 34. K ● The very morning of the talk, lagom releases it’s (suggested) Scala API! ● Let’s get hacking...
- 35. Compile time DI w/ cake or Macwire Stronger Typed APIs Typeclass Serializers / path params Macros for service clients ~Kafka as the message broker K ● Setup of a lagom project with Scala API ● What’s new in the milestone release for Lagom + Scala...
- 37. Design Build Support Extend K ● Still no official Scala API: https://github.com/lagom/lagom/issues/1 Design ● Well thought out patterns, but also slightly constrained for RAD to the prescribed, opinionated, way. Prob not the right choice to PoC with. Build ● Low overhead dev setup ● Slightly slow realtime/hot compile+ run feedback.. Support ● Conductr required for Lightbend Monitoring and out of the box deployment.. Non Conductr deployment non-trivial (write a service locator - seen as a time vs money investment/ trade)..(note K8s support been started here: https://github.com/lagom/lagom/issues/59 ) ● Nice ‘bundle’ abstraction for deployment though.. Extend
- 38. ● Depends how far deviation differs from out of the box idioms and supported tools/raodmap @See: https://ordina-jworks.github.io/microservices/2016/04/22/Lagom-First-Impressions-and -Initial-Comparison-to-Spring-Cloud.html#anatomy-of-a-lagom-project
- 39. Finch S ● Provides a DSL on top of Twitter’s Finagle webserver framework ● Allows plugging in of different libs for JSON, auth etc, but uses things like Circe by default ● Models services as something called an Endpoint[T] that can handle requests and reply with responses monadic ● Functional by design, to allow for AND / OR or mapping of functions over Endpoints
- 40. endpoint :: endpoint => endpoint (AND) endpoint :+: endpoint => endpoint (OR) endpoint { fn } => endpoint (map) S ● Composable DSL and functional makes it possible to build API from reusable building blocks ● Endpoint is the main abstraction. Can be AND / OR / Mapped
- 41. val retrieveItem = get("items" / uuid) { uuid: UUID => Ok(itemRepo.get(uuid)) } val endpoints = ( retrieveItem :+: createItem) val service = endpoints.toService S URL and method match on get and uuid is extracted and typed It is then passed in as a function param DSL provides types like OK (http 200) as a response Can see how these URLs are combined with OR to make the list of service endpoints
- 42. S + Admin endpoints provided by com.twitter.server.TwitterServer (~24 endpoints) + Simple, composable and typed + Easy JSON conversions through circe and shapeless magic.. + Low cycle time to convert idea to delivery - If you need to convert from Twitter specific types to standard ones - Finding people with Finch experience - More sample apps would be great
- 43. Design Build Support Extend S Design - Very little noise between technical design, requirement and initial development. The magic of generic types make various conversions trivial Build - Similarly, little enforcement of specific patterns in place, making development quick and simple. Support - Over 2 dozen support admin endpoint available through the Twitter server, making the application of monitoring on a delivery artefact simple. Only caveat here being the extensive use of Shapeless can make some diagnosis of errors a challenge. (Get Dave’s Book!!!!) Extend - Built as a starting point for extension. Extension tricky due to heavy use of bespoke Twitter types. Not just out of the box.
- 44. Activity and Popularity See: https://scala.libhunt.com/ K Comparisons taken from: https://scala.libhunt.com/ E.g. https://scala.libhunt.com/project/lagom/vs/playframework?rel=cmp -lib
- 45. Spectrums L i b r a r y F r a m e w o r k M o n o l i t h Mature / Emerging [Team / Org] Flexibility vs Time to market K ● Lots of ways to measure and compare ● Monolith <> Library.. Size and preconfiguration available. Frameworks/frameliths in the middle ● Eval against maturity of the team and organisation. Tolerance for risk. ● Is time to market or ability to change a running system most valuable ? ● Monolith style generally quicker to get ot of the door, but debt is in later modification or isolated scale.
- 46. Personas The Hacker: Bleeding edge tech. Open to risk. For the love of tech. The Leader: Early adopter and evaluator.. Mid risk profile. Tool to get the job done. The Follower: Whatever ‘stack’ the company has adopted. Low risk. Utili-tech K ● Introduce our developer persona’s
- 47. ...on the curve K ● Developer personas and where they appear on the chasm
- 48. ...mapping all the things K ● Mapping our frameworks on the chasm
- 49. ...good for.. Rapid Prototyping / Mocks Functioning Functional The Enterprise Next Gen Spray ? NG Types ? K ● Considerations for the system architect/delivery lead/manager/CTO and how they map to a library choice. ● Mocks -> http4s ● Functional -> Finch ● Enterprise -> Play ● Next Gen enterprises -> Lagom ● Where does Spray / Akka-http fit in ? (note, akka / akka-http often used under the covers in Lightbend stacks)
- 50. Conclusion FP => Microservices isomorphism Monoliths / Frameliths => bootstrap speed vs future agility More planes in the blue skies, More platforms onto the boats Over the wire types => FTW Business ⇔ Tech ⇔ People => Decisions K - Some level of mapping or isomorphism between FP and microservices - Monoliths (frameliths) are quick to get started, but their agility can atrophy quickly - More ‘practical’ blogs, samples and decision trees required - Watch out for Over the wire Types! OTWT => FTW!
- 51. Thanks, Links and Questions THANK YOU!!! Dave Gurnell & Team Underscore & ITV ● @kings13y / @sofiacole35 ● http://breakpointradio.net ● http://underscore.io/ ● www.sofiacole.com ● http://bit.ly/finch-101 ● http://bit.ly/finch-to-1 ● http://bit.ly/lagom-scala-ex ● http://bit.ly/onthetypelevel ● http://bit.ly/opencliptroot ● http://bit.ly/sesstypes ● http://bytes.schibsted.com/109/ ● http://bit.ly/shapelessPRs Be Nice :-) S My blog posts that will be going up over the coming weeks + source code in github! + slides! + KD blogpost on Lagom 1.3.0-M1 the Scala edition on _ blog ! Follow #scalax or podcast / tweets for notifications!