Image API Microservices

TL;DR

This article covers microservices implementation using Quarkus: Supersonic Subatomic Java. We look at Quarkus to realize a microservices architecture for a simple image sampling service.

We will list steps to incorporate Quarkus extensions for OpenAPI service definition, REST clients, Eclipse micro profile metrics, Distributed Tracing and Centralized Logging. We also look at creating Docker images for JVM and building native images using GRAAL. The article concludes with deploying services to Docker Compose and Kubernetes.

Show me the code:

Code Description - https://github.com/MalcolmPereira/imageapi

1. Microservices Recap

What ?

Microservices offers a new paradigm for organizing applications when solving problems in a business domain. Microservices are an architectural style for separating concerns of a given domain into isolated independent services each providing concise business value. Services may work independently or invoke other services to meet business objectives, each service aims to provide one business function and do it well.

Why ?

Microservices provides opportunities for businesses to be resilient and agile in an ever competitive market and with incentives to break away from large distributed monoliths. Microservices if implemented correctly will provide the following benefits:

• Highly coherent and loosely coupled services, each service is tasked with one business objective performing it well.

• Services can be owned, managed by smaller teams and can evolve independently while maintaining required business functions it supports. This helps with improved time to market, microservices compliments agile based development methodologies.

• Services can be independently developed, deployed, monitored and scaled.

How ?

Microservices are inherently developed as RESTful services built around RESTful verbs of GET, POST, PUT, DELETE. REST is a proven architectural style that complements microservices for exposing business functions apis as services. OpenAPI specification aids in documenting and describing the exposed services.

Internal inter-service communication may use other RPC technologies like gRPC which can speed up communications using binary data serialization instead of textual (JSON/XML) representations. Many frameworks exists in almost all modern languages supporting REST constructs, this document aims to use Quarkus for realizing java based RESTful services.

… Challenges ?

Yes, like everything else in life there ain't no such thing as a free lunch. Breaking apart monoliths into distributed services bring following challenges:

• Logging and Monitoring : There is no one place to look if things start to break, there are multiple services to monitor and even more components that can fail.

• Tracing : When services depend on other services, how can we trace requests from one service to another and determine end to end how a given request was processed.

• Reporting : Each service will have its own data store, data is now spread across multiple micro-databases, reporting becomes challenging.

• Service Discovery : How can services find each other or how callers of apis reach services

• Security : Security concerns need to be carefully examined for each service, more attack vectors to defend now that there are many services.

• Increased latency: When services need to work with other services to complete a request, latency will increase due to inter service communications, need to carefully examine inter service dependencies and ways to speed things up.

All of these and others need to be carefully designed for and planned when architecting for microservices.

In the end, many proven solutions exists today that solve these challenges giving microservices an edge that outweigh impediments. Quarkus provides extensions to address these challenges and businesses should not deter from investing in microservices.

2. Quarkus

What ?

Quarkus is a new super fantastic java framework for cloud native stacks, sponsored by RedHat. Quarkus allows to build performant java microservices that are cloud native ready. Quarkus primary built around containers first mindset making for an ideal contender in cloud native stacks. 

Why?

Quarkus is open sourced with strong community support and backing from proven industry leaders. Quarkus extension ecosystem provides commonly used cloud native extensions ready to support use cases in your applications. Quarkus brings developer joy by live reloading of code during development, improving productivity. 

How ?

Quarkus bootstrapping page on quarkus.io is the place to get started. Please see quarkus.io for all great features quarkus has to offer.

We will examine a simple microservice realization using Quarkus and extensions available within the quarkus ecosystem which solve common challenges when developing microservices.

3. Microservice Realization

The basic idea involves separating image processing concerns into independent services. The application allows user to upload and scale an image, list and view images previously scaled.

Not very cutting edge or next level of technology that will solve climate change, none the less good enough for realizing microservices prototyping with Quarkus.

Image API microservices core components:

Image Client:

This is a simple react application that will invoke ImageAPI Service.

ImageAPI Service:

This is the proxy or api gateway for image processing services, this acts as the facade for all other services contained in the architecture. The advantage being, consumers need not know how to invoke individual services or keep track of where these individual services resides or service contracts involved. Consumers are only ever talking to this facade which will internally coordinate with other services.

ImageValidation Service:

This service validates uploaded content to check if it is supported and returns error for invalid content.

ImageThumbnail Service:

This service will scale image based on user selected parameters and return processed image back to user synchronously, service will also write data to a message broker which will be processed by the image storage service asynchronously to save processed image data in its datastore.

Images are upsampled or downsampled using BICUBIC, BILINEAR or NEAREST_NEIGHBOR algorithms supported in Java 2D. (As of this writing Graal Native Image does not support java 2D so native image cannot be created for modules using Java 2D - ImageValidation and ImageThumbnail device.)

RabbitMQ:

Message broker that allows for asynchronous processing of image related data.

ImageStorageService:

This service stores processed image data in PostgreSQL database and allows to view processed data at a later time.

PostgreSQL:

Database to store processed images.

ELK Stack:

ElasticSearch, LogStash and Kibana for Centralized Logging

Jaegar:

Distributed Tracing support by Jaegar Open Tracing Implementation

Basic flow described:

Consumer calls ImageAPI service facade to sample image, service facade coordinates with ImageValidation Service and ImageThumbnail Service to return sampled image synchronously, image data is written to message broker and processed asynchronously by ImageStorage Service to save image data to PostgreSQL datastore.

4. Implementation with Quarkus

As described earlier, microservices pose significant challenges as we break away legacy monoliths to distributed services, Quarkus aids in microservices development by bridging these challenges with the following abilities making for a smoother transition to a resilient implementation.

4.1 Simplicity:

Quarkus makes it very simple and straight forward to quickly get started building java microservices with the bootstrapping page. Configure application details, select extensions as needed and click generate application to download application zip.

Extract application zip file and open in your favorite IDE. The application has a basic scaffolding with all dependencies in place to start building the service.

The codebase is a maven project with regular maven configuration, additional docker folder containing pre-configured docker files and application.properties file which controls application configurations. JBOSS RESTEasy is the backbone supporting restful nature of the application.

Quarkus community has created well documented guides with step by step process for the various tooling and extensions supported in quarkus ecosystem, will refer to these guides as we explore how these are added to the image api service. Run application using provided maven wrapper.

./mvnw quarkus:dev

The quarkus:dev plugin allows for hot code replacement with code updates quickly reloaded within a blink of an eye as you keep coding the application, true developer joy.

4.2 Service Definition:

OpenAPI specification provides a standard way of describing microservices, defining api and contracts they support. The specification can be described in JSON or YAML, latter being more concise without clutter, omitting parenthesis.

Swagger is a well know implementation of OpenAPI specification and SwaggerUI generates UI to describe microservice endpoints, contracts and schema for request and responses and also provision to quickly test the service.

The quarkus quarkus-smallrye-openapi extension provides required facility for describing your services and wrapping it in SwaggerUI which can be published on a known endpoint along with service.

The openapi-swaggerui guide helps to get started using open api in quarkus. Steps for exposing open api service specification are as follows:

1. Add quarkus-smallrye-openapi maven dependency to the project.

2. Document your service following open api specification in JSON or YAML, YAML preferred