Rockford Lhotka's Blog

Home | Lhotka.net | CSLA .NET

 Friday, 30 November 2018
« Netflix on the Surface Pro | Main |

For some time now it has been the case that people are all excited about "microservices".

I want to start by saying that I think this is a horrible name for what we're trying to accomplish, because the term attempts to put the concept of size onto services.

Calling a service is expensive. You are creating a message, serializing that message, sending it over a network via http or a queue (or both), where it is deserialized, and finally the service can do some work. Any response goes through all that same overhead to get back to the caller. That overhead is measured in milliseconds - usually 10's of milliseconds.

So if your "micro"service does work that takes less than 10-20 milliseconds to complete, then you've paid this massive performance cost to get to/from the service over the network, only to have the actual work take less time than the overhead.

That's like paying your auto mechanic for a full hour, just so they can do a 5 minute fix to your car. Nobody would do that without being forced (and sometimes we are - due to specialized skills or tools/parts availability).

This analogy translates to the services world too. Calling a service is fine if the service:

  1. does enough work to be worth the overhead of calling the service (the work took longer than the network overhead)
  2. needs to run in a secure location
  3. is required to run in a geo-bounded location (think GDPR)
  4. must run on specialized hardware that doesn't exist elsewhere
  5. contains code that is so valuable that, if reverse engineered, would destroy your organization (variation on security)

I've tried to put those in order from most to least likely, but everyone's scenario is a bit different.

The point I'm really getting at, is that in the majority of cases it is important to make sure a service does enough work to make it worth the non-trivial overhead of getting to/from the service over http and/or a queue.

In those other less common scenarios there's a business decision to be made. If the service is very small and fast, you will be paying massive overhead for very little work to be done. Presumably the business is saying that those other concerns outweigh the fact that your app will be far slower than it could be.

(hint: as a developer you should make this clear to the business stakeholders up front - head off the question you know is coming later: "why is this app so slow???" - you want to be able to pull out the email thread where you explained that it will be slow because the business decision maker chose to put some tiny-but-critical bit of functionality in a service)

On this page....
Search
Archives
Feed your aggregator (RSS 2.0)
November, 2018 (1)
October, 2018 (1)
September, 2018 (3)
August, 2018 (3)
June, 2018 (4)
May, 2018 (1)
April, 2018 (3)
March, 2018 (4)
December, 2017 (1)
November, 2017 (2)
October, 2017 (1)
September, 2017 (3)
August, 2017 (1)
July, 2017 (1)
June, 2017 (1)
May, 2017 (1)
April, 2017 (2)
March, 2017 (1)
February, 2017 (2)
January, 2017 (2)
December, 2016 (5)
November, 2016 (2)
August, 2016 (4)
July, 2016 (2)
June, 2016 (4)
May, 2016 (3)
April, 2016 (4)
March, 2016 (1)
February, 2016 (7)
January, 2016 (4)
December, 2015 (4)
November, 2015 (2)
October, 2015 (2)
September, 2015 (3)
August, 2015 (3)
July, 2015 (2)
June, 2015 (2)
May, 2015 (1)
February, 2015 (1)
January, 2015 (1)
October, 2014 (1)
August, 2014 (2)
July, 2014 (3)
June, 2014 (4)
May, 2014 (2)
April, 2014 (6)
March, 2014 (4)
February, 2014 (4)
January, 2014 (2)
December, 2013 (3)
October, 2013 (3)
August, 2013 (5)
July, 2013 (2)
May, 2013 (3)
April, 2013 (2)
March, 2013 (3)
February, 2013 (7)
January, 2013 (4)
December, 2012 (3)
November, 2012 (3)
October, 2012 (7)
September, 2012 (1)
August, 2012 (4)
July, 2012 (3)
June, 2012 (5)
May, 2012 (4)
April, 2012 (6)
March, 2012 (10)
February, 2012 (2)
January, 2012 (2)
December, 2011 (4)
November, 2011 (6)
October, 2011 (14)
September, 2011 (5)
August, 2011 (3)
June, 2011 (2)
May, 2011 (1)
April, 2011 (3)
March, 2011 (6)
February, 2011 (3)
January, 2011 (6)
December, 2010 (3)
November, 2010 (8)
October, 2010 (6)
September, 2010 (6)
August, 2010 (7)
July, 2010 (8)
June, 2010 (6)
May, 2010 (8)
April, 2010 (13)
March, 2010 (7)
February, 2010 (5)
January, 2010 (9)
December, 2009 (6)
November, 2009 (8)
October, 2009 (11)
September, 2009 (5)
August, 2009 (5)
July, 2009 (10)
June, 2009 (5)
May, 2009 (7)
April, 2009 (7)
March, 2009 (11)
February, 2009 (6)
January, 2009 (9)
December, 2008 (5)
November, 2008 (4)
October, 2008 (7)
September, 2008 (8)
August, 2008 (11)
July, 2008 (11)
June, 2008 (10)
May, 2008 (6)
April, 2008 (8)
March, 2008 (9)
February, 2008 (6)
January, 2008 (6)
December, 2007 (6)
November, 2007 (9)
October, 2007 (7)
September, 2007 (5)
August, 2007 (8)
July, 2007 (6)
June, 2007 (8)
May, 2007 (7)
April, 2007 (9)
March, 2007 (8)
February, 2007 (5)
January, 2007 (9)
December, 2006 (4)
November, 2006 (3)
October, 2006 (4)
September, 2006 (9)
August, 2006 (4)
July, 2006 (9)
June, 2006 (4)
May, 2006 (10)
April, 2006 (4)
March, 2006 (11)
February, 2006 (3)
January, 2006 (13)
December, 2005 (6)
November, 2005 (7)
October, 2005 (4)
September, 2005 (9)
August, 2005 (6)
July, 2005 (7)
June, 2005 (5)
May, 2005 (4)
April, 2005 (7)
March, 2005 (16)
February, 2005 (17)
January, 2005 (17)
December, 2004 (13)
November, 2004 (7)
October, 2004 (14)
September, 2004 (11)
August, 2004 (7)
July, 2004 (3)
June, 2004 (6)
May, 2004 (3)
April, 2004 (2)
March, 2004 (1)
February, 2004 (5)
Categories
About

Powered by: newtelligence dasBlog 2.0.7226.0

Disclaimer
The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.

© Copyright 2018, Marimer LLC

Send mail to the author(s) E-mail



Sign In