Building Microservices | 12 Factor App | Concurrency - Scale out process model | InterviewDOT
Channel: Interview DOT
Date: 2020-04-06

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

Tamil Building Microservices | 12 Factor App | Concurrency - Scale out via the process model | 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.

Concurrency
Scale with the process model
Each computer program, when running, is represented by one or more processes. Webapps use various types of process execution. For example, PHP processes run as child processes from Apache and are started as required when requests are received. Java processes are different: the JVM provides a massive over-process that reserves large amounts of system resources (memory and CPU) and the concurrency is managed internally via threads. In both cases, the running processes for the developers of the app can only be seen minimally.

The scaling is represented as running processes, the diversity of the workload is represented as process types.

In the twelve-factor app, processes are first class citizens. The processes of the twelve-factor app are based on the Unix process model for service daemons . With this model, developers can design their app for processing a wide variety of tasks by assigning a process type to each task . For example, HTTP requests can be served by a web process and long-term background work by a worker process.

This does not prevent the individual processes from managing their internal multiplexing, using threads in the runtime VM or the Async / event model tools like EventMachine , twisted or Node.js . But a single VM is limited in size (vertical scaling) because an app must still be able to start multiple processes on multiple physical machines.

The process model shines particularly when it comes to scaling. The share-nothing, horizontally divisible way of the processes of the twelve-factor app means that further concurrency can be added easily and reliably. The bundle of process types and the number of processes is also called process formation .

The processes of a twelve-factor app should never run as daemons or write PID files. Instead, they should rely on the process manager of the operating system (such as systemd , the distributed process manager of a cloud platform or a tool like Foreman during development) to manage output streams , react to crashed processes and with user-initiated restarts and shutdowns deal.

concurrency, advises us that cloud-native applications
should scale out using the process model. There was a time when, if
an application reached the limit of its capacity, the solution was to
increase its size. If an application could only handle some number of
requests per minute, then the preferred solution was to simply make
the application bigger.
Adding CPUs, RAM, and other resources (virtual or physical) to a
single monolithic application is called vertical scaling, and this type
of behavior is typically frowned upon in civilized society these days.
A much more modern approach, one ideal for the kind of elastic
scalability that the cloud supports, is to scale out, or horizontally.
Rather than making a single big process even larger, you create mul‐
tiple processes, and then distribute the load of your application
among those processes.
Most cloud providers have perfected this capability to the point
where you can even configure rules that will dynamically scale the
number of instances of your application based on load or other run‐
time telemetry available in a system.
If you are building disposable, stateless, share-nothing processes
then you will be well positioned to take full advantage of horizontal
scaling and running multiple, concurrent instances of your applica‐
tion so that it can truly thrive in the cloud.

When you need to scale, launch more microservice instances:
- Microservices should be designed to scale out by replicating.
- Microservices should be designed to scale horizontally rather
than vertically.
✓ AUTO-SCALING
The services can be elastically scaled or shrunk based on given
metric.
✓ Threading can be used within microservices, but don’t rely on
it as the sole mechanism for scaling