Introduction

The cornerstone of all wit products, this is a suite of serverless microservices, providing a common set of services across all wit products including, but not limited to, licensing & subscription, authentication & authorisation, application updates/upgrades, notifications, billing, payments, account management, registration, user management and device management, in addition to federating access to 3rd party services, such as, transport, news & weather.

Serverless Microservices

Serverless in deployment allowing to accommodate any dynamic load scenario as demand requires. Cloud Provider Agnostic - AWS, Azure, GCP and/or public/private cloud Kubernetes deployment.

Fine grained Microservices, allowing for fine scaling by function, isolation between function and benefitting from the best use of technologies specific to that function. WOZiTech promotes node.js and MongoDB, but being tech agnostic and having a experience in a large number of tech, WOZiTech will not shy away from say a "C#.net/SQLserver" microservice if that is more relevant for the task at hand.

Secure From Ground Up

Token-based API security built in from the ground up. Not just authentication, but authorisation too through client ids, audiences and claims. Auth0 is preferred by WOZitech, as the industry leading provider of security as a platform, supporting extensive set of Identity Management scenarios including, but not limited to, social media (Facebook, github, google, Twitter), native client (Microsoft, Android, iPhone), SPA web applications and significantly here, APIs.

All environments, except local development, enforce TLS (SSL) encryption to secure data in transit, passing JWT in the HTTP Authorization header.

API Gateway

wit-serve itself is the gateway to the wit set of microservices, providing federated access across all discovered services including logging, profiling and, where necessary, caching.

API namespace is important; accessing microservices by portable URIs, across multiple environments. A microservice must be resolvable by URI and RESTful actions (GET, POST, DELETE, PUT) upon that URI.

Although microservices can be platform agnostic, all wit microservices are deployed to the AWS platform. This however has little sigificance, because as an API gateway, the deployment of wit-serve only is significant; all wit microservices, although individually directly accessible are accessed via this gateway. Consequently only one root domain is required for the namespace to resolve wit-serve microservices.

But separate namespaces are required for each environment. To allow for common TLS (SSL) certificates to secure transport, the environment namespace must derive from a common namespace. All wit microservices can be consumed by any wit product.

The namespace used for wit microservices will follow this pattern:

[http|https]://<environment>.api.wit.wozitech.click/<service name>
It is noted that by including the environment within the root namespace, each environment 'can' itself be deployed to separate cloud providers; for example, production to AWS, acceptance to Azure and regression to GCP. All that is required is a little cleverness to manage the sub-domains across cloud providers.

Different client platforms have different API interaction needs. An SPA web application will invoke an microservice API differently to that of an Android client application. wit-serve is the 'Backend for the Frontend' providing facades to deliver the API more efficiently.

As a gateway, wit-serve will employ good microservice patterns to ensure API availability, including, but not limited to, circuit breaking and failover.

Local Development and Test

Develop and run functions locally to speed development and use best practice unit and integration tests.

Local deployment allows simple and effective development/testing of client applications & services that depend on these functions. But rather the developer having to create individual test environments with each dependable function then deployed and consequently configure their client accordingly, all wit-serve functions can be deployed to a local APIGW (nest.js single instance). Alternatively, a wit-serve Docker image using 'localstack'.

Showcase

Showcasing in this project is:

  • Lambda Framework - despite its name, this is a Javascript API for abstracting serverless web applications for any provider (common cloud or custom).
  • middy - lightweight middleware engine for AWS Lambda functions.
  • pact.io - consumer driven contract test tool.
  • Kong - the modern day API Gateway, along with Docker Kong = a Docker runable image of Kong (requires external Cassandra/PostgreSQL instance).
  • AWS APIGW - industry leading serverless technology from AWS to expose lambda functions.
  • AWS Lambda - industry leading serverless technology from AWS.
  • AWS Step Functions - Orchestrating AWS Lambda.
  • kubeless - Kubernetes answer to serverless functions.
  • Azure Functions - Microsoft"s answer to serverless functions.
  • GCP Functions - Google"s answer to serverless functions.
  • localstack - A fully functional local AWS cloud stack, but more specifically localstack docker - a runable docker image.
  • nest.js - node.js framework brokering local (test) access to functions by client services.
  • Auth0 - never compromise on Identity; security from the ground up across all services.
  • Serverless Framework - open source agnostic serverless development and deployment. And following on from this, introducing: