introduction to development Methodologies, the 12 factor app methodology. Now we're going to look at a domain specific methodology related to cloud computing with cloud computing. Instead of building monolithic solutions such as an accounting application, we build solutions from networks of loosely connected components, each independently scalable and reusable. Since we've covered, object or did concepts in an earlier course think of this as solutions being assembled from coarse grained stateless objects, communicating via messages sent over networks. The 12 Factor APP concepts grew out of the Haruko platform for cloud computing. We're looking at Cloud native Apps, which Haruka called Web apps, or software. As a service. Many enterprises have developed microservices based architectures as their preferred solution. Haruka was one of the earlier platforms for building such architectures, and the 12 factor app comes from that community now. There are other statements of principles, such as those identified by Martin Fowler for Microservices. In general, they're all looking at the same sorts of underlying complications involved in working with these sorts of architectures. Here are nine characteristics of a micro service architecture as identified by Martin Fowler, Component ization as services For a long time, developers have sought to assemble solutions from components. With this approach, those components are services Our teams are organized according to the business capabilities were trying to deliver, not according to job roles. We don't have a business team under a line of business manager, a team of UI experts and I t team under an I T manager and a team of DBS under an infrastructure manager. We have an inventory management team or a payroll team containing all of the members we need. This one might sound odd, but the point is that project teams tend to disband when the particular development project is done, whereas the product team lives for the lifetime of the product. It also means the developers are given more insight and ownership of what happens to their product in the production environment, rather than being kept at a great distance from it. As has been in the case in many organizations, the underlying issue behind smart endpoints and dumb pipes is to break from the enterprise service bus pattern that has been commonly found in classic service oriented architectures. The fact is that when service oriented architectures first emerged, we tried making smart endpoints that approach. Using the tools of the day was a failure. Developers had enough trouble writing the business logic for clients and services, much less putting in cross cutting concerns such as message transformation, protocol handling, routing, retrace cashing, authentication and authorization and more. So the next idea was that any semantically compatible client should be able to talk to any semantically compatible service regardless of physical message format, transport protocol, etcetera and the enterprise service. Bus technology would make it right smart plumbing handling most if not all, of the cross cutting concerns. And it was glorious. It worked. Clients and services could focus solely on their business logic, and the smart plumbing handled the rest. But the E S B the Enterprise Service bus became a monolith in its own right and a bottleneck. And so existing SP Technologies do not scale to the cloud. But let's face it, we still need these capabilities, and we don't want to have to write them in every client and service. So while the E S B pattern brought a great deal of value to service oriented architectures, we can't quite use it. But we don't want to give up the value So now what? So then now what is multi fold? First, we have better tools. We can easily embed routing, retry endpoint management and more into a spring boot application. With barely a line of code, we just have to declare certain dependencies in, maybe add an annotation. Alternatively, we could use the service mesh approach, which means that our micro service is packaged with a sidecar, another piece of software in the container to which we offload all of those cross cutting concerns. So we're still using the E S B as a pattern, in a sense, if you look at it in the right way, but the E S B is created out of things like the sidecars and micro services in the cloud. Rather than being part of a monolith, governance needs to be decentralized. Each product team should have a certain amount of autonomy and decision making. Data management is a thorny problem for microservices. There are a variety of things that are different with microservices than monoliths. With respect to data and new approaches for handling them. Devops devops devops. We must automate our infrastructure and not just ci CD, for example, constant monitoring of metrics that can be used to drive elastic provisioning of service instances as well as retirement of instances that are either having problems or no longer necessary for our scale. This issue is as crucial as it gets. We must design for failure. We must expect that every downstream call to another micro service may fail and be ready to handle the failure patterns such as cashing circuit breakers and bulkheads come into play here. This issue is so critical that Netflix developed Chaos monkey to actually randomly shut down services in their runtime environment in order to force themselves to make sure that they had successfully accommodated failure. Having built an architecture where solutions are assembled from discrete services, we have to accommodate evolution. This goes from how we consider migrating from a monolith to a services based solution to ensuring that all parts of our solution can continue to morph and evolve as necessary to meet new business requirements. Every component must be capable of being independently replaced and or upgraded. Hopefully, by now you are coming to understand that there are good reasons behind Martin Fowler's work as well as 12 factor apps and similar. They are necessary to address the fundamental nature of cloud native computing. Fowler's patterns, as well as the 12 factors, exist to provide guidance and best practices when implementing micro service solutions. Microsoft has catalogued over 40 such cloud designed patterns. 12 factor is essentially Paracas catalogue will spend most of the rest of this module looking at 12 factor apps, but for now recognize that they have the following characteristics. We use declarative formats to set up automation, minimizing the effort it takes for new developers to join a project. We insist on clean contracts between our code and the underlying operating system, providing portability across platforms for Java programmers, This is just part of the J. R E. Our apps are designed and implemented from the beginning to deploy in cloud environments and by Externalizing configuration. We minimize issues moving between development, testing, staging production and other environments. And finally, each component can scale massively, inherently and independently from other components. These are the 12 factors we're going to go over each of them individually. So for now we're just listing them. Remember, these are practices that came out of Haruko, their expressions of good practice, but some platforms may have other means to accomplish the same goal factor. One code base, one code base tracked and revision control. Many deploys two dependencies explicitly declare and isolate dependencies. Three Config. Store can fig in the environment. Four. Backing services treat backing services as attached resources. Five. Build release. Run strictly separate. Build and run stages. Six. Processes Execute our solution as one or more stateless processes. Seven. Port binding export services via port binding eight. Concurrency scale out via the process model nine. Disposability Maximize robustness with fast startup and graceful shutdown. 10. Keep development, staging and production as similar as possible. 11 logs treat logs as event streams. 12 admin processes, run admin and management tasks as one off processes. This was a fast list of the 12 factors in our next series of videos will go over these 12 factors in more detail.
