AhaApps Blog

Microservices with MuleSoft – Part 2 – Getting Started with your Microservice Strategy

Posted by Rich Bronson

Find me on:

Jul 1, 2016 10:00:00 AM


First of all, I want to thank everyone who commented on my first blog post on this topic titled Microservices with MuleSoft - Part1


Microservices_blog2.jpgMicroservices architecture is a big paradigm shift in design and requires us not
only to rethink the way we design applications but also the processes we use to develop and manage our applications. Today I would like to go deeper in design and look at a simple n-tier application and show how it might look in a Microservices paradigm.


An N-tier Application


Looking at figure 1, you see a fairly typical design for a web based application.  In this case we have an application that get, save and calculate insurance policies.



Figure 1 


While we have multiple distinct layers which is good Business logic is separated from the UI and the data layer is separated from the business logic. 


If a user wants to save a policy

  • The user calls the UI layer to save the policy.
  • The UI controller calls the Insured object to get the person who is insured. 
  • Then the UI controller calls InsuredService and InsuredItems Service apis to get their information.
  • Then the UI controller calls PolicyCalculator to calculate the prices.
  • Then call the Policy object to save the policy.  

These are all good thing but here are a few things I do not like about this though. 


First of all, everything is in the same giant database.  While this has some advantages in having all my data in one place there could be some downsides. For example, maybe I want my Insured, and Insured items to be stored in SQL databases but I want the policies in a document database. Or perhaps I expect there to be so much data in the database that performance or storage space may become an issue.


The second thing is that in this example most of my operations are quick low resource calls but PolicyCalculator is CPU and memory intensive.  To solve that I will make multiple copies of the entire application (except the database) and put them on different virtual servers.  This works but is kind of wasteful.



Microservices with Composed Services


Now let’s look at it from a Microservices approach. I want to point out a couple of things in Figure 2. All my business logic items are now Microservices and each one is entirely self-contained and they communicate with each other via APIs.  They have their own databases and the DAL is gone. You can still have a DAL but your abstraction is at a different level now.



Figure 2


In reference to our concern above about scaling up, since PolicyCalculatorService is entirely self-contained we can have ten copies of that service lying around but only two of the others.


Finally, you will notice we have added a composed service. Composed services (or orchestrated services) are services that are built out of calls to existing services. I like to use MuleSoft for orchestration because they make it so easy. Here they tell our application to call the service, take the results and call the next service and so on until you have performed all the operations you need to complete your task.


The process here is very similar though the design is more flexible. 

  • The user calls the UI layer to save the policy.
  • The UI calls the Save Policy composed service.
  • SavePolicy calls InsuredService and InsuredItems Service apis to get their information.
  • SavePolicy  then calls the PolicyCalculatorService api to calculate the rates.
  • Finally, the PolicyService api is called to save the policy and the results are returned to the API.



A Note on Composed Services


Before we move on I want to point out that many of the examples you will find for Microservices will have no mention of composed services. For me this is one of the points where application overtakes theory.  


While you can do Microservices without a composed services layer you will need some kind of business layer to put all the pieces together to form your business logic flow. Doing this with composed services allows you simplify the creation and testing of your process flows to the point that you can have junior level developers or even business analysts designing your flows while your developers focus on the more complex logic in your Microservices.





Something you may have noticed by now is that the behavior between the two examples is very similar.  Logic flows very much in the same way. Instead what we have done is taken our separation of concerns to the next level but making each component completely independent of the other. Next time we will talk about some of the problems this introduces and how to resolve them.



A little bit about AhaApps. We are a very different company, our philosophy boils down to these tenets:

· Live and breathe to create “Aha” moments for our clients.

· Get things done right the first time.

· Listen intently and ask the right questions.

· Modernize Information Technology with Integration.



Contact AhaApps for  Microservices Strategy