Book Image

Embracing Microservices Design

By : Ovais Mehboob Ahmed Khan, Nabil Siddiqui, Timothy Oleson
Book Image

Embracing Microservices Design

By: Ovais Mehboob Ahmed Khan, Nabil Siddiqui, Timothy Oleson

Overview of this book

Microservices have been widely adopted for designing distributed enterprise apps that are flexible, robust, and fine-grained into services that are independent of each other. There has been a paradigm shift where organizations are now either building new apps on microservices or transforming existing monolithic apps into microservices-based architecture. This book explores the importance of anti-patterns and the need to address flaws in them with alternative practices and patterns. You'll identify common mistakes caused by a lack of understanding when implementing microservices and cover topics such as organizational readiness to adopt microservices, domain-driven design, and resiliency and scalability of microservices. The book further demonstrates the anti-patterns involved in re-platforming brownfield apps and designing distributed data architecture. You’ll also focus on how to avoid communication and deployment pitfalls and understand cross-cutting concerns such as logging, monitoring, and security. Finally, you’ll explore testing pitfalls and establish a framework to address isolation, autonomy, and standardization. By the end of this book, you'll have understood critical mistakes to avoid while building microservices and the right practices to adopt early in the product life cycle to ensure the success of a microservices initiative.
Table of Contents (16 chapters)
1
Section 1: Overview of Microservices, Design, and Architecture Pitfalls
6
Section 2: Overview of Data Design Pitfalls, Communication, and Cross-Cutting Concerns
10
Section 3: Testing Pitfalls and Evaluating Microservices Architecture

Additional factors for modern cloud-native apps

In Beyond the Twelve-Factor App, Kevin Hoffman discussed three additional factors that are important for building cloud-native applications in the modern era. Let's take a look.

API first

In the API first approach, applications are designed with the intent to be consistent and reusable. The API description language helps in providing a contract that dictates the behavior of an API. For example, Swagger provides the tooling for developing APIs with the OpenAPI specification.

Telemetry

In a cloud-native environment, teams have less control over the execution environment. They are dependent on the capabilities provided by the cloud vendor. Installing debuggers and inspectors is not an option, which makes real-time application monitoring and telemetry a challenge. To address telemetry, you need to make sure that you are collecting system/health data, application performance data, and domain-specific data so that you have complete visibility of the system in near real time.

Security

Security is an important pillar of a well-architected cloud-native application. The cloud-native application is built to run in multiple data centers to serve customers across the globe. They need to ensure that the clients accessing these applications are authenticated and authorized. These applications should identify every requestor and grant access based on their roles. At times, these requests are encrypted using Transport Layer Security (TLS) to ensure data privacy while data is in transit. Teams also need to think about securing their data at rest with the capabilities available in different storage platforms. As an example, Azure Cosmos DB and an Azure SQL server allow us to encrypt data at rest.

The preceding 12 factors and the three additional factors we've looked at here have given us a thorough understanding of building cloud-native microservices with an API first mindset. In the cloud-native world, security and telemetry are no longer an afterthought. Approaching security with a zero-trust mindset is essential, while continuously collecting data to monitor system health gives you the ability to make the necessary adjustments to achieve higher availability for the systems.