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
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.
No comments:
Post a Comment