What Are Microservices Really All About? (And When Not To Use It)

Summary

The video script delves into microservices architecture, highlighting its benefits for large teams in building scalable applications with loosely coupled services. It explains the independent deployment, scalability, and communication methods of microservices, such as RPC and event streaming. The script also addresses challenges like maintaining data integrity and the necessity of components like API gateways and service registries. It concludes by discussing the suitability of microservices for large teams and the importance of well-defined interfaces for potential future adoption by startups.

Takeaways

• 🔌 Microservices architecture allows for the development of scalable applications through many loosely coupled services.
• 🛠 Each microservice in the architecture has a dedicated function, such as shopping cart, billing, or user profile management, and is considered a separate domain.
• 🔗 Microservices communicate through well-defined interfaces with small surface areas to limit the impact of failures and defects.
• 🚀 They can use remote procedure calls (RPC), event streaming, or message brokers for communication, each with its advantages and drawbacks.
• 🚦 Microservices can be independently deployed, providing operators with confidence and flexibility in frequent deployments.
• ⚖️ The architecture offers operational flexibility to scale individual services independently, which is highly valuable.
• 🔒 Well-architected microservices practice strong information hiding, often involving breaking up monolithic databases into logical components.
• 🗃️ One challenge with microservices is maintaining data integrity without the traditional database foreign key relationships and referential integrity.
• 🚪 A key component of microservices architecture is the API gateway, which routes incoming requests to the appropriate microservices after authentication.
• 📍 The API gateway uses a service registry and discovery service to locate and route to microservices, which must register and discover each other's locations.
• 🛑 Additional components like monitoring, alerting, and DevOps tools are essential for the successful implementation of microservices architecture.
• 💡 Microservices architecture is most beneficial for large teams, enabling team independence and fast movement with contained failure impacts, but may not be suitable for small startups due to the overhead involved.

Q & A

What is the main advantage of using microservices architecture for large teams?

Microservices architecture allows large teams to build scalable applications by decomposing them into many loosely coupled services, which enhances team independence and allows each team to work on their respective domains with agility and reduced risk of widespread failures.

How are microservices defined in the context of an application?

Microservices are individual components of an application that handle dedicated functions, such as shopping cart, billing, user profile, and push notifications. They operate independently and communicate with each other through well-defined interfaces.

What is the significance of having small surface areas in the interfaces of microservices?

Small surface areas in microservices interfaces limit the impact of failures and defects, making it easier to understand and manage the interactions between services within the larger application context.

How do microservices communicate with each other?

Microservices communicate through a combination of remote procedure calls (RPC), event streaming, or message brokers, each offering different trade-offs in terms of response time and isolation.

What is the impact of using RPC for communication between microservices?

RPC, such as gRPC, provides faster response times but has a larger blast radius, meaning if a service goes down, it can have a more significant impact on other services.

Why is it beneficial for microservices to be independently deployable?

Independent deployment of microservices allows for more frequent and confident releases, as each service is smaller and has a limited impact area, reducing the risk associated with deployment.

What operational flexibility does microservices architecture provide?

Microservices architecture offers the flexibility to scale individual services independently based on demand, which is invaluable for optimizing resource usage and application performance.

Why is strong information hiding important in well-architected microservices?

Strong information hiding in microservices helps to encapsulate the logical components within each service, promoting better modularity and reducing dependencies between services.

What are the implications of breaking up a monolithic database into logical components for microservices?

Breaking up a monolithic database into logical components for microservices means that foreign key relationships and referential integrity can no longer be enforced at the database level, shifting the responsibility of maintaining data integrity to the application layer.

What role does an API gateway play in a microservices architecture?

An API gateway in a microservices architecture handles incoming requests, routes them to the appropriate microservices, and relies on an identity provider for authentication and authorization of requests.

Why is a service registry and discovery service important for microservices?

A service registry and discovery service is crucial for microservices to locate and communicate with each other, allowing the API gateway to route requests and services to discover each other's locations.

When is microservices architecture most suitable for implementation?

Microservices architecture is most suitable for large teams with the resources to manage its complexity. It enables team independence and rapid development but may not be ideal for small startups due to the overhead involved.

