Mobile Microservices

Let me start by stating that Microservices is NOT a pattern but rather a distinctive method of developing software systems which is becoming more and more popular as people realize the advantages of it Vs developing a Monolithic systems.

I’ve adopted and been developing & evolving this type of architecture for mobile applications and decided to share knowledge..

The core of microservices architecture is :

Smart endpoints that process info and apply logic, and dumb pipes through which the info flows.

Before we dive in to the microservices lets go through some foundational, mobile oriented paradigms.

Message-driven

Message driven architecture ( i.e. reactive ) is one of the most important paradigms one needs to understand when developing any mobile app. Most important rule of any mobile app is User Experience. A responsive system ensures quick reaction to any user requests or actions which is driven by asynchronous behavior and timely messages deliveries among objects in the system.

Lets take an example from real life:

Task in hand : Brew a pot of coffee

  • Impediments :
    • You’re out of cream and sugar.

Reactive, message driven approach:

  • Begin to brew a pot of coffee.
  • Go to the store while the coffee is brewing.
  • Buy cream and sugar.
  • Return home.
  • Drink coffee immediately.
  • Enjoy life.

react.png

Monolithic approach:

  • Go to the store.
  • Buy cream and sugar.
  • Return home.
  • Start brewing a pot of coffee.
  • Impatiently watch the pot of coffee as it brews.
  • Experience caffeine withdrawal.
  • Crash.

sequential.png

As you can clearly see, the second approach take double the time resulting in a very poor user experience.

A message-driven application may be event-driven, actor-based, or a combination of the two.

Event-driven system is based on events which are monitored by zero or more observers. This is different than imperative programming because the caller doesn’t need to block waiting for a response from the invoked routine. Events are being broadcasts and absorbed by whoever is willing to listen.

Consider the following diagram describing the event – driven architecture

eventdriven.png

Actor-based concurrency is an extension of the Event-driven system, where messages are directed to a recipient, which happens to be an actor. Messages may cross thread boundaries or be passed to another actor’s mailbox on a different physical server. This enables elasticity — scaling out on demand — as actors can be distributed across the network, yet still communicate with each other as they are all sharing the same bus.

The main difference between messages and events is that messages are directed while events happen. Messages have a clear destination while events may be observed by zero or more (0-N) observers.

 

Example of the Message driven implementation can be found at the following git repo:

Event Driven mobile foundation

Actor-based concurrency

Actor-based applications revolve around asynchronous message passing between multiple actors.

An actor is a construct with the following properties:

  • An observer for receiving messages.
  • The actor’s logic, which relies on pattern matching to determine how to handle each type of message it receives.
  • Isolated state — rather than shared state — for storing context between requests.

Actors pass messages back and forth, or to themselves. An actor can pass a message to itself in order to finish processing a long-running request after it services other messages in its queue first. A huge benefit of actor-based concurrency is that in addition to the benefits gained by an event-driven architecture, scaling computation out across network boundaries is even easier, and callback-hell is avoided because messages are directed to actors. This is a powerful concept that makes it easy to build hyper-scalable applications that are also easy to design, build, and maintain. You only need to think about how messages flow between actors.

Another major benefit of an actor-based architecture is the loose coupling of components. The caller doesn’t block a thread waiting for a response, therefore the caller can quickly move onto other work. The invoked routine, encapsulated by an actor, only needs to call the caller back if necessary.

More to come…..

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s