Technologically, my company is conservative, within reason. There’s a good reason for that, being an airline, lots of our hardware (airplanes) and processes (at airports and in the sky) are highly regulated, and require the utmost attention to safety, risk management, and other critical factors. In that, we cannot afford to be cavalier, like move fast and break things Silicon Valley an-app-and-a-backend startups.
For this reason, and many others beside, we still operate our critical systems and integrations targeted to execute on the Java Virtual Machine (OpenJDK for the most part).
Recently, my programming group has been developing micro-services using the akka framework. We also use some Apache Camel to glue endpoints together, especially our many legacy data endpoints running in IBM MQ, JMS, and SOA services (more on this later).
My other arguments for continuing to use it, I think, centre around two main points.
The first is that this is a familiar technology to corporate management. We’re not a startup. Things like rearchitecting your existing in-house applications, services, and integrations, into a cloud-native, micro-services based, modern architecture makes senior managers wary that they may be just about to waste many millions of dollars on a plaything for software engineers. Even though another goal of this project is also to reduce our Oracle product footprint (and hence, our licensing costs), “Java” (for us, an Open JDK implementation) is by now a familiar and soothing component in the technical landscape; something that managers nowadays rarely understand.
The second argument for using a technology that runs on the JVM, comes from Akka itself. First, Akka is written in Scala, and this gives us an out from Java to a functional language if we desire it, and meanwhile it comes with a fully scoped Java DSL/API. Second, Akka allows us to use a programming paradigm which, while very old, is coupled to another which is very new. By this I mean Akka’s Actor Model, and there’s also Akka’s implementation of Reactive Streams.
However, even more importantly for me, is the way that Akka leverages that base to be able to provide persistent, distributed, stateful services with scale and performance, and with a CQRS architecture. The systems we need to build must integrate a range of message-driven message inputs. These inputs are often ‘partial’ inputs. By converting them into ‘commands,’ which are then processed by stateful singletons in our service cluster into ordered ‘events’, we achieve performant and concurrent processing of message streams without having to resort to delegating state management to the database layer. Events, the result of the command processing, are always ‘write only’. ‘State’ is regenerated simply by replaying the events in their definitive order. This is generally the lie of “stateless” services: actually they are very typically not stateless, it’s just that you’ve delegated the management of state to your database technology. Your service then must implement the management of thing things like consistency and transaction deadlocks (or delegate this to an implementation layer like a transaction manager and deal with the exceptions). That’s why nonces and version numbers in the storage model exist.
There’s a great overview of the way this interacts with cloud-native services architecture from the Akka developers here. As well there is this interview with Jonas Bonér at InfoQ. There’s also an interesting article here, although, note the implementation discussed is on Akka.Net.