Creating your microservices REST endpoint

Microservices are a frequent topic these days because they promise to help reduce the impact of complex problems in a services oriented architecture.

If we skip through the whole story around architecture, devops and what's good for world, we often arrive at a few architecture and design decisions that need to be thought through to implement services, and in particular, micro-services.

Operation Instrumentation

One of the areas is around operational instrumentation, monitoring and management. Microservices need to be instrumented with counters and other measurement methods to allow devops to monitor the microservice. Counting how many rest calls, how long they took and other such measurements are also needed to help implement throttling and SLAs, if those are important to your microservice. Common libraries for this include:

• metrics
• finagle (includes metrics but is also a library with reactive, service development support)
• qbit (includes metrics but like finagle, is also a library with reactive, service development support)

and various ways to aggregate microservice metrics such is a a statsd server. You can then visualize the processing via graphite or gangala. New companies are pushing to be a SaaS or on-prem solution, such as AppDynamics.

Interestingly enough, the instrumentation concept is very similar to that of trying to measure mobile device activities. For example, in order to obtain front end UI application insight into usage behavior, you instrument your javascript so that when a page is loaded or a view changed, a counter is incremented. In many cases, that counter is sent to a receiving server and put into a nice dashboard. Adobe (analytics), google (analytics) and Microsoft have mobile management software stacks and capabilities to do exactly this. Overall though, its really quite basic functionality.

Endpoint

The other area that needs to be thought through is your REST (or SOAP) endpoint. Today, with lambda architectures being the rage, you need endpoints that can plug into a variety of different backends to support batch and real-time processing.

Choices for the endpoint are varied and include:

• akka rest & streams
• spray.io (which is really built on akka)
• finagle
• play
• finch (on top of finagle)
• remotely (see one of the scala talks)
• scalaz-streams
• qbit
• netty, grizly and a bunch of other lower-level plumbing libraries
• ...anything else that can mimic an HTTP server...

You really only need to have support to create an HTTP server and process HTTP requests. In some cases the microservice will directly access a database or create a message to send to a kafka queue or some other clever messaging architecture.

The entry point into your environment may be an API gateway, similar to the one that Amazon (AWS) provides or a load balancer system that has some routing smarts or even a combination of the two for large enterprises (a load balancer/proxy that proxies out to an API gateway). Note that a load balancer may need access to operation metrics to do a good job. 

Load balancers and API gateways include:

• HAProxy (general purpose load balancer)
• tyk (API gateway)
• strongloop (API gateway)
• LoopBack (API gateway built on node.js)
• nginx (can do both but is not full featured for everything)
• apache httpd (see nginx's note)
• openrepose (throttling, monitoring)
• Amazon's API Gateway & Microsoft's Azure service of the same (managed service)
• ...custom...you can take an endpoint solution and build a simple load balancer/api gateway...(custom)

There is a big list of software packages, mostly opensource, listed on microservices list of stuff on gihtub.

Note: My software package examples are a bit scala and JVM biased. As you would expect, the Microsoft Azure cloud PaaS also has equivalent functionality.