Styles of Microservices

You’ve heard that microservices allow development teams to use any language - how do you start? What is a microservice, really, anyway?

There’ve been tweets of microservices, emphasizing that they’re very short in code length and speedy to write, but is that really all they are, just a short bit of code?

Here’s an example using groovy with Pivotal’s Spring Boot:

@Grab("spring-boot-actuator")
@RestController
class GreetingsController {
        @RequestMapping("/hi/{name}")
        def hi(@PathVariable String name) {
                [greeting: "Hi, " + name + "!"]
        }
}

The magic of microservices comes from the microservices infrastructure that’s around the “short” bit of code. In the example above, there’s groovy which sits on a jvm, but before it gets there, there’s maven projects providing all the annotation support, and the spring-boot-actuator which provides very useful convention-based endpoints for /trace, /metrics, and /info allowing monitoring of a service.

Although that’s a few lines of code to stand up a service with some known API endpoints, but it’s still not enough for a microservice.

A microservices infrastructure provides the devops team (the code developer, tester and deployer) a suite of functionality, typically also implemented in a microservices architecture style. Microservices development also assumes that the microservice manages it’s own access to other services and can deal with failure very well. Further, a microservice may have multiple copies deployed, to ensure against all sorts of distributed service latencies or failures.

Components of a microservices infrastructure include:

a registry
a library for providing convention-based endpoints for intercommunication (a regular API)
a library for fault tolerance / resiliancy patterns
a library for client-side load balancing
a health and resiliency monitoring library
a library for autogenerating access to other microservices
a library to allow proxy access for other microservices the microservice may want to expose

These libraries can be implemented via annotations in Java, as as spring-boot-actuator does for a regular API, above, or as actual libraries included in the source of the microservice. The management of libraries via maven or some other mechanism is outside the scope of microservices - that’s a traditional dependency management issue.

Patterns to Date

Code Generation: Pivotal’s Spring Boot & Spring Cloud wrap groovy or java with their annotations is an example of this.
Agent-Container: IBM, in this paper (slides), describes an agent infrastructure that’s added to a standard container. I like to call this heavy dependency “macroservices.”
Platform: A microservices “platform” - a small environment that includes all the prerequisite dependencies (libraries, etc.) that the core microservice can use. Different from an agent-container, this platform is the fabric on which a microservice is deployed. Scaling and distribution of the platform become an issue. Pivotal, again, is moving this direction with Cloud Foundry.