What advice is given to startups considering the adoption of microservices architecture?

Startups are advised to design each function in the application with a well-defined interface, making it easier to migrate to a microservices architecture if the business and team grow and it becomes more appropriate.

Outlines

00:00

🛠 Microservices Architecture Overview

The script introduces microservices architecture as a scalable solution for large teams to build applications composed of many loosely coupled services. It defines microservices as individual, function-specific components within an application, such as shopping cart, billing, and user profiles, which communicate through well-defined interfaces to limit failure impact. The benefits include ease of reasoning, independent deployment, and the ability to scale services individually. However, it also highlights the challenges of maintaining data integrity without traditional database relationships.

Keywords

💡Microservices architecture

Microservices architecture is a software design pattern where an application is composed of small, independent services that communicate with each other. It is central to the video's theme as it enables scalability and flexibility in large-scale applications. The script uses the concept to discuss how large teams can build applications composed of many loosely coupled services, each handling a specific function.

💡Loosely coupled services

Loosely coupled services are components of a system that interact with each other but are not tightly bound. This concept is key to the script's discussion of microservices, as it allows for easier maintenance and updates of individual services without affecting the entire system, as seen in the example of services like shopping cart, billing, and user profile.

💡Dedicated function

A dedicated function refers to a specific task or responsibility within a system. In the context of the video, each microservice has a dedicated function, which contributes to the overall functionality of the application. This is exemplified by the script's mention of services like push notifications and user profiles, each serving a distinct purpose.

💡Well-defined interfaces

Well-defined interfaces in the script refer to the clear and specific points of interaction between microservices. They are crucial for limiting the impact of failures and ensuring that services can communicate effectively. The script mentions that these interfaces help in making each service easier to understand within the larger application context.

💡Remote Procedure Calls (RPC)

Remote Procedure Calls (RPC) is a protocol used by microservices to communicate with each other. The script discusses RPC, such as gRPC, as a method that provides faster response times but may have a larger impact on other services if one service fails, illustrating the trade-off between speed and fault isolation.

💡Event streaming

Event streaming is a method of communication between microservices where events are pushed to a stream and processed asynchronously. The script contrasts event streaming with RPC, noting that while it offers better isolation between services, it may take longer to process, which is a key consideration in microservices design.

💡Independent deployment

Independent deployment means that each microservice can be deployed separately from the others. The script highlights this as a benefit of microservices architecture, allowing for more frequent and less risky updates to individual services without affecting the entire application.

💡Operational flexibility

Operational flexibility refers to the ability to manage and scale services independently based on demand. The script emphasizes this as a significant advantage of microservices, allowing for individual scaling of services to meet varying loads and requirements.

💡Strong information hiding

Strong information hiding is a principle where microservices keep their internal workings hidden from others, exposing only what is necessary. The script explains that this practice often involves breaking up monolithic databases into logical components that are kept within their respective microservices, enhancing modularity and security.

💡API gateway

An API gateway is a server that acts as an entry point into a system of microservices. The script describes the API gateway's role in handling incoming requests and routing them to the appropriate microservices, relying on a service registry and discovery service to locate the services.

💡Service registry and discovery

A service registry and discovery mechanism is used to keep track of microservices and their locations. The script explains that microservices register with this service to be discoverable, which is essential for the API gateway to route requests correctly.

💡DevOps toolings

DevOps toolings refer to the tools and practices used to enhance collaboration between development and operations teams. The script mentions these tools in the context of microservices architecture, where they are used for deployment, monitoring, and troubleshooting, supporting the continuous integration and delivery process.

Highlights

Microservices architecture allows large teams to build scalable applications composed of loosely coupled services.

Each microservice in a microservices architecture handles a dedicated function within the application, such as shopping cart, billing, or user profile.

Microservices communicate via well-defined interfaces with small surface areas to limit the impact of failures.

Remote procedure calls (RPC) like gRPC provide faster response times but have a larger blast radius when a service fails.

Event streaming offers better isolation between services but may have longer processing times.

