Docs: Dagger vs Other Software
Signed-off-by: Solomon Hykes <sh.github.6811@hykes.org>
This commit is contained in:
parent
ba9210cf7c
commit
0f6ae46902
@ -19,7 +19,7 @@ Dagger is *alpha-quality software*. It has many bugs, the user interface is mini
|
||||
|
||||
## 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)
|
||||
* [Tutorials](doc/tutorials.md)
|
||||
* [Adding Dagger to your project](doc/adding_dagger.md)
|
||||
|
26
doc/vs.md
Normal file
26
doc/vs.md
Normal 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.
|
@ -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 it’s 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.
|
Reference in New Issue
Block a user