<div style="text-align: justify"> # The Twelve-Factor App The twelve-factor methodology is used for building software-as-a-service (SAAS) applications using any kind of programming language together with different backing services. Following this approach, it is possible to deploy an app that has minimum deviations between production and development, can be scaled and deployed to most cloud platforms without the need for system administrators or servers, and has a great connection with the base operating system. In general, these cloud-friendly applications do not only operate in the cloud — they also adopt elastic scalability, ephemeral file systems and statelessness. It is common for them to approach everything as a service which makes them easy to scale and deploy swiftly together with fast delivery of features and other changes. There are particular rules, guidelines and recommendations to follow for each factor/aspect of this methodology in order to develop a cloud-native application. ## Codebase The first and priority of the twelve factors is the codebase and it represents a single repository or a set of them sharing a root commit. An application must have only one codebase which is consistent across all application deployments and monitored in a version control system. One codebase is thought to have multiple deploys if the developers and their code are well organized. On the other hand, if an application is made up of a couple or more source code repositories, automating the build and deployment phases of the app's life cycle is practically impossible. Having several development teams working on a single codebase can lead to considerable problems. As a conclusion, good developer expertise, coordination and structure among the teams enable the application to have a functioning and well-organized codebase. It is certainly possible to share code across many applications using the _one code, one app_ approach. It's also crucial to determine if shared code should be treated as a microservice or as a standalone product. If shared code is a different product, it could be included as a dependency in the app. ## Dependencies Modern dependency management includes an integrated server that contains everything an application needs to run in a single build artifact. Applications should always bring their dependencies to the cloud in order to be self-contained and have an embedded server. The majority of programming languages have facilities that empower developers to define dependencies and delegate duty to make sure that those dependencies are fulfilled with a certain tool. Declared dependencies must be isolated at all times. Isolation might be accomplished by examining the specified dependencies and grouping them into a sub-structure beneath or inside the application's artifact. The code can't rely on dependencies already being present on the deployment destination. Furthermore, a cloud-native application never assumes the presence of system-wide packages. Possible failures can bring down a whole server or cost a corporation a financial loss due to undetected data corruption if dependencies are not adequately isolated. The idea of repeated deployments is important to properly manage an application's dependencies, thus no assumption should be made that the runtime into which an application is deployed is not automated. If dependencies are maintained with control and consistency, applications will be one level closer to being able to operate in cloud environments. ## Configuration The safest approach to save and maintain an application's configuration is to use _env vars_, which implies externalizing and storing the config in the environment. Non-changeable components do not belong in the configuration since it comprises of components that are variable throughout different deploys. Internal information that is part of the app must not be included in configuration. To clarify, if a value is consistent across all deploys, it isn't configuration. According to twelve-factor rules, configuration should be kept distinct from code, because code doesn't vary across different deploys, but configuration often does. With this separation, it is easier to alter environment variables as no code is being affected. It's extremely important to be cautious while keeping security credentials - they should never be kept in the codebase. Bundled assets remain part of the codebase even if security credentials are stored in some properties files or retrieved from the source code. Since environment variables are maintained individually for each deploy, the application concept that contains them scales efficiently. ## Backing services Any service on which an app relies for functionality via the network as part of its usual operation is referred to as an backing service. Managing datastores, messaging or queuing systems, SMTP services, caching systems, or even file storage that is attached to an app as a resource are all examples of backing services. Both local and third-party services are considered equivalent as they are associated to the app and accessed via URL or other configuration credentials. Each backing service is considered as a resource which may be integrated to and excluded from deploys at a certain moment. Without modifying any code, the current production database may be removed, and the new database attached. There are some specific requirements for resource binding that must be followed in addition to the previously listed twelve-factor principles: * an application should indicate its demand for a certain backing service but let the actual resource binding to the cloud environment * external configuration should be used to relate an application to its backing services * without having to re-deploy the application, it should be possible to place and remove backing services freely The job of system administrators is made easier once an adaptive and robust cloud-native application is built by following the guidelines above. ## Build, release, run The fifth factor involves three critical steps: build, release, and run, although some additionally include a design step as the initial stage of the process. Dependencies, their packaging mechanism, and the way of attaching them to the application should all be defined during this added design phase. The result of the build phase is an executable artifact created from the code repository. The _"one build, multiple deploys"_ approach requires it to be versioned and function properly everywhere. The build is combined with the configuration in the following release stage, which is then delivered to the cloud environment. Because it integrates the initial build with a specified configuration, each release must be unique. Furthermore, if an issue occurs, it is easy to revert to a prior release. Finally, at the run stage, cloud providers generally provide a runtime that is responsible for keeping the application operational while evaluating its performance and gathering its logs. The main goal is to isolate all phases, increase deployment speed, and automate application testing, all of which may be accomplished using cloud services. ## Processes Following the 12-factor model, an application should operate as a solo stateless process, or in exceptional cases, several stateless processes that share absolutely nothing. Share-nothing architecture (SNA) presents a distributed computing architecture made up of numerous isolated nodes. These nodes don't share the same memory, which reduces possible conflicts between them (for example, causing problems while attempting to update some data simultaneously). [**ana add reference later**](https://en.wikipedia.org/wiki/Shared-nothing_architecture) Because cloud processes come and go, everything shared within them might vanish as well, potentially producing a cascade of catastrophes. In the process of handling a request, the application can produce and use temporary state, but that data must therefore be gone by the time the consumer receives a response. To be clear, a state can exist, but it cannot be managed by the application, and it must be given by outer backing services if it is to be long-lasting. It could be beneficial to utilize some third-party solutions as a backing service for the application's session state or caching data. This is done in order to avoid processes exchanging data that is closely linked. ## Port binding A cloud-native application is considered entirely self-contained and does not require insertion into any external application server or container. This port-binding factor specifies that a service or application is specified by a port number rather than a domain name by the network. Because it also maintains various network components, the cloud provider shall handle the port assignment for the application. Although a cloud provider could offer a web container, it is quite improbable that it will allow numerous applications to be hosted in the same container. This necessitates a 1:1 association between the application and the application server at all times. After all, an application that supports externalized port binding becomes incredibly strong and may easily be utilized as a backing service for another application. ## Concurency By allocating each type of work to a process type, an application may be developed to manage a variety of workloads using the twelve-factor model. By embracing concurrency, different segments of an application can be scaled up to match the requirements when needed. Vertical scaling, which involves additional RAM, CPUs, or other resources, is no longer considered contemporary. The main idea is to generate several processes, and then divide the application's burden across them. This technique allows the application to scale out, or horizontally - it refers to scaling up an application by adding additional instances of machines rather than increasing resources and scaling up the entire application. [**ana add reference later**](https://touchstonesecurity.com/horizontal-vs-vertical-scaling-what-you-need-to-know/) ## Disposability Cloud-native application's processes are disposable, which means they may be launched and terminated at any point. Processes should try to reduce startup time, leading to greater agility in the release and scaling up processes. Very long startup times in the cloud might possibly inhibit the app from launching at all. On the other hand, it may be difficult to relaunch an application after a failure if it does not shut down properly and promptly. Long-running operations shall perform independently or be externalized as a backing service to utilize cloud-native architecture. ## Dev/prod parity Tenth factor presents the need of having application's development, staging and production segments, or to better say, all environments as similar as possible. By keeping the distance between development and production minimal, the 12-factor application is intended for continuous application delivery. To be more specific, there are three key aspects to consider: time gap, manpower gap, and tool gap. 1. Release intervals of once a month, for example, might be too long for some applications. Organizations should attempt to shorten the time gap between check-in and production (minutes, hours) to improve the situation, as developers may forget what they've done previously and what went into a release. This might also help developers work more efficiently because they would know that their code will be deployed almost immediately. 2. Deployers and developers should be the same people, indicating the need for synchronizing the production deployment process with the development process. However, if a good build pipeline is in place, an application should be automatically deployed to all relevant environments. 3. When using particular backing services, there should be no compromises, which means that the same resource types should be utilized in all environments. The company loses the capacity to predict how code change will perform in production if the development, testing, and production environments are all different. ## Logs A 12-factor application should never try to write to or maintain log files, and it should never worry about routing or storing its output stream. Typically, logs are saved in text format, with each line reflecting a single event. Because logs are a time-ordered sequence of events generated by an application, they should be handled as event streams. The event stream can be forwarded to a log indexing and analysis system, saved to a file, or viewed in real time through a terminal's output. Cloud-native applications write all of their logs to `stdout` and `stderr`, as they usually know very little about the file system on which they run. The entire codebase of an application becomes simpler when it is separated from the knowledge of log storage. Furthermore, when log modifications are required, the application itself doesn't require any changes. > we have them stored as files now, have to think of that later [name=ananovokmet] ## Admin processes The final factor indicates that all administrative and management operations should be executed as one-off processes in the very same environment as the application's typical long-running processes. Furthermore, to avoid synchronization concerns, admin code must be sent alongside application code. To run one-off admin processes in a local deployment, developers use a direct shell command; however, in a production deployment, developers could utilize a remote command execution method, for example `ssh`. What is more, cloud-native applications should integrate more efficient solutions for performing one-off processes. AWS Lambda functions, for example, are called on-demand and do not require organizations to leave provided servers up and running. <br> ## Additional factors In the _Beyond the 12-Factor App_ book, author _Kevin Hoffman_ stated some additional factors to build cloud-native applications even more appropriate. ### API first As it is written in the book, Application Programming Interfaces (API) should be treated as _First-Class Citizens_. The main benefits of _API first_ approach is that organization teams have the ability to work in parallel, it can reduce the cost of application development process, it can increase the speed to market and reduce the risk of failure. There are 8 common stages for the API-first plan: 1. Brainstorming - figuring out which APIs and services should be built and offered 2. Establishing API stakeholders - API initiatives should involve as many individuals as possible 3. Designing an API contract - consistency is very important; all APIs should be described, documented, and work the same 4. Creating a style guide - it is important to ensure consistency across the teams that are building services 5. Implementing API governance - it can assist in enforcing specified standards and reinforcing intended outcomes 6. Automating processes - for example, generating documentation, style validation, versioning, etc. 7. Tracking and managing API portfolio - for discovering duplicated code, redundant APIs, or their dependencies 8. Creating a portal for internal developers - an internal location where all API-related information, such as specifications, and contracts, is kept [**ana add reference later**](https://swagger.io/resources/articles/adopting-an-api-first-approach/) ### Telemetry Auditing and monitoring cloud applications are sometimes underestimated, although they are among the most crucial aspects of production deployment planning and execution. In the cloud, establishing telemetry properly might make the difference between success and failure. ### Authentication and authorization The code of a cloud-native application is deemed safe since it is transmitted across multiple data centers, operated in multiple containers, and accessible by a large number of clients. Even if the organization wants to integrate security measures only to keep track of which person performed which data modification, it is an advantage in and of itself. Whether the product is intended for an enterprise, a mobile device, or the cloud, security should never be forgotten or ignored. <br> <br> <br> > is it enough to put references on the [book](https://www.cdta.org/sites/default/files/awards/beyond_the_12-factor_app_pivotal.pdf) and 12factor.net at the end of the whole section? [name=ananovokmet] </div>
Last changed by  
 
