Docs: Dagger vs Other Software

Signed-off-by: Solomon Hykes <sh.github.6811@hykes.org>
This commit is contained in:
Solomon Hykes 2021-03-25 00:31:22 +00:00
parent ba9210cf7c
commit 0f6ae46902
3 changed files with 27 additions and 26 deletions

View File

@ -19,7 +19,7 @@ Dagger is *alpha-quality software*. It has many bugs, the user interface is mini
## Learn More ## Learn More
* [What is Application Delivery as Code?](doc/what_is_adc.md) * [Dagger vs. Other Software](doc/vs.md)
* [Installing Dagger](doc/install.md) * [Installing Dagger](doc/install.md)
* [Tutorials](doc/tutorials.md) * [Tutorials](doc/tutorials.md)
* [Adding Dagger to your project](doc/adding_dagger.md) * [Adding Dagger to your project](doc/adding_dagger.md)

26
doc/vs.md Normal file
View File

@ -0,0 +1,26 @@
# Dagger vs. Other Software
## Dagger vs. PaaS (Heroku, Firebase, etc.)
*Summary: Dagger can be used with or without a PaaS system.*
A PaaS system is a complete platform for deploying and running certain types of applications.
* The benefit of using a PaaS system is convenience: developers don't have to worry about the many details of deployment: everything just works.
* The drawback of using a PaaS system is lack of flexibility: only certain types of applications are supported.
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
*Summary: Dagger can augment your deploy scripts, and later help you simplify or even remove them.*
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.
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.
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 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.

View File

@ -1,25 +0,0 @@
# What is Application Delivery as Code?
## The problem with PaaS
A PaaS, or platform-as-a-service, is the glue between an application and the cloud infrastructure running it. It automates the deployment process and provides a simplified view of the underlying infrastructure, which makes developers more productive.
However, despite the undeniable productivity benefits of using a PaaS, most applications today do not. Why? Because it's not flexible enough: each PaaS only supports certain types of application stacks and infrastructure. Applications that cannot adapt to the platform are simply not supported.
## The problem with artisanal deploy scripts
Most applications don't fit in any major PaaS. Instead they are deployed by a patchwork of specialized tools, usually glued together by an artisanal shell script or equivalent.
*FIXME: example of specialized tools*
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?
## The best of both worlds: Application Delivery as Code
Application Delivery as Code (ADC) is an alternative to PaaS and artisanal deploy scripts, which combines the best of each.
Simply put, with ADC each application gets its own single-purpose PaaS. The platform adapts to the application, not the other way around. And because its defined *as code*, this custom PaaS can easily be changed over time, as the application stack and infrastructure evolves.
Because doing this with a general programming language, like Go, would be prohibitively expensive, a good ADC implementation requires a specialized language and runtime environment. For example, Dagger uses [Cue](https://cuelang.org) as its language, and [Buildkit](https://github.com/moby/buildkit) as its runtime environment.