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 email@example.com.
- Cloud Native
- Continuous Testing
- Continuous Integration
- API Testing
- Open API Standard
- Service Contract
- Synchronous Communication
- Asynchronous Communication
- Software Development Engineer in Test (SDET)
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.
Microservice architecture was born from the pitfalls of 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, and Protobuff.
The Microservice 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.
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 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 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.
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:
- Unit tests
- Pre-integration, component level tests that run following every code commit
- Integration tests
- Acceptance tests
- Post production tests
Type of tests can include, depending on availability and phase the following:
- Load, Stress, Soak
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 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.
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.
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 (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/
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 adherence.
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.
There are two types of Service Contracts:
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.
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.
Until recently, synchronous communication was the most common communication pattern, leveraging protocols such as REST, and more recently, gRPC, which is more performance-oriented.
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.
Lately, there has been a strong trend toward asynchronous communication, which further decouples the services.
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.
SDET, also known as Software Development Engineer in Test, is a job role within the Software Testing and Quality Assurance Domain. The term was originally used by Microsoft and then Google with a view of automating mundane and repetitive manual testing tasks.
UP9 is a microservice testing platform for Cloud Native systems that can scale across any number of services. UP9 helps developers prevent software regressions and increase engineering productivity through effortless testing and instant virtualization.
- Understand how services interact with each other with automatic contract discovery.
- Ensure system-wide contract adherence with tests that write themselves.
- Start testing early with test environments as code, automatically mocking all service dependencies.
UP9 offloads the microservice testing workload from developers, giving them precious time back.
You can sign up now for free!
For support, feel free to use any one of the three: