Скачать или смотреть Building Microservices | 12 Factor App | Port Binding | InterviewDOT

Click here -    / @interviewdot   to get notifications.

Tamil Building Microservices | 12 Factor App | Port Binding | 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.

Binding to ports
Export services by tying ports
Web apps sometimes run as a container in a web server. For example, PHP apps run as a module in Apache HTTPD , or Java apps sometimes run in Tomcat .

The twelve-factor app is completely independent and does not rely on an external web server being injected at runtime to provide the web with a service. The web app exports HTTP as a service by binding itself to a port and waits for requests on this port.

In a local development environment, a developer opens a service URL such as http://localhost:5000/to access the app's service. During deployment, a routing layer ensures that requests from a publicly visible host name come to the processes linked to the ports.

This is usually implemented using a dependency declaration. A web server library such as Tornado for Python, Thin for Ruby or Jetty for Java and other JVM-based languages ​​is added to the app . This takes place entirely in the user space , i.e. in the code of the app. The contract with the runtime environment is binding to a port to service requests.

HTTP is not the only service that can be exported through port binding. Almost any server software can be operated by tying a process to a port and waiting for incoming requests. Some examples are ejabberd (speaks XMPP ) and Redis (speaks the Redis protocol ).

It should also be mentioned that port binding enables an app to become a supporting service for another app by providing the URL of the supporting app to the consuming app as a resource handle.

Export services via port binding
Web applications are traditionally deployed to a certain software stack. Java enterprise applications for examples are deployed to an enterprise or Servlet container whereas server-side scripting languages such as PHP run on top of a web server. The applications therefore depend on their immediate runtime.

This 12-factor principle advise to develop self-sufficient applications that expose their functionality via network ports. Since web-based enterprise applications will communicate via the network, binding services to ports is the way of least coupling.

Web applications, especially those already running within an enter‐
prise, are often executed within some kind of server container. The
Java world is full of containers like Tomcat, JBoss, Liberty, and Web‐
Sphere. Other web applications might run inside other containers,
like Microsoft Internet Information Server (IIS).
In a noncloud environment, web applications are deployed to these
containers, and the container is then responsible for assigning ports
for applications when they start up.
One extremely common pattern in an enterprise that manages its
own web servers is to host a number of applications in the same
container, separating applications by port number (or URL hierar‐
chy) and then using DNS to provide a user-friendly facade around
that server. For example, you might have a (virtual or physical) host
called appserver, and a number of apps that have been assigned
ports 8080 through 8090. Rather than making users remember port
numbers, DNS is used to associate a host name like app1 with app
server:8080, app2 with appserver:8081, and so on.

Avoiding Micromanaging Port Assignments
Embracing platform-as-a-service here allows developers and devops
alike to not have to perform this kind of micromanagement any‐
more. Your cloud provider should be managing the port assignment
for you because it is likely also managing routing, scaling, high avail‐
ability, and fault tolerance, all of which require the cloud provider to
manage certain aspects of the network, including routing host
names to ports and mapping external port numbers to containerinternal ports.
The reason the original 12 factor for port binding used the word
export is because it is assumed that a cloud-native application is selfcontained and is never injected into any kind of external application
server or container.