Microservices can be independently deployed, providing peace of mind and confidence for frequent deployments.

The architecture allows for the independent scaling of individual microservices, offering operational flexibility.

Well-architected microservices practice strong information hiding, often involving the separation of monolithic databases into logical components.

Breaking up databases in microservices can eliminate foreign key relationships and shift the burden of maintaining data integrity to the application layer.

An API gateway is a key component in microservices architecture, handling incoming requests and routing them to relevant services.

The API gateway relies on an identity provider service for authentication and authorization of requests.

Service registry and discovery services are used by the API gateway to locate and route requests to microservices.

Other components like monitoring, alerting, and DevOps tooling are useful in a microservices architecture for deployment and troubleshooting.

Microservices architecture is cost-intensive and best suited for large teams, enabling team independence and fast movement with contained failure impact.

For startups, designing each function with a well-defined interface can make future migration to microservices architecture more manageable.

The overhead of implementing microservices architecture is significant and may not be suitable for small startups initially.

Resources such as books and a weekly newsletter on system design can provide further insights into microservices and other architectural patterns.

Transcripts

Microservices architecture enables large  teams to build scalable applications that  

are composed of many loosely coupled services.

What does a typical microservices  architecture look like?

And when should we use it?

Let’s take a look.

Microservices are loosely coupled.

Each service handles a dedicated function  inside a large-scale application.

For example, shopping cart, billing, user profile,  

push notifications can all  be individual microservices.

These functional areas are  sometimes called domains.

Microservices communicate with each other via  well-defined interfaces with small surface areas.

The small surface areas limit the  blast radius of failures and defects.

It makes each service easier to reason about  in the context of the entire application.

Microservices talk to one another over a  combination of remote procedure calls (RPC),  

event streaming, or message brokers.

RPC like gRPC provides faster  response, but the blast radius,  

or the impact to other microservices, would  be larger when the service was to go down.

Event streaming provides better isolation  between services but they take longer to process.

Microservices can be independently deployed.

Since each service is small, easier to  reason about, and has a smaller blast radius,  

this gives the operators peace of  mind and confidence to deploy often.

Microservices provide more flexibility to scale  up individual microservices independently.

The operational flexibility is invaluable.

Well-architected microservices  practice strong information hiding.

This often means breaking up a monolithic  database into its logical components and  

keeping each logical component well hidden  inside its corresponding microservice.

By logical component, it could mean  a separate schema within a database  

cluster or an entirely separate physical database.

This is an implementation detail.

However, one big drawback of microservices  is the breaking up of the database.

By breaking up a database into separate  logical units, the database can no longer  

maintain foreign key relationships and enforce  referential integrity between these units.

The burden of maintaining data integrity  is now moved into the application layer.

Let’s take a look at other critical  components required for a successful  

implementation of microservices architecture.

A key component is an API gateway.  

API gateway handles incoming requests and  routes them to the relevant microservices.

The API gateway relies on an identity provider  service to handle the authentication and put  

authorization of each request  coming through the API gateway.

To locate the service to  route an incoming request to,  

the API gateway consults a service  registry and discovery service.

Microservices register with this  service registry and discover the  

location of other microservices  through the discovery service.

There are other useful components  in a microservices architecture like  

monitoring and alerting, DevOps toolings for  deployment, and troubleshooting, for example.

Let’s wrap up by discussing when  to use microservices architecture.

Microservices cost money to build and operate.

It really only makes sense for large teams.

For large teams, it enables team independence.

Each domain, or function, can be  independently maintained by a dedicated team.

In a well-designed microservices architecture,  

these independent teams can move fast, and the  blast radius of failures is well-contained.

Each service could be independently  designed, deployed, and scaled.

However, the overhead of a sound implementation is  

so large that it is usually not  a good fit for small startups.

One advice for startups is to design each function  in the application with a well-defined interface.

One day if the business and team  are growing fast that microservices  

architecture starts to make sense, it  would be more manageable to migrate.

If you would like to learn more about system  design, check out our books and weekly newsletter.

Please subscribe if you learned something new.

Thank you so much, and we’ll see you next time.