Microservices Glossary This Glossary is a live list of terms intended to assist those new to the microservices space to better understand the day to day terminology. The definitions represent the meanings understood and shared by the majority of the developer community. If you would like to add a submission, please email info@up9.com.

Terms

Monolith

Monolith

The Monolithic architecture is a software architecture that encompasses the entire application business-logic in a single large codebase.

Although it's considered the traditional (and sometimes the less advised) strategy, the Monolithic architecture holds many benefits and may well be the right choice for some engineering teams.

You can read more about the pros and cons of a Monolithic architecture here.

Microservices

Microservices

Microservice architecture was born from the pitfalls of the Monolithic architecture.

Microservices - also known as the Microservice architecture - is an architectural style that structures a system as a federation of a relatively high number of services that are usually smaller in size, highly maintainable, testable, loosely coupled and independently deployable.

Each service is organized around a well defined business-logic, they are often located on different machines and communicate via either synchronous and/or asynchronous messaging, based on protocols such as REST, gRPC, Protobuff and the like.

Microservice gRPC, REST

The Microservic architecture enables the rapid, frequent and reliable delivery of large, complex applications as well as independent roadmaps and deployment schedules.

You can read more about the pros and cons of a Microservice architecture here.

Service Oriented Architecture (SOA)

SOA

SOA, although a different style of software architecture than the Monolithic architecture, is very closely related. One can consider SOA the duplication of the Monolith across a handful of services. SOA is usually the first step when breaking away from the Monolith en-route to a Microservice architecture.

While there are differences between the two styles, it is the author's opinion that they do not merit a deep discussion. When we reference a Monolithic architecture style in this article, we also include SOA and sometimes will use both interchangeably.

You can read more about SOA Vs Microservice architecture here.

Cloud Native

Cloud Native is used to describe container-based environments such as Kubernetes or Docker. Developers use them to build and run applications with services packaged in containers and then deployed as Microservices through agile DevOps processes and continuous delivery workflows whether on-premise or on the public or private cloud.

Continuous Testing

Built on the premise of having developers testing software often, and in every phase of the software life cycle. Continuous Testing entails the automation of the following testing activities:

  1. Unit tests
  2. Pre-integration, component level tests that run following every code commit
  3. Integration tests
  4. Acceptance tests
  5. Post production tests

Type of tests can include, depending on availability and phase the following:

  1. Functional
  2. Regression
  3. Performance
  4. Load, Stress, Soak
  5. Security

Continuous Testing is often part of Continuous Integration/Delivery. It is used to identify failures early in the life cycle, allowing engineering teams time to prevent them from reaching production

Continuous Integration1

Continuous Integration (aka CI) is the automation of code change integration from multiple developers and merging the various code changes into a single repository multiple times a day. Changes are then reviewed by an automated build, detecting potential issues early for fixes, before they potentially break in production environments.

API Testing2

Performed to assess the functionality, reliability, performance, and security of the programming interfaces. Software is used to send calls to the API, get output, and monitor the system's response. API tests generally focus on the business logic layer of software architecture.

gRPC3

A modern open source high performance RPC framework that can run in any environment. It can efficiently connect services in and across data centers with pluggable support for load balancing, tracing, health checking and authentication. It is also applicable in last mile of distributed computing to connect devices, mobile applications and browsers to backend services.

Open API Standard

Open API Standard (aka OAS) is a vendor neutral open API description specifications, which standardizes how REST APIs are described. You can read more about OAS here: https://www.openapis.org/

Service Contract

At the heart of Contract Testing lies the Service Contract. A Service Contract (Contract) usually belongs to a Provider and lists all the methods a Consumer can interact with the Provider. Interactions result in data returned or actions performed.

To make Contract Testing useful, every service should have an up-to-date Contract. The service owner should publish this Contract at all times for two main reasons:

  • So Consumers can derive their Contract variants and build their code with the Consumer context in mind.
  • So Providers can avoid software regressions by ensuring Contract compliance.

In the case of synchronous communication, the Contract is likely to list the service endpoints used to interact with the Provider, while in the asynchronous case, it will likely include the message schema.

While there is no clear guidance of how to represent a Contract, OpenAPI specifications (with its friendly name, Swagger) is a popular choice.

Contract-Sample

There are two types of Service Contracts:

Provider Contract

The Provider Contract includes a comprehensive list of methods guiding Consumers as to how to interact with the Provider, with no specific Consumer in context.

The Provider Contract is published by the Provider with the promise to adhere to the Contract. Consumers can derive a variant of the Provider Contract for their own usage and context.

Consumer Contract

A Consumer Contract represents the agreement a certain Consumer has with a Provider. The Consumer Contract is a variant of the Provider Contract for use by a specific Consumer, and therefore includes only a subset of the Provider Contract.

The Consumer Contract usually provides a better understanding of how the Consumer can interact with the Provider as well as mock the Provider for testing purposes.

Synchronous Communication

Until recently, synchronous communication was the most common communication pattern, leveraging protocols such as REST, and more recently, gRPC, which is more performance-oriented.

Rest and gRPC

Synchronous communication includes request/response transactions, where the response immediately follows the request. An upstream service will usually wait for incoming requests using an agreed-upon communication protocol (e.g REST or gRPC), and will then return a response including either data or the status of an action.

Asynchronous Communication

Lately, there has been a strong trend toward asynchronous communication, which further decouples the services.

Kafka

Asynchronous communication includes reading and writing messages to a message bus. A Provider will usually post (write) a message to a message bus (e.g. Kafka) that will be consumed (read) by Consumers.

ABOUT UP9

UP9 provides an out-of-the-box test automation for microservices, kubernetes and cloud-native systems, replacing the need for developers to constantly build and maintain tests, while providing comprehensive service test-coverage.

Features:

  • Automatic generation and maintenance of CI-ready test-code, based on service traffic.
  • Observability into API-contracts, business-logic and service architecture.
  • Automatic reliability, test-coverage and root-cause analysis.
  • Machine generated tests include functional, regression, performance and edge-case test-cases, covering all services and all service-endpoints.

UP9 offloads the microservice testing workload from developers, giving them precious time back.

References: