Building Microservices | 12 Factor App - Explicitly Declare and Isolate Dependencies | InterviewDOT
Channel: Interview DOT
Date: 2020-03-30

Click here - https://www.youtube.com/channel/UCd0U_xlQxdZynq09knDszXA?sub_confirmation=1 to get notifications.

Tamil Building Microservices | 12 Factor App - Explicitly Declare and Isolate Dependencies | InterviewDOT

The twelve-factor app methodology is a methodology for building software-as-a-service applications. These best practices are designed to enable applications with portability and resilience to be deployed to the web.

The 12 Factor App Manifesto gives some recommendations on how best to develop web apps for the cloud. A good SaaS application must be easily scalable, quickly deployable and easily portable. However, this is not so easy to guarantee. However, the standards proposed by the manifest are not applicable to all applications.

A 12-factor app relies on the explicit existence declaration of all dependencies, completely and exactly, via a dependency declaration manifest. And you must also use a dependency isolation tool along with dependency declaration.

Dependency declaration is required as it simplifies setup for developers who are new to the app.
Using dependency isolation tool during execution ensures that no implicit dependencies “leak in” from the surrounding system.
And using both dependency declaration and dependency isolation together is important, because only one is not sufficient to satisfy twelve-factor.

Explicitly declare and isolate dependencies

Your application might rely on external libraries and packages to run. You should never assume that these packages exist on the target system. Instead, your application must declare all dependencies and their correct version explicitly.

When working with PHP and Joomlatools Platform, we can rely on Composer to install dependencies for us. All we have to do is declare them in the composer.json manifest.

Dependencies

Instead of packaging the third-party libraries inside your microservice, specify your dependencies in your Maven pom.xml or Gradle settings.gradle file. This enables you to freely move up to newer versions.

Explicitly declare and isolate dependencies
Most programming languages ​​offer a system to distribute supporting libraries, such as CPAN for Perl or Rubygems for Ruby. Libraries originating from a package system can be installed system-wide (also called “site packages”) or restricted to a directory of the app (called “vendoring” or “bundling” - also “deliver” in German).

A twelve-factor app never relies on the existence of system-wide packages. It declares all dependencies completely and correctly via a dependency declaration . It also uses a dependency isolation tool at runtime to ensure that no implicit dependencies “leak” from the surrounding system. The full and explicit specification of the dependencies is applied equally in production and development.

For example, Bundler for Ruby offers the format Gemfilefor dependency declaration and dependency bundle execisolation. Python has two different tools for these steps - Pip for declaration and Virtualenv for isolation. Even C has autoconf to declare dependencies, and static linking can provide isolation. Regardless of the tools, the dependency declaration and isolation must always be used together - one alone is not enough for the twelve factors.

One benefit of the explicit dependency declaration is that the app is easier for new developers to set up. New developers can check out the app's codebase on their development machine and only need a language runtime and dependency management. To get the app up and running, all you need is a deterministic build command . For example, the build command for Ruby / Bundler bundle installand for Clojure / Leiningen is lein deps.

Nor do twelve-factor apps rely on the implicit existence of any system tools. Examples of this are shell calls from ImageMagick or curl. Even though these tools are available on many and even most systems, there is no guarantee that they will be available on all systems on which the app will run in the future, or that the tool version will be available on one system in the future is compatible. If the app accesses a system tool via shell, the app should also deliver the tool.