The [process formation](https://12factor.net/concurrency) is the array of processes that are used to do the app’s 
regular business (such as handling web requests) as it runs.

Twelve-factor strongly favors languages which provide a REPL shell out of the box, and which make it easy to run 
one-off scripts.

In a local deploy, developers invoke one-off admin processes by a direct shell command inside the app’s checkout 
directory.

In a production deploy, developers can use ssh or other remote command execution mechanism provided by that deploy’s 
execution environment to run such a process. Cheers!!


Admin processes: Run admin/management tasks as one-off processes

Logs are the stream of aggregated, time-ordered events collected from the output streams of all running processes 
and backing services.

A twelve-factor app never concerns itself with routing or storage of its output stream.

It should not attempt to write to or manage logfiles. Instead, each running process writes its event stream, 
unbuffered, to `stdout`.

During local development, the developer will view this stream in the foreground of their terminal to observe the 
app’s behavior. Cheers!!


Logs: Treat logs as event streams

The twelve-factor app is designed for continuous deployment by keeping the gap between development and production 
small.

Looking at the three gaps described above:

### Make the time gap small

A developer may write code and have it deployed hours or even just minutes later.

### Make the personnel gap small

Developers who wrote code are closely involved in deploying it and watching its behavior in production.

### Make the tools gap small

Keep development and production as similar as possible. Cheers!!


Dev/prod parity: Keep development, staging, and production as similar as possible

The twelve-factor app’s [processes](https://12factor.net/processes) are disposable, meaning they can be started or stopped at a moment’s notice.

This facilitates fast elastic scaling, rapid deployment of [code](https://12factor.net/codebase) or [config](https://12factor.net/config) changes,
and robustness of production deploys.

Processes should strive to minimize startup time. Ideally, a process takes a few seconds from the time the launch 
command is executed until the process is up and ready to receive requests or jobs.

Processes should also be robust against sudden death, in the case of a failure in the underlying hardware. Cheers!!


Disposability: Maximize robustness with fast startup and graceful shutdown

In the twelve-factor app, processes are a first class citizen.

Processes in the twelve-factor app take strong cues from the unix process model for running service daemons.

Using this model, the developer can architect their app to handle diverse workloads by assigning each type of work 
to a process type.

For example, HTTP requests may be handled by a web process, and long-running background tasks handled by a worker 
process. Cheers!!


Concurrency: Scale out via the process model

The twelve-factor app is completely self-contained and does not rely on runtime injection of a webserver into the 
execution environment to create a web-facing service.

The web app exports HTTP as a service by binding to a port, and listening to requests coming in on that port.

HTTP is not the only service that can be exported by port binding.

Nearly any kind of server software can be run via a process binding to a port and awaiting incoming requests. Cheers!!


Port binding: Export services via port binding


Pulumi is an infrastructure-as-code (IAC) platform that allows developers and operators to define, deploy, and 
manage cloud resources using familiar programming languages like Python, JavaScript, TypeScript, Go, and C#.

![pulumi example](/images/blog/pulumi-1.png)

Pulumi has gained traction in the community for several reasons:

- **Familiar programming languages**: Pulumi supports popular, general-purpose programming languages, enabling 
  developers to leverage their existing skills and knowledge. This allows for a smoother learning curve and 
  improved productivity.

- **Code reusability and modularity**: Pulumi's support for general-purpose programming languages enables better code 
reusability, modularity, and organization. Developers can create custom abstractions, share code between projects, 
and apply software engineering best practices to infrastructure management.

- **Integration with existing tools and libraries**: Pulumi's language support allows for easy integration with 
  existing tools, libraries, and frameworks. This can help streamline development workflows and improve overall 
  efficiency.

- **Strong support for cloud platforms**: Pulumi provides support for a wide range of cloud providers, including AWS, 
Azure, Google Cloud, and Kubernetes. It also offers support for additional providers and services through its 
growing ecosystem.

- **Real-time feedback and preview**: Pulumi offers real-time feedback and preview capabilities, allowing developers to 
see the impact of their infrastructure changes before applying them. This can help catch potential issues early and 
improve overall reliability.

- **State management**: Pulumi manages state using its Pulumi Service, which simplifies state handling, locking, and 
consistency for users. This can lead to a more streamlined user experience compared to some other IAC tools.

- **Policy as Code**: Pulumi includes policy-as-code capabilities, allowing organizations to enforce best practices, 
security policies, and compliance requirements across their infrastructure.

- **Growing community and ecosystem**: Pulumi has been attracting attention from developers and organizations 
  looking for a modern approach to infrastructure management. This has resulted in a growing community, ecosystem, 
  and library of pre-built components.

## Differences between Terraform and Pulumi

Both of them are infrastructure-as-code (IAC) tools that help users automate and manage their cloud infrastructure.

Although they share a common purpose, there are several differences between the two tools:

#### Language Support

**Terraform**: It uses its own domain-specific language (DSL) called HashiCorp Configuration Language (HCL) for writing 
infrastructure configurations. HCL is designed specifically for defining cloud infrastructure and resources, making 
it easy to read and understand.

![terraform example](/images/blog/terraform.png)

**Pulumi**: It supports general-purpose programming languages like Python, JavaScript, TypeScript, Go, and C#. This 
enables users to leverage existing programming skills and use familiar constructs, libraries, and tools for 
infrastructure management.

![pulumi example](/images/blog/pulumi-2.png)

#### Ecosystem and Community

**Terraform**: Developed by HashiCorp, Terraform has a larger and more mature ecosystem with a broad range of supported 
cloud providers and services. It has a vast collection of pre-built modules and a large user community.

**Pulumi**: Pulumi is a newer and smaller player in the IAC space. Although it has a growing ecosystem and support for 
various cloud providers, its community and library of pre-built modules are not as extensive as Terraform's.

#### State Management

**Terraform**: It manages the state of infrastructure using a local or remote backend, which stores the current state 
of resources. Users must configure state backends and handle state locking and consistency.

**Pulumi**: It handles state management through its own Pulumi Service, which stores and manages the state by default. 
Pulumi automatically handles state locking and consistency, simplifying the user experience.

#### Pricing and Open Source

**Terraform**: It is an open-source tool, and its core functionality is free to use. HashiCorp also offers a commercial 
product called Terraform Enterprise that adds features like collaboration, governance, and enhanced security.

**Pulumi**: It offers a free tier with basic features and limited usage, but its advanced features and commercial 
support require a paid subscription. Pulumi's core is open source, but its service for state management is not.

#### Interoperability

**Terraform**: Terraform's HCL may have a learning curve for users who are not familiar with it. While Terraform has 
excellent cloud provider support, it can be more challenging to integrate with existing application codebases.

**Pulumi**: Since it uses general-purpose programming languages, Pulumi can more easily integrate with existing 
codebases, libraries, and frameworks, enabling developers to create reusable components and apply software 
engineering best practices to infrastructure management.

## Conclusion

That said, both Terraform and Pulumi have their strengths and weaknesses. The choice between them will depend on
factors such as the user's programming background, desired language support, existing tooling, and community support.

Despite being a newer player in the IAC space, Pulumi's unique approach of using general-purpose programming 
languages and its focus on developer experience has resonated with many in the community.

HelloWorld's professionals keep an eye on innovative solutions like Pulumi and Terraform, so they can use the right 
technologies and tools for the challenging problems they have to tackle every single day. Cheers!!


Pulumi vs Terraform

Twelve-factor processes are stateless and [share-nothing](https://en.wikipedia.org/wiki/Shared-nothing_architecture).

Any data that needs to persist must be stored in a stateful [backing service](https://12factor.net/backing-services),
typically a database.

The twelve-factor app never assumes that anything cached in memory or on disk will be available on a future request 
or job – with many processes of each type running, chances are high that a future request will be served by a 
different process.

Even when running only one process, a restart (triggered by code deploy, config change, or the execution environment 
relocating the process to a different physical location) will usually wipe out all local (e.g., memory and 
filesystem) state. Cheers!!


Processes: Execute the app as one or more stateless processes


In the context of modern software engineering, DevOps is a complementary counterpart, much like the concept of 
Yin and Yang. These two concepts, originating from Chinese philosophy, represent the interconnectedness and 
interdependence of seemingly opposite forces in the natural world.

The traditional approach tech companies followed for many years often separated development and operations teams, 
creating silos and communication gaps. This separation could lead to inefficiencies, delays, and lower-quality 
software. DevOps brings these two functions together, integrating them into a seamless whole.

Just as Yin and Yang symbolize harmony and balance in nature, DevOps aims to harmonize the software development 
life cycle by fostering collaboration, shared goals, and continuous improvement, allowing organizations to deliver 
software faster, more reliably, and with higher quality.

Here are some key aspects that highlight the importance of DevOps culture for modern software products:

- **Faster time to market**: DevOps practices, such as continuous integration and continuous deployment (CI/CD), enable 
organizations to release software updates and new features more frequently, allowing them to stay competitive and 
respond quickly to market demands.

- **Improved collaboration**: DevOps culture encourages cross-functional teams, breaking down silos between development, 
operations, and other stakeholders. This improved collaboration leads to better communication, faster 
  decision-making, and increased innovation.

- **Higher quality**: By automating testing and deployment processes, DevOps helps reduce human error and increases the 
overall quality of the software. This results in fewer bugs, improved stability, and better user experiences.

- **Increased efficiency**: Automation and streamlined processes in DevOps eliminate manual, time-consuming tasks, 
allowing team members to focus on more valuable work, such as feature development or innovation.

- **Better resource management**: DevOps practices, such as infrastructure as code (IAC), enable more effective 
management of resources, leading to cost savings and reduced waste.

- **Enhanced scalability**: DevOps enables teams to build and deploy software using cloud-native architectures and 
technologies, making it easier to scale applications up or down as needed.

- **Continuous learning and improvement**: DevOps culture emphasizes a continuous learning mindset, encouraging teams to 
regularly assess and improve their processes, tools, and skills. This constant feedback loop helps organizations 
stay agile and adapt to changes in the market.

In summary, adopting a DevOps culture is crucial for modern software products as it helps organizations stay 
competitive, deliver better quality software, and respond more effectively to market demands. It fosters 
collaboration, efficiency, and continuous improvement, making it a key aspect of successful software development 
and IT operations.

Cheers!!


Engineering without DevOps is like Yin without Yang


The twelve-factor app uses strict separation between the build, release, and run stages.

For example, it is impossible to make changes to the code at runtime, since there is no way to propagate those 
changes back to the build stage.

Every release should always have a unique release ID, such as a timestamp of the release (such as 2011-04-06-20:32:17 )
or an incrementing number (such as  v100 ).

Releases are an append-only ledger and a release cannot be mutated once it is created.

Any change must create a new release. Cheers!!


Build, release, run: Strictly separate build and run stages


The code for a twelve-factor app makes no distinction between local and third party
services. To the app, both are attached resources, accessed via a URL or other
locator/credentials stored in the config.

A deploy of the twelve-factor app should be able to swap out a local MySQL database
with one managed by a third party (such as Amazon RDS) without any changes to the
app’s code.

Likewise, a local SMTP server could be swapped with a third-party SMTP service (such
as Postmark) without code changes.

In both cases, only the resource handle in the config needs to change.


Backing services: Treat backing services as attached resources


The twelve-factor app stores config in environment variables (often shortened to env vars or env).

Env vars are easy to change between deploys without changing any code; unlike config files, there is little chance 
of them being checked into the code repo accidentally; and unlike custom config files, or other config mechanisms 
such as Java System Properties, they are a language- and OS-agnostic standard.

Env vars are granular controls, each fully orthogonal to other env vars. They are never grouped together as 
"environments", but instead are independently managed for each deploy. This is a model that scales up smoothly as 
the app naturally expands into more deploys over its lifetime.


Config: Store config in the environment


A twelve-factor app never relies on the implicit existence of system-wide packages. It declares all dependencies,
completely and exactly, via a dependency declaration manifest.

Furthermore, it uses a dependency isolation tool during execution to ensure that no implicit dependencies "leak in"
from the surrounding system.

The full and explicit dependency specification is applied uniformly to both production and development.


Dependencies: Explicitly declare and isolate dependencies


A twelve-factor app is always tracked in a version control system, such as Git, Mercurial, or Subversion.

A copy of the revision tracking database is known as a code repository, often shortened to code repo or just repo.

There is only one codebase per app, but there will be many deploys of the app.

A deploy is a running instance of the app. This is typically a production site, and one or more staging sites.

Additionally, every developer has a copy of the app running in their local development environment, each of which also qualifies as a deploy.


Publications about "devops"

Admin processes: Run admin/management tasks as one-off processes

By HelloWorld PC

Logs: Treat logs as event streams

By HelloWorld PC

Dev/prod parity: Keep development, staging, and production as similar as possible

By HelloWorld PC

Disposability: Maximize robustness with fast startup and graceful shutdown

By HelloWorld PC

Concurrency: Scale out via the process model

By HelloWorld PC

Port binding: Export services via port binding

By HelloWorld PC

Pulumi vs Terraform

By HelloWorld PC

Processes: Execute the app as one or more stateless processes

By HelloWorld PC

Engineering without DevOps is like Yin without Yang

By HelloWorld PC

Build, release, run: Strictly separate build and run stages

By HelloWorld PC