ana
anas work
331

Read more

possible sections to write

1 monolithic architectures and their problems 2 microservices and why both 1&2: http://aws-de-media.s3.amazonaws.com/images/AWS_Summit_Berlin_2016/sessions/pushing_the_boundaries_1300_microservices_on_aws.pdf

8/15/2022
PACKER OUTPUT

ana@DESKTOP-U0ULQ81:/mnt/c/Users/it/cloudana_git/LDM_GIT/ldm/ldm$ packer build -force -var "latest_ldm=$latest_ldm" -var-file="marketplace.pkrvars.hcl" test.pkr.hcl amazon-ebs.example: output will be in this color. azure-arm.example: output will be in this color. ==> azure-arm.example: Running builder ... ==> azure-arm.example: Getting tokens using device flow ==> azure-arm.example: Getting token for https://management.azure.com/ ==> azure-arm.example: Loading auth token from file: /home/ana/.azure/packer/oauth-184a7bbc-05d1-4814-acdb-8647136eff21mgmt.json ==> azure-arm.example: Auth token found in file: /home/ana/.azure/packer/oauth-184a7bbc-05d1-4814-acdb-8647136eff21mgmt.json ==> amazon-ebs.example: Force Deregister flag found, skipping prevalidating AMI Name

3/11/2022
AWS Lambda use cases

