BT

New Early adopter or innovator? InfoQ has been working on some new features for you. Learn more

The Economics of Microservices: Phil Calçado Recommends Avoiding ‘Microliths’ at CraftConf

| by Daniel Bryant on May 17, 2017. Estimated reading time: 4 minutes |

At CraftConf 2017, held in Budapest, Hungary, Phil Calçado presented "The Economics of Microservices". Key takeaways from the talk included: the 'Inverse Conway Maneuver' can be a useful tool to shape a software application's architecture during a migration away from a monolith, but this can lead to creating 'microliths' (mini-monoliths) unless the 'transaction cost' of creating a new service is lowered to below the cost of adding to an existing monolith or service; and while a monolith benefits from 'economies of scope' (e.g. adding new functionality does not require the cost of implementing a new deployment process), microservices benefit from 'economies of scale', and accordingly require the (sometimes upfront) cost of automated processes to support operating at scale.

With a reference to Conway's Law, Calçado, a Director of Product Engineering at DigitalOcean, began his talk by discussing how he has been part of several teams that have migrated away from a monolithic architecture. The 'Inverse Conway Maneuver', as popularised by Thoughtworks (and James Lewis), can be used in an attempt to shape the organisational structure in order to change the corresponding software application architect - typically towards smaller services, i.e. 'microservices'. However, working successfully with microservices requires an up-front investment to support deployment and cross-cutting concerns, and over time working with these smaller services can become unwieldy if care isn't taken.

Borrowing some tools of thinking from the business management space, Calçado quoted R. H. Coase's "The Nature of the Firm" (PDF link), providing the analogies of 'firms' to a monolithic application, and 'free agents' to microservices:

Firms exist when the transaction cost of doing something within the firm, even with all of its overhead, is lower than the cost of doing things through a marketplace of free agents.

 

[...this works well until] the costs of organising an extra transaction within the firm become equal to the cost of carrying out the same transaction by means of an exchange on the open market or the costs of organising another firm.

When an organisation begins to migrate towards a microservices architecture, at first the 'transaction cost' of just adding functionality to the monolith is relatively low in comparison with creating an entire new service (and all of the associated delivery mechanics). The Inverse Conway Maneuver attempts to make the transaction cost of adding to the monolith higher than creating a new service, but Calçado proposed that a better approach is to reduce the costs of creating a service below that of simply adding to the monolith or an existing service. 

Reduce the transaction cost of adding a new service

Constantly adding functionality inappropriately to an existing microservice can lead to the creation of 'microliths', which are in effect small monoliths.

Making the 'wrong' thing harder is ok at the beginning, but making the 'right' thing easier is what takes you to excellence.

The next section of the talk looked at unpacking the transaction cost for microservices, and referencing Martin Fowler's Microservices Prerequisites' Calçado proposed adding four additional prerequisites based on his experience:

  1. Rapid provisioning (Fowler)
  2. Basic monitoring (Fowler)
  3. Rapid deployment (Fowler)
  4. Easy to provision storage
  5. Access to the Edge, for example, when a new service is exposed to clients it will need access to 'edge' functionality like session data, and also the ability to handle cross cutting perimeter concerns like auditing and rate limiting
  6. Authentication/Authorisation
  7. Standardised Remote Procedure Calls (RPC), for example, by using a microservice chassis like Twitter's Finagle or Netflix's Karyon (now deprecated), or a service mesh like Linkerd or Envoy

Moving back to economics, it was proposed that monoliths benefit from economies of scope, and microservices benefit from economies of scale. For example, once the deployment process is configured for a monolithic application, adding a new feature does not usually incur cost in regards to this. However, with microservices, the creation of a new service usually requires incurring the cost of creating a new deployment script or pipeline. This again relates to the previous point made about reducing 'transaction cost' - the most effective way to reduce the migration overhead of moving to microservices is to reduce the cost of adding a service.

Monoliths benefit from economies of scope

Concluding the talk, the audience was reminded that not all of the approaches to reducing transaction cost need to be known upfront. The primary focus of any business is to add value to customers/users/stakeholders, and in Calçado's experience the typical five steps for a development team undertaking a migration to a microservice system while still generating business value are:

  1. Experimentation - developers experience architectural issues, and experiment with building services external to the monolith.
  2. Checklists and standards - manual processes for creating services are standardised and documented.
  3. Copy and paste - code is copied, for example, to bootstrap a new service.
  4. Libraries and Tools - the code being copied in the previous step is shaped into a composable set of libraries and tools.
  5. Platform - the creation of a microservice ecosystem and all required elements of a supporting platform.

The slides for Phil Calçado's Craft Conf talk "The Economics of Microservices" can be found on SlideShare, and the video can be watched on the Craft Conf 2017 Ustream channel.

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Constantly adding functionality inappropriately to an existing.... by Roland Heimdahl

Probably the key to a lot of bad design. I have something, therefore I "constantly adding functionality inappropriately" instead of building something else. And since I have the functionallity close and easy accessable the mud is forming a ball... a large one.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

1 Discuss

Educational Content

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and dont miss out on content that matters to you

BT