[MUSIC] Hello, I'm Mahendra Mehra and I welcome you to this lesson on design methodology of microservices. In our previous lesson, we discussed how microservices architecture is a better approach over moonlit approach to application development. The question is how do you pull it off? One matter which is extremely beneficial is the 12 factor app methodology. It was created by developers at Hiroko back in 2011. So let's get started. The 12 factor methodology is a set of 12 best practices to develop applications, which are supposed to run as a service. 12 factor app principles got very popular as it alliance with the microservices principle. Let's look at each of them. The first one is code based. This principle states that an app should be tracked in a single code repository and must not share the repository with any other application. Usually in microservices, every services have their own codebase, and having an independent code base helps you too easy the process for your applications. The next one is dependencies. All the application packages should be managed through package managers like sbd Maven or griddle. For example, Maven requires us to describe a project dependencies in an xml file typically known as project object model or palm. Again in a non containerized environment, you can go for configuration management tools like chef and Sibyl etc. To install the system level dependencies, but for a containerized environment you can always go for a docker file. Configuration. Configuration says that you must externalize the configurations from the application. All the configuration data should be stored separately from the code, in the environment as variables and not in the code repository and should be reddened by the code at runtime. Having a separate conflict file makes it easy to update the conflict values without touching the actual board base. Thus eliminating the need for redeploying applications when the conflict values are changed. You can use configuration management tools like an Sybil or chef to automate this process. Backing services. The 12 factor app can automatically swap the application from one provider to another without making any further modifications to the codebase. Let us say you would like to change the database server from your own promises my SQL two OC database cloud service. To do so you should not make any code changes to your application only configuration change should be able to take care of it. Build, release and run, strictly separate the build and run stages is what this factor promotes. You can use the tools to automate the bills and deployment process, DR images, make it easy to separate the build, release and run stages more efficiently. Images should be created from every commit and treated as a deployment artifact. Processes by adopting the stateless nature of rest your services can be horizontally scaled as per the needs with zero impact. If your system still requires to maintain the state, you can use resources like readies ma'am cage or data store to store the state instead of in memory. Never assume that any case in memory or on disk will be available during the future request or job. Court binding, application should be self contained instead of deploying them into any of the external web service. To make the port binding factor more useful for microservices, you must allow access to the persistent data owned by a service only by the way of service A P E. This prevents implicit service contracts between microservices. Concurrency. This principle advocates to obtain for horizontal scaling instead of vertical scaling. The vertical scaling requires adding additional hardware to the system. Horizontal scaling works by adding additional instances of the application. In microservices architecture adopting the containerization applications can be scaled urgently as per the demand. Disposability, the system should not get impacted when new instances are added or existing ones are taken down. This is known as system disposability systems do crash due to various reasons. The system should ensure that the impact would be minimal and the applications should be stored in a valid state. Services deployed in docker containers do this automatically, as it's an inherent feature of containers that they can be stopped and started instantly. Development and production parity. You must always keep the development, staging and production as similar as possible to avoid the risk of bugs showing up in the later stages of your software development lifecycle. Containers work well for this as they enable you to run the exact same execution environment all the way from local development through the production. Logs become paramount in troubleshooting the production issues are understanding the user behavior, law provides visibility into behavior of a running application. Logs should be streamed to a chosen location rather than dumping them into a log file. Observe ability and monitoring help you achieve this in a microservices based architecture, which we will be also covering in our later modules. Admin processes, the idea here is to separate the administrative task from the rest of the app to prevent one of tasks from causing issues with your running applications. For example, doing data cleanup, running analytics for a presentation or turning on and off features for AB testing. After understanding microservices and differences between microservices and monolithic architecture. Let us also look at the top benefits of microservices. The primary benefit of micro service architecture is its loosely coupled components. These components can easily be developed, replaced and scaled individually. Microservices are not organized around technical capabilities of a particular product, but rather business capabilities, as the end goal is user experience and customer satisfaction. As with microservices, the choice of programming language can be multi lingual. Also the development teams can work in parallel on different piece of codes it improves the productivity and at the same time the speed of deployment. Increase for children's and forward isolation. Microservices offer fallback mechanisms, so that in case one micro service fails, the other microservices around, it won't get hampered and they can still make progress. Greater scalability and flexibility. This is one of the important features that microservices offer, its ability to scale horizontally. This means that any deployed service can be duplicated in order to avoid slow execution bottlenecks. Simplified security monitoring. The ability to isolate each service facilitates better security management and monitoring. It's always easier to isolate threats with the modular arrangement. Autonomous, cross- functional teams, specific microservices can be assigned to specific development teams, which allows them to focus solely on one service or feature. This means teams can work autonomously without worrying what's going on with the rest of the application. Let's take a look at some of the drawbacks of microservices design. Microservices designs are more complex. Communication between services can be complex at times. An application can include dozens or even hundreds of different services and they only to communicate securely. More expensive than monoliths. For microservices architecture to work for your organization you need sufficient hosting infrastructure with security and maintenance support. You also need skilled development teams who will understand and manage all of these services for you. Any micro service initiative requires organizations to make changes to their internal culture. Before they can start the migration process there should already be a mature agile and develops culture in place. Microservices design presents harder debugging problems. Debugging becomes more challenging with microservice. With an application consisting of multiple microservices and with each micro service having its own set of logs, pressing the source of the problem can be difficult at times. Global testing is difficult, while unit testing may be easier with microservices, integration testing is not. The components are distributed and developers can't test an entire system from their individual machines. To wrap up, clearly there are many advantages and disadvantages of microservices architecture to consider. But it's important to consider how well this approach fits your organizational culture and goals. Implementing microservices could bring great results that are highly beneficial, particularly to large companies or complex business domains. I hope you found this lesson useful. Thanks for watching.
