Bespoke Systems - custom analyses

Styles of Microservices

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:

class GreetingsController {
        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:

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