Hi Grace, tell us who you are and what lead you into microservices?
Hi, I’m Grace Jansen and I’m a Developer Advocate and Senior Inventor at IBM. Joining as a graduate a few years ago, I joined the software industry in the height of organisations migrating their monolithic applications to microservices.
As a Biology graduate, at the conceptual level, microservices made a lot of sense to me. Having studied organisms that live in societies/communities, I could see the similarities to and benefits of breaking down these huge applications into smaller chunks.
However, upon closer inspection of how microservices are implemented, it quickly became clear that in practicality there are still many issues that microservices don’t yet solve. But…. This is precisely what makes working in this area so fun and interesting and keeps me excited to come to work. How do we solve these problems? How do we evolve and develop microservice application architecture further and make our applications even more resilient and responsive?
What will you be talking about at Voxxed Days Microservices?
Microservices often struggle to deal with varying loads on the system, unexpected failures and elasticity of resource allocation. In my talk I’ll go through how Reactive application architecture can build upon microservice architecture to help tackle these issues and therefore why Reactive is the future of application architecture.
However, application architecture can be a fairly abstract concept and is often hard to visualise. To tackle this, I use an unusual theme in my talks… I use bee societies and behaviours to help create relatable analogies to the behaviours reactive architecture enables applications to achieve to better explain just why you want your application to be Reactive.
Reactive systems are complex to deal with, but looking at all the frameworks (akka, RxJava, Vert.x, etc.) it looks like they are spreading all over. Should a Microservice architecture be entirely reactive or just in a few cases ?
The simple answer is, preferably yes, a Microservice architecture would ideally be entirely reactive.
Reactive systems are defined through the cornerstone principles that make up the Reactive Manifesto. These principles are reactivity, resiliency, elasticity and message-driven. In order for an application to be truly reactive and able to deal with varied loads and failures, every section of an application should enable these principles. Some of the frameworks listed above (e.g. RxJava) enable the implementation of reactive tools, like Reactive Programming, but not an end-to-end entirely reactive solution. As Jonas Bonér explains, whilst tools like Reactive Programming are great techniques for managing internal logic and dataflow transformation asynchronous and nonblocking execution, it does not enable the application to be resilient to failure or elastic in its response to load changes. The tight coupling between computation stages in applications that implement Reactive Programming in isolation means that they usually handle success or failure directly without signalling it to the outside world. This lack of addressability makes the recovery of individual stages harder to achieve as it is typically unclear where exceptions should be propagated. As well as this, the lack of location transparency when only using Reactive Programming in isolation makes it hard to scale out a program purely based on Reactive Programming techniques adaptively in an elastic fashion and therefore requires layering additional tools on top, such as a Message Bus, Data Grid or bespoke network protocols.
However, when Reactive Programming is used alongside other tools such as circuit breakers, bulkheads, etc, on a system level in enables the application to become a complete Reactive System. This enables the application to become elastic, resilient and reactive not just when things work as expected but also in the face of failure and under unpredictable load.
Good, see you soon then
#ReactiveApplicationArchitecture #ReactiveManifesto #Analogy
My contact information: