Docs: rewrite intro and "vs" to match landing page
Signed-off-by: Solomon Hykes <solomon@dagger.io>
This commit is contained in:
parent
4dd72b78a1
commit
79f86227f3
@ -4,40 +4,43 @@ slug: /1002/vs/
|
|||||||
|
|
||||||
# Dagger vs. Other Software
|
# Dagger vs. Other Software
|
||||||
|
|
||||||
|
## Dagger vs. CI (Github Actions, Gitlab, CircleCI, Jenkins, etc.)
|
||||||
|
|
||||||
|
Dagger does not replace your CI: it improves it by adding a portable development layer on top of it.
|
||||||
|
|
||||||
|
* Dagger runs on all major CI products. This *reduces CI lock-in*: you can change CI without rewriting all your pipelines.
|
||||||
|
* Dagger also runs on your dev machine. This allows *dev/CI parity*: the same pipelines can be used in CI and development.
|
||||||
|
|
||||||
## Dagger vs. PaaS (Heroku, Firebase, etc.)
|
## Dagger vs. PaaS (Heroku, Firebase, etc.)
|
||||||
|
|
||||||
_Summary: Dagger can be used with or without a PaaS system._
|
Dagger is not a PaaS, but you can use it to add PaaS-like features to your CICD pipelines:
|
||||||
|
|
||||||
A PaaS system is a complete platform for deploying and running certain types of applications.
|
* A simple deployment abstraction for the developer
|
||||||
|
* A catalog of possible customizations, managed by the platform team
|
||||||
|
* On-demand staging or development environments
|
||||||
|
|
||||||
- The benefit of using a PaaS system is convenience: developers don't have to worry about the many details of deployment: everything just works.
|
Using Dagger is a good way to get many of the benefits of a PaaS (developer productivity and peace of mind),
|
||||||
- The drawback of using a PaaS system is lack of flexibility: only certain types of applications are supported.
|
without giving up the benefits of custom CICD pipelines (full control over your infrastructure and tooling).
|
||||||
|
|
||||||
As an application grows, it is almost certain to outgrow the capabilities of a PaaS system, leaving no choice but to look for alternatives. A good strategy is to choose the right platform for each component. Some components continue to run on a PaaS system; others run on specialized infrastructure. This strategy can be implemented with Dagger: each component gets its own deployment plan expressed as code, and Dagger glues it all together into a single workflow.
|
|
||||||
|
|
||||||
## Dagger vs. artisanal deploy scripts
|
## Dagger vs. artisanal deploy scripts
|
||||||
|
|
||||||
_Summary: Dagger can augment your deploy scripts, and later help you simplify or even remove them._
|
Most applications have a custom deploy script that usually gets the job done, but is painful to change and troubleshoot.
|
||||||
|
|
||||||
Most applications don't fit entirely in any major PaaS system. Instead they are deployed by a patchwork of tools, usually glued together by an artisanal script.
|
Using Dagger, you have two options:
|
||||||
|
|
||||||
A deploy script may be written in virtually any scripting language. The most commonly used languages include Bash, Powershell, Make, Python, Ruby, Javascript... As well as a plethora of niche specialized languages.
|
1. You can *replace* your script with a DAG that is better in every way: more features, more reliable, faster, easier to read, improve, and debug.
|
||||||
|
2. You can *extend* your script by wrapping it, as-is, into a DAG. This allows you to start using Dagger right away, and worry about rewrites later.
|
||||||
|
|
||||||
Most teams are unhappy with their deploy script. They are high maintenance, tend to break at the worst possible time, and are less convenient to use than a PaaS. But when you need control of your stack, what other choice is there?
|
## Dagger vs. Infrastructure as Code (Terraform, Pulumi, Cloudformation, CDK)
|
||||||
|
|
||||||
Dagger can either replace artisanal deploy scripts altogether, or augment them by incorporating them into a more standardized deployment system. This is a good strategy for teams which already have scripts and want to improve their deployment gradually, without the disruption of a "big bang" rewrite.
|
Dagger is the perfect complement to an IaC tool.
|
||||||
|
|
||||||
## Dagger vs. CI (Github Actions, Gitlab, CircleCI, Jenkins, etc.)
|
* IaC tools help infrastructure teams answer questions like: what is the current state of my infrastructure? What is its desired state? And how do I get there?
|
||||||
|
* Dagger helps CICD teams answer question like: what work needs to be done to deliver my application, in what order, and how to I orchestrate it?
|
||||||
|
|
||||||
_Summary: Dagger can be used with or without a CI system._
|
It is very common for a Dagger configuration to integrate with at least one IaC tool.
|
||||||
|
|
||||||
Dagger is not a replacement for a CI system. It can be used to deploy applications directly from the terminal,
|
## Dagger vs. Build Systems (Make, Maven, Bazel, Npm/Yarn, Docker Build, etc.)
|
||||||
or automatically as part of a CI script.
|
|
||||||
|
|
||||||
## Dagger vs. Build Systems (Make, Maven, Bazel, Npm/Yarn, etc.)
|
Dagger is complementary to build systems. Most Dagger configurations involve integrating with at least one specialized build.
|
||||||
|
If several build systems are involved, Dagger helps integrate them into a unified graph.
|
||||||
_Summary: Dagger can be used with or without a build system._
|
|
||||||
|
|
||||||
Most deployment workflows involve building: the process of producing executable artifacts from source code. Build systems are highly specific to the type of application, the programming language in use, etc.
|
|
||||||
|
|
||||||
Dagger can integrate any build system into an overall deployment workflow. If a Dagger module is not already available for a particular build system, a custom module can easily be written, and perhaps even contributed to the open-source catalog for everyone else to use.
|
|
||||||
|
@ -4,32 +4,13 @@ slug: /
|
|||||||
|
|
||||||
# What is Dagger?
|
# What is Dagger?
|
||||||
|
|
||||||
Dagger is a universal deployment engine. Write your deployment logic once, run it securely from anywhere.
|
Dagger is a portable devkit for CICD. It helps you develop powerful CICD pipelines that can run anwyhere.
|
||||||
|
|
||||||
Key features:
|
* Choose from a wide catalog of reusable actions, or create your own in your favorite programming language.
|
||||||
|
* Tie it all together with [CUE](https://cuelang.org), the next-generation declarative language invented at Google. No more YAML hell!
|
||||||
* Escape YAML hell. Thanks to the Cue language, writing configuration is as fun and productive as writing code.
|
* Unify dev and CI. The same Dagger pipeline can run on your dev machine or in CI. All you need is a Docker-compatible runtime.
|
||||||
* A powerful declarative execution engine to automate even the most complex and custom logic
|
* Avoid CI lock-in. Dagger runs natively on Github Actions, Gitlab, CircleCI, Jenkins, AWS Codebuild, Tekton, and more.
|
||||||
* Static type checking so you can catch configuration errors before running that huge deployment
|
* Test and debug your pipelines locally; catch configuration errors in seconds with static type checking.
|
||||||
* Built-in caching and parallelism for maximum scale and performance
|
|
||||||
* An ecosystem of reusable packages to save you time and share your expertise with the community
|
|
||||||
* Avoid CI lock-in: the same Dagger configuration can be used in any CI, or with no CI at all
|
|
||||||
* Rapid local development: test and run everything locally, in seconds.
|
|
||||||
* Deploy from CI or the laptop: no more duplicating your CI config in a Makefile just so you can perform a task locally.
|
|
||||||
* Native support for encrypted secrets
|
|
||||||
* Just-in-time artifacts: fetch, transform and produce any artifact on the fly: source repositories, container images, binaries, database exports, ML models...
|
|
||||||
|
|
||||||
Using Dagger, teams with different deployment workflows can more easily collaborate and deploy each other's software,
|
|
||||||
without being forced to change their tools.
|
|
||||||
|
|
||||||
Typical use cases:
|
|
||||||
|
|
||||||
* On-demand staging environments for reviewing code changes
|
|
||||||
* Manage CICD across multiple repositories and CI runners, with one unified configuration
|
|
||||||
* Iterate on infrastructure without disrupting development teams
|
|
||||||
* Lock down access to the production cluster so that only authorized configurations are applied
|
|
||||||
* Common ground between the PaaS, Kubernetes and Serverless siloes.
|
|
||||||
* On-demand integration environments for testing complex changes spanning several teams
|
|
||||||
|
|
||||||
![Dagger_Website_Ship](https://user-images.githubusercontent.com/216487/122216381-328a3500-ce61-11eb-907f-d2b6f66b3b10.png)
|
![Dagger_Website_Ship](https://user-images.githubusercontent.com/216487/122216381-328a3500-ce61-11eb-907f-d2b6f66b3b10.png)
|
||||||
|
|
||||||
|
Reference in New Issue
Block a user