AWS Lambda has over 100,000 monthly active users, does billions of monthly executions, and is available in 22 worldwide locations. Many organizations have chosen to use the Function-as-a-Service (FaaS) model to enhance their business operations while saving both time and money. AWS Lambda has a variety of fascinating use cases, and few of them will be briefly covered in this chapter. Mass Emailing Each year, many huge corporations, for example, The New York Times, must send billions of transactional emails, as well as newsletters, and other publications. Mass emailing demands technological skill and is highly expensive, but it has become a vital aspect of any marketing campaign. Simple Email Service (SES) and AWS Lambda can work together to provide a cost-effective email flow, while the email list is safely stored in Simple Storage Service (S3). General steps are: Upload CSV file A CSV file is a trigger for an S3 event That S3 event invokes a Lambda Function Lambda function adds the CSV file to DynamoDB database

12/17/2021
AWS Lambda best practices

Best practice rules for AWS Lambda https://www.trendmicro.com/cloudoneconformity/knowledge-base/aws/Lambda/ also best practices, has some advices https://aws.plainenglish.io/aws-lambda-best-practices-7454da49314d --> Since serverless computing has its own set of disadvantages, it may not be appropriate for everyone or every use case. When it comes to developing Lambda code, knowing how a lambda function works may help us identify some of the best practices to follow when utilizing lambda functions, as well as the value of each best practice. Function code and dependencies, function configuration, logging and monitoring are among the key practices described below. 1. The lambda handler should be separated from service logic It is recommended that the business logic be written in a separate service layer rather than in the handler function itself. It's because it makes it much simpler to write more readable and intelligible code, as well as unit-testable code for the business logic. For example, the handler function will be an entry point for a lambda function and let's say that multiple variables are passed into the mentioned handler function. It may get problematic if each lambda triggers an event with the first parameter containing all information about the triggering event.

12/13/2021
Read more from ana
Published on HackMD