Hold onto your hats Scala people – Typesafe is no more. Not because it’s been crushed in a horrific Unicorn stampede or anything like that – there’s just been a name change and rebrand. As of today, the people who brought you Akka and the Play framework now go as ‘Lightbend’.
Before you jump to logical leaps about entry into quantum computing or similarly fantastic pivots, President and CEO Mark Brewer has assured us that there’s no big symbolism behind the name. In fact, part of the reason Typesafe opted for Lightbend is that is it relatively technologically agnostic, rather than explicitly linking the company to a specific language or functionality as it had previously with the Scala language. This is also very handy when you consider the exploding Reactive space Lightbend has found its niche in over the past year or so.
The decision to rebrand was announced in May of last year, and since then, the company have been hard at work probing the sentiment behind the Typesafe community, its employees, and other industry experts, to help guide their decision.
Lagom: an OS framework for a Reactive age
In that same spirit of corporate refraction, Lightbend have another surprise for the JVM community today: Lagom – a brand new open source framework, built from Reactive Platform technologies the Play framework, Akka, and ConductR and designed for the Java platform.
Whilst this might come as a surprise to some, Java users actually make up around 50% of Lightbend’s customer base. Although Lightbend will certainly be working to develop a Scala based counterpart down the line, for now, it’s keen to push the technology forward as fast as it can – and for that to happen, for the first time in the Scala warders’s history, it’s releasing a tool that’s Java first.
Jonas Bonér (Lightbend CTO and Co-Founder) identifies three characteristics that set Lagom apart from other offerings in the space. For a start, all communication is asynchronous by default. This means your system is default scalable and resilient. It also offers event based persistence as default. Thirdly, Lightbend has optmised the development environment around Lagom for maximum productivity. There’s no need to bring in solutions like Ansible or Chef for automation – Lagom does the heavy lifting for you.
Taking its name from the Swedish word for sufficient, adequate, or just right, Bonér regards Lagom’s characteristics as a distillation of Lightbend’s four core ideas for what microservices should offer. These are as following:
- Services should be isolated, loosely coupled enough to allow scaling and resilience as required. And, it should be noted, that’s scalability as required – no more of this circumlocutory debate about exactly how big a microservice needs to be.
- They should abide by the single responsibility principle – each individual microservice should be doing one thing and the scope of the service should be clear, regardless of its size.
- Services should have very simple backend compose. Each one needs to own its data “all the way down to the database.” The rise of microservices has been intertwined with the market’s awakening to containers and their ability to take users all the way down to the stack. Thanks to the emergence of Docker and its competitors, traversing deep down to the furthest reaches of a system is a reality for any developer, and it’s something that must be considered when putting microservices in place.
- In a crowded marketspace, microservices have come to mean a lot of things to many different people, however, Lightbend have seen Akka and Play customers engaging with this architectural style long before the practice become popularised on the conference circuit. Based on its experiences with Akka and Play, it believes all services need to be asynchronous. As Martin Fowler wrote in his viral article around microservice trade-offs last year, “Asynchronous programming is hard: hard to get right, and much harder to debug. But most microservice stories I’ve heard need asynchrony in order to get acceptable performance.” Hopefully Lagom should make things a little easier in this respect.
Although Bonér notes that Akka and Play users have been “succeeding” with and are happy to build their microservices with these existing products, with the growth of microservices, the need for a dedicated tool had become clear.
A key problem with microservice implementation from is just how easy it is for developers to reflexively jump to the wrong solutions. Bonér cites the example of REST in microservices in particular as an example of this snafu, or where he’s seen developers succumbing to the temptation to use JPA as a default for persistence. “Sure it may be necessary sometimes,” he adds, “but it can be a negative thing. Modern defaults on Reactive principles enable you to build these services across scale.”
If you’re interested in learning more about Lagom, you might be interested in registering for this introductory Webinar, taking place on March 17th.
The road ahead for Lightbend
Whilst some commentators may see Lightbend’s preference for Java on Lagom as dark news for the Scala community at large, both Bonér and Brewer are emphatic about the organisation’s commitment to the language. Brewer points out that Scala based innovations like Apache Spark and Kafka have come from outside Lightbend, but both have been instrumental in helping to push the Scala language forward.
In fact, last year Scala appeared to be more popular than ever, in spite of Java’s move to functional with the introduction of lambdas in Java 8. Scala will remain a key piece in the Lightbend arsenal, with continued investment in its evolution, and all of Lightbend’s platforms and tech will continue to be built in Scala. They’ll just be trying to do “just as good a job” for Java (and the huge base of customers and developers it carries in its wake) on the side.