Microservices, microservices everywhere

At OSCON I got the opportunity to bend Steven Pousty’s (developer evangelist extrodinaire) ear about microservices during vert.x office hours.  He was good enough to let me ramble on and then give me some new things to think about.

The one thing I’ve not seen a satisfactory answer to is the scope of a microservice.  That is what makes it micro?  There’ve been objections to Fowler’s “business capabilities” as still too vague; he’s even written a “sizing” side bar commentary.  I’ve heard the “nothing new under the sun” folks claiming that this is folderol that’s been best practice since the dawn of programming.

I’m going to throw my hat in the ring with what may be a blend of the two positions.

A microservice is returns a single set of facts, can do simple transforms or translations of those facts, and can use different sources to do simple collation to present facts.  Anything else is either an application or an application masquerading as a service.

What’s the idea behind transforms and translations?

An application takes facts and manipulates them to create knowledge or new facts.  Taking a pricing sheet and calculating spot discounts based on contracts, loyalty incentives, coupon codes, etc. is the work of an application.  This is the standard “business logic” layer.

An allowed transform for a microservice would be US Dollars to British Pound Sterling.  (Steven’s idea, I hadn’t thought about storage of facts and known transforms that could be validated)  That microservice may call service to determine the exchange rate to be used, nothing stipulates that a microservice must be completely standalone.

A tactical example:

A RDBMS (remember those?) is an application masquerading as a service composed of microservices.  Ok, so masquerading may be strong, but presenting a service interface.

The service interface is the SQL query.  Known interface, known return, but under the covers an RDBMS can do all sorts of manipulation of facts to return a “single query”.  I’ve seen user logins for web apps that used data from 13 different tables (ask me over a beer sometime).

The idea of stored procedures and moving code closer to the data means that the RDBMS is an application.  The “service return” could be an entirely new set of facts or knowledge generated by the RDBMS application and returned via the service interface to another application.

Where then are the microservices?  The microservices in the RDBMS are the tables and views.  A single table contains a single set of facts, organized in columns.  A table is responsible for only its fact set.  A materialized view can collate tables based on certain criteria to present as a single fact set.

The arguments about size and appropriate complexity of microservices apply to database design.  How normalized should your fact set be?  Too little normalization, big mess of facts to work with; too much, too many services.  Same with appropriate use of views, too many keys and joins should be a query, not a composite fact table (e.g. microservice).

Which of course means that the size answer for microservices is the same for any IT question posed to me: “It depends.”

Example as tl;dr:

  • Select from table == microservice
  • Join multiple tables and return a value based on a third table == service
  • Star joins, data cubing, stored procedures == application with a service interface

Why the all the fuss in the first place?

Microservices (new, old, or indifferent) are key to building cloud native applications.  The new world of application development, cloud or enterprise, should be API first.  Everything is a service.  And not in a marketing as-a-Service sense.  APIs are everywhere, and changing the point of view of the architecture to API first is radical for a lot of developers.  Cloud native applications need to be stateless, scalable, fungible.  The best way to get there quickly is to build sets of services and microservices that feed that logic processors.

Even the infrastructure layer (where I play the most) is headed this way.  Docker to create composable and movable containers.  OpenShift Origin to standardize framework deployments and automate framework scaling.  Even AWS auto-scaling groups and OpenStack Heat autoscaling.  And outside the cloud paradigm, this sort of approach will allow enterprise applications the same levels of speed and flexibility of coding and deployment.

What’s your view on microservices?  Are they overhyped or are you applying this lens to your architectures.

A previous version of this post existed but was lost and this is a complete rewrite.

Leave a Reply

Your email address will not be published. Required fields are marked *