Section 1: Overview of Microservices, Design, and Architecture Pitfalls
In this section, you'll learn about the fundamentals of microservices, the importance of domain-driven design, architecture pitfalls, and the decomposition strategy. This section comprises the following chapters:
- Chapter 1, Setting Up Your Mindset for Microservices Endeavor
- Chapter 2, Failing to Understand the Role of DDD
- Chapter 3, Microservices Architecture Pitfalls
- Chapter 4, Keeping the Replatforming of Brownfield Applications Trivial
Chapter 1: Setting Up Your Mindset for a Microservices Endeavor
Microservices is an architectural style that structures an application into multiple services that encapsulate business capabilities. These microservices are usually much smaller, both in terms of scope and functionality, compared to traditional services. They have logical and physical separation, and they communicate with each other via messages over a network to form an application.
Adopting the microservice architecture is a journey that requires a mindset that can embrace changes in culture, processes, and practices. In essence, organizations need to go through several changes to increase agility and adaptability to achieve their goals and deliver business value.
In this chapter, we will help you understand the philosophy of microservices and the various aspects that help organizations with their digital transformation. We will also learn about microservice design principles and their components, along with their benefits and challenges. Finally, we will discuss the role of leadership and how to get started by adopting widely accepted practices in the industry.
The following topics will be covered in this chapter:
- Philosophy of microservices
- Microservice design principles
- Building teams to deliver business value faster
- Benefits of microservices
- Challenges of microservices
- Microservice architecture components
- Reviewing leadership responsibilities
- Defining core priorities for a business
- Using the twelve-factor app methodology
- Additional factors for modern cloud-native apps
This chapter aims to help you understand the key concepts of microservices and their potential for bringing change that can fuel business growth for organizations. In addition, we will discuss the role of leadership in shifting the mindset by building effective teams that embrace change to deliver business value faster. Finally, we will dive into the "Twelve-Factor App" methodology, which has helped many organizations in their successful adoption of microservices.
Philosophy of microservices
The digital revolution is disrupting every industry to fulfill the unmet demands of its users and embrace digital transformation to transform their current businesses. Digital transformation allows businesses to adapt quickly to the changing business conditions and create value for their end users. Digital transformation is about empowering your employees, engaging your customers, transforming products, and optimizing operations. The essence of digital transformation is in a growth mindset, where organizations invest in improving their internal capabilities, processes, and systems to bring change that drives business and societal outcomes. Many of these systems are due for a change that would enable them to innovate at a rapid pace and reimagine the future to deliver exciting experiences. In the last few decades, most of these systems were built using a monolithic architecture, which is relatively difficult to change and maintain as it grows and becomes complex. Though the Service-oriented architecture (SOA) was a major improvement over the monolithic architecture, it has its own challenges, such as when the application grows, it becomes a distributed monolithic application, which is again difficult to maintain or extend. The focus of SOA is more on reusability and integration, where services constantly exchange messages in return for tasks to be executed. The messaging platform is the backbone of SOA and is responsible for service discovery, orchestration, routing, message transformation, message enrichment, security, and transaction management. The major downside of SOA is that the information is shared and knowledge of the business domain is scattered across the Enterprise Service Bus (ESB), which makes it difficult to change the service.
Microservices is an evolution of the architecture style that addresses the pain points of other architecture styles to enable rapid change and scale. Microservices also enable continuous delivery of business capabilities. The effort of concentrating on and segregating business capabilities from each other in individual services enables organizations to build systems that are modular, isolated, and loosely coupled in nature. These characteristics play a crucial role in helping organizations build dedicated teams that are focused on delivering engineering velocity. Teams are isolated to develop and deploy microservices independently, without any major collaboration required. However, if there are dependencies between services and the services haven't been modeled properly, they undergo extensive collaboration, violating the isolation as a benefit. The microservice architecture also enables organizations to build services with autonomy that embraces change and lowers the risk of failures because of service independence.
Microservices have changed the application development paradigm, where new fundamentals have surfaced and are successful at building and operationalizing microservices. Organizations need to start with the right mindset and build a culture of ownership across small teams to continuously deliver value to their end users.
Now that you have a basic understanding of the philosophy behind microservices, next, we will go through microservice design principles.
Microservice design principles
In the quest of building microservices, you will have to make several choices that will give a different flavor to your microservice architecture and its evolution over time. Microservice design principles provide the guidelines for evaluating key decisions that can affect the design of your microservice-based architecture. In principle, microservices support loose coupling and the modularity of services. Other principles can govern the design of a microservice architecture, but their importance can vary. We will cover those principles in the following sections.
Single responsibility principle and domain-driven design
A microservice should be responsible for offering a single feature or a group of related features to deliver a business capability. The only reason why a microservice interface should change is due to changes in the business capabilities offered by the microservice. This helps systems to be designed following the real-world domains and helps us visualize systems and architectures as a translation of real-world problems. Domain-driven design is an approach that helps with domain modeling and defining microservice boundaries, which helps us achieve modularity and reduces coupling.
Encapsulation and interface segregation
Each microservice owns its data, and the only way a service can communicate with other services is through well-defined interfaces. These interfaces are carefully designed by keeping their clients in mind. Rather than overloading microservice endpoints in client applications, a popular alternative is to introduce an API gateway, which will be explained later in the chapter. This technique is useful in delegating the communication responsibility to API gateways and keeping microservices focused on delivering business capabilities.
Culture of autonomy, ownership, and shared governance
The microservice architecture allows business capabilities owned by different teams to be delivered. These teams can work independently without requiring much collaboration across teams. Each team doesn't need to be assigned a single business capability; instead, they may choose from a related set of capabilities that belong to a single domain. The microservice architecture flourishes when you allow teams to have autonomy, since they can choose what they think is right to deliver the desired business capability. This doesn't mean that teams can do anything, though, but it certainly gives them the freedom to make decisions under an umbrella of formally agreed principles. These principles are called shared governance, which provides consensus across the teams regarding how they want to address different cross-...
