Analytics as a (micro)service

micro-service-architecture

What is a microservice? and why analytics can take the form of a microservice?

Ok. Just to be brief, a microservice is a service that it is highly independent and focus on doing mainly one task. For example, you want a software that does sales forecasts; you could go to a vendor and get a complex and expensive software that does all sorts of stuff on time series data… but you really just need a plain sales forecast every now and then.

You can then have someone in your team that writes some code that does the sales forecast. This team member will be someone you rely on to perform the analysis, but you could also ask him/her to package the code and make it available to you to use whenever you need. This packaged code, that can be used by a “non-coder” to perform an analytical task is what I would define an “analytics microservice”.

Now, the question is:” Why a microservice?, why not buying an analytics box?”.

To answer this I need to digress slightly and discuss what a competitive advantage is in this context. I believe a competitive advantage can be of two kinds:

  1. You do something your competitors don’t do
  2. You do something better than your competitors

The marketing of analytics solutions is still, largely, about making the case for analytics as something a company should invest into… well that’s pretty basic.

What about using the wealth of knowledge at the cross-over of computer science and statistics better than your competitors?

That’s where I think microservices can be of use. You can write and update your microservice as soon as something new comes up, before any vendor has gone through the product innovation cycle. I mean, we have seen softwares like SPSS introduce data analytics techniques decades after were used by academics.

It didn’t use to be so important to have updated data analytics tools, but now days, can be.

Think about a bank, that might be using customer transactions data to forecast the start of an economic downturn (e.g. the bank could see lower spend on electronics and travel, late repayments on credit cards etc etc). This could help the bank choose the right balance of liquidity and reserves, possibly working slowly toward increased reserves when the market is slowing down in a non-dramatic fashion (suddenly stopping credits it’s a bad thing). Now, if the analytics model the bank is using is inefficient there is a higher chance of false positives and therefore the bank might increase reserves when unnecessary,… paying the opportunity cost of not lending. The bank with the better model is both less exposed to risk and also paying the right price for being less exposed.

The above is just an example (not very realistic since banks balance sheets are not managed in this way), where the bank could invest resources in creating a highly specialised and cutting edge microservice simply to predict crisis rather than buying a software that uses 10-30 years old algorithms and do all sort of things that aren’t needed.

It then could happen that you find yourself with a collection of disparate microservices that don’t talk to each other. Well, in the specific case of analytics solutions I believe this is not a huge obstacle since they all do speak the same language ultimately…maths; in a way or the other. Possibly stick to a selection of coding languages that don’t differ greatly and it shouldn’t be easy to join up all the microservices.

Next time I’ll write a blog I’d like to show an example using Python and Spark. I will time how long it takes to me to write a microservice that can be of real use.

Bye for now.