[Music] Welcome to "Microservices Patterns and Anti-Patterns.” After watching this video, you will be able to: Describe several patterns you can use with microservices, and explain anti-patterns not to follow when using microservices. Microservices have numerous patterns available that enable more efficient dev-ops. Let's look at several commonly used patterns. With the convergence of more powerful browsers, faster networks, and client-side languages, many web interfaces began to incorporate all functionality into single-page applications. The user enters through one interface that never reloads the landing page or navigates away from that initial experience. Built using a combination of HTML, CSS, and JavaScript, these applications respond to user input through dynamic service calls to backing REST-based services that update portions of the screen instead of redirecting to an entirely new page. This application architecture often simplifies the frontend experience with the tradeoff of more responsibility on the backing services. While a single-page application works well for a single channel user experience, a single page application pattern delivers poor results across user experiences across different channels, like mobile and web. A Backend for Frontend pattern inserts a layer between the user experience and the resources that the experience calls on. For example, an app used on a desktop will have different screen size, display, and performance limits than a mobile device. The BFF pattern allows developers to create and support one backend type per user interface using the best options for that interface, rather than supporting a generic backend that works with any interface, but that potentially negatively impacts front end performance. This diagram illustrates a great use case for a Backend for Frontend application architecture. Say that a user can access an application via a mobile app or a web application on your desktop. Using a BFF pattern, you develop a backend specifically for the mobile experience and another backend specifically for the web experience. Each backend knows how to call the correct services and orchestrate code to optimize the requested channel's experience. The mobile app might display a more limited subset of data, and the screen sizes are different from the web experience. Each backend is a microservice. Instead of having a monolithic app that checks which channel is needed and then contains all the logic to prepare the user experience for that channel, you apply microservice architecture to separate the monolithic backend into distinct services that perform their specific, necessary tasks. The Strangler pattern helps manage the refactoring of a monolithic application in stages. The pattern gets its metaphorical name from the garden phenomenon of a vine that strangles a tree. Think of a web application built using individual URLs that map functionally to different aspects of a business domain. With the Strangler pattern, you use the structure of a web application to split an application into multiple functional domains and replace those domains with a new microservices-based implementation for one domain at a time. These two aspects form separate applications that exist side-by-side in the same URL space. Over time, the newly refactored application replaces the original application until finally, you can shut off the monolithic application. The Strangler Pattern includes these steps: First, transform. Create a parallel new site on a cloud platform or within your existing environment. Next, coexist. Leave the existing site functional and live for a specified time. Incrementally redirect from the current location to the new site for newly implemented functionality. Finally, eliminate. Remove the outdated functionality from the existing site, or simply stop maintaining that functionality when you redirect traffic from the original site. Numerous patterns are available that help address some of the more common challenges and opportunities associated with transitioning to and using microservices. Learning more about recommended microservice patterns is worthwhile. While there are many patterns for creating effective microservices, there are an equally significant number of patterns that can quickly get any development team into trouble. Next, learn about these anti-patterns, also referred to as microservices "dont’s." The first rule of microservices is, don't build microservices. Stated more accurately, don't start with microservices. Microservices are ideal for managing application complexity when the applications are too large and unwieldy to update and maintain easily. When you determine that the monolithic application's complexity negatively affects application development and maintenance, consider refactoring that application into smaller services. Always use microservices with DevOps or cloud services. Building out microservices means building out distributed systems, and distributed systems can be difficult and time-consuming. Implementing microservices without proper deployment and monitoring, automation, or managed cloud services that support your now sprawling, heterogenous application infrastructure creates numerous, unnecessary complications. Avoid implementing too many microservices by making those microservices too small. If you go too far with implementing the "micro" in microservices, you can easily find yourself with development overhead and complexity that outweighs the overall gains. It's better to lean toward larger services and then only break them apart when they start to develop characteristics that microservices solve. Break apart larger services when deploying changes becomes complicated and slow, the common data model is overly complex, or when parts of the service have differing load and scale requirements. In this video, you learned that: Microservices enable single-page applications that rely on backing services to update the page dynamically, backend for frontend patterns use microservices to facilitate different user experiences more easily, apply the Strangler pattern to help break up monolithic apps into microservices, only use microservices when needed, use microservices with DevOps and Cloud services, and build microservices to the right size and not overly small.
