Monday, May 11, 2015

Pico Services in Go

Peter Bourgon (@peterbourgon) spoke at FOSDEM 2015(video) on the subject of "Go in the modern enterprise". Much of what he described as the weakness of Go he called as examples of structured services. As Peter dives deeper into the description he makes the point but misses the implications.

Peter's definition of structured services fits into what I call dimensional systems or Mandelbrot dimension. It's where the implementation details of the service scale as the dimensional power is applied. And, the actual realization of this exact system of services is found in two places. (a) flow based programming (b) go's generator.

In the case of go's generator, Quinn Slack of SourceGraph, presented at Google I/O 2014 (video). He made a strong case for a number of useful Go patterns. The strongest was the AST and go generate. In particular he talked about wrapping all of the "service" APIs with authentication APIs.

I was introduced to flow based programming after watching some of the flowhub and NoFlow  kickstarter videos and supporting documentation. Later I implemented a similar framework in Go which functioned well but was incomplete as it put a hard burden on the framework which is now better implemented in the ast+generate tools.

One anti pattern for structured services is that the smallest hello world, in Go, is still about 8M. And as you start registering services with whatever discovery services, or virtual SOA buss, the challenges multiply.
  • zero downtime green/blue graceful deploy
  • idempotent transactions
  • audit-able call stack
  • distributed transaction services
UPDATE: The network/buss is still a very expensive operation.

UPDATE:  I've traded a number of tweets with Peter and one thing I discovered that I failed to describe here... the smaller a microservice gets there is a proportionate increase in the cost of servicing it. For example, monitoring a service has cost c. If you divide the service into n smaller services then the cost increases to (n x c). The burden might be multiplied many times over as n is distributed across other subsystems and services.

No comments:

Post a Comment

another bad day for open source

One of the hallmarks of a good open source project is just how complicated it is to install, configure and maintain. Happily gitlab and the ...