Image: iStockphoto/outline205

Long before cloud computing became the juggernaut that it is today, it went through a series of definitions, redefinitions, and marketing fluff. There were many different conceptual passes that preceded the industry finally landing on “cloud.” And, it wasn’t so much the term that made it eventually stick, it was the arrival of a high quality, simple-to-use product: Amazon Web Services.

The latest renaissance in application infrastructure has been confused and meandering by comparison. CORBA, RPC, XA, EJBs, SOA, REST, and n-number of web services standards over the past decade have left software development awash in countless languages and abstraction methods. On the one hand, the degree of choice (and availability of outstanding open source frameworks) is great. On the other hand, enterprise software remains stuck in a pattern of write, re-write (for scale), repeat.

This story of retrenching and rewriting is arguably the most common use case in enterprise software.

SEE: Research: 57% using or planning to use industry cloud services (Tech Pro Research)

Jonas Bonér, creator of Akka and CTO and co-founder of Lightbend (formerly known as Typesafe), believes that mainstream developers are fast approaching the moment of microservices mass adoption. I caught up with Bonér to learn more about Lagom and what he calls microservices’ “cloud moment.”

TechRepublic: Microservices seems to have picked up where SOA (service-oriented architecture) left off. What’s still broken today, and why did SOA fail?

Bonér: Traditional enterprise systems are still designed as monoliths: All-in-one, all-or-nothing, difficult to scale, difficult to understand, and difficult to maintain. Monoliths can quickly turn into nightmares that stifle innovation, stifle progress, and stifle joy. The negative side effects monoliths cause can be catastrophic for a company, engendering everything from low morale, to high employee turnover, to preventing a company from hiring top engineering talent, to lost market opportunities, and, in extreme cases, to the failure of a company.

A valid question to ask is whether microservices are actually just SOA dressed up in new clothes. The answer is both yes and no. Yes, because the initial goals–decoupling, isolation, composition, integration, discrete and autonomous services–are the same. No, because the fundamental ideas of SOA were most often misunderstood and misused, resulting in complicated systems where an Enterprise Service Bus (ESB) was used to hook up multiple monoliths, communicating over complicated, inefficient, and inflexible protocols.

Anne Thomas from Gartner captures this very well in her article SOA is Dead; Long Live Services. Although the word “SOA” is dead, the requirement for service-oriented architecture is stronger than ever.

TechRepublic: You just released a new open source microservices developer toolkit and runtime (Lagom) that could potentially deliver a standard runtime for the new class of applications designed to run at-scale on the Java Virtual Machine (JVM) and cloud infrastructure. That seems promising….

Bonér: Well for some time companies using our Reactive Platform–like Verizon, iHeart Media, Gilt Groupe–they leveraged Play Framework, Akka, and Scala to both decompose existing monoliths into microservices, as well as to create green field/new microservices.

What we observed was that while many of these companies had unlimited engineering resources and talent, the far greater pool of Java developers needed a more opinionated framework–specifically for Java–that enabled the construction of microservices built to run and scale on the JVM. This is the reason we are starting with a pure Java API for Lagom, with a Scala API coming next.

TechRepublic: Doesn’t Spring Boot basically solve for that?

Bonér: Spring Boot has done a great job packaging up a microservices framework on top of the legacy JEE eco-system and has indeed become an attractive option for developers that are building and publishing individual microservices.

But, we saw an opportunity to address a much greater problem than the creation of single, individual microservices. Microservices only makes sense as systems, as they are collaborative in nature and it is in between the individual services that the most interesting and challenging things occur. Here we are entering the world of distributed systems, which is a very different world compared to monoliths and the individual services per se.

What has been missing is a framework and platform that takes a holistic systems view on microservices, allowing you to remain productive and keep complexity under control even in systems with hundreds to thousands of services. This is what Lagom addresses.

TechRepublic: That systems view must demand an asynchronous approach to communication between the component parts…?

Bonér: Absolutely. In our view, microservices need to be asynchronous by default. Relying on synchronous REST creates coupling which affects both productivity, scalability, and availability. We also saw the requirement for a modern microservices framework to include event-based persistence through Event Sourcing and CQRS out-of-the-box.

And perhaps most importantly, we saw the requirement for developer and operator productivity. Other microservices frameworks force you to hand-run scripts that boot up microservices (that is, open up terminal windows and boot them by hand) or add additional infrastructure for automation. It does not makes sense that developers should have to give on productivity tools like hot code reloading and install in a whole suite of new infrastructure tools on their laptops just to run and test the system.

SEE: Microservices 101: The good, the bad and the ugly (ZDNet)

Lagom addresses this as well, allowing you to manage hundreds of services from a single CLI, running distributed tests, performing hot code reload, and more.

With Lagom we took the best of Reactive principles from Play Framework, Akka, and Scala, and created a framework that is dead-simple for all Java developers to use. They get the best of asynchronous messaging, elasticity and resilience patterns, with minimal investment up front. As James Roper, Lagom’s project lead, says, “The more asynchronous communication you use, the more resilient and scalable your system will be. We will be taking many organisations into a realm of architecture that they have never explored before.”