2019-08-23 14:22:47 -07:00
|
|
|
---
|
2023-06-02 21:41:36 -07:00
|
|
|
title_tag: "Pulumi vs. Custom IaC Solutions"
|
2022-12-13 15:19:37 -08:00
|
|
|
meta_desc: Learn about the major differences between Pulumi and custom infrastructure as code solutions.
|
2023-05-15 15:25:28 -07:00
|
|
|
title: Custom Solutions
|
|
|
|
h1: Pulumi vs custom infra-as-code solutions
|
2023-06-08 16:15:52 -07:00
|
|
|
meta_image: /images/docs/meta-images/docs-meta.png
|
2019-08-23 14:22:47 -07:00
|
|
|
menu:
|
2023-05-15 15:25:28 -07:00
|
|
|
concepts:
|
2019-08-23 14:22:47 -07:00
|
|
|
parent: vs
|
2019-09-10 08:04:15 -07:00
|
|
|
weight: 8
|
2021-09-14 07:48:43 -07:00
|
|
|
aliases:
|
|
|
|
- /docs/reference/vs/custom/
|
2023-05-15 15:25:28 -07:00
|
|
|
- /docs/intro/vs/custom/
|
2019-08-23 14:22:47 -07:00
|
|
|
---
|
|
|
|
|
|
|
|
Many organizations start out by manually managing their infrastructure. This often begins by pointing and clicking in
|
|
|
|
your cloud's web console, and then evolve by encoding provisioning and logic in simple scripts (Bash, Python, etc).
|
|
|
|
|
|
|
|
This approach works in the early days, but this home-grown solution begins to break down over time
|
|
|
|
|
|
|
|
* Provisioning multiple copies of an app is difficult (or impossible)
|
|
|
|
* The logic in scripts grow non-linearly with respect to your infrastructure's complexity
|
|
|
|
* Failure modes require manual intervention to repair environments, often leading to downtime
|
|
|
|
* As cloud providers evolve, it becomes hard to keep up and adopt the latest innovations
|
|
|
|
|
|
|
|
The maintenance cost of solutions like this often grows to consume multiple team members; it, in fact, usually ties
|
|
|
|
up your best and brightest engineers. Many teams find that they spend more time managing their home-grown
|
|
|
|
infrastructure scripts than they do writing business logic, and still can't move as fast as they want to.
|
|
|
|
|
Eliminate "real languages" from our website (#4032)
* Eliminate "real languages" from our website
We know that this terminology is unfriendly and can be seen as
gatekeeping. We've moved away from it over time, but there are many
traces of it in our documentation -- most notably, even on our
homepage. Instead of "real languages", let's use "familiar languages",
and in places where deeper explanation makes sense in context, we
can say "familiar, general-purpose languages."
The current 2nd-level blurb on the homepage isn't very good right now
anyhow, so this is a convenient change. As we make progress on various
marketing efforts, we will likely make more extensive changes, but
for now this at least fixes this problem. We recently A/B tested
updates without much of an impact, so let's move ahead with this change
and then if we want to test alternatives to "familiar", we can do that.
For instance, we considered "popular", etc.
* Also eliminate "real code"
2020-08-19 06:19:50 -07:00
|
|
|
Pulumi was designed to address these problems out of the box. It offers a cloud programming model, with familiar
|
2019-08-23 14:22:47 -07:00
|
|
|
languages, for expressing your cloud infrastructure and application needs. By expressing them using Pulumi, you
|
|
|
|
get a robust and repeatable deployment model, that works in a team environment. Pulumi was also designed to
|
|
|
|
make provisioning multiple copies of your infrastructure of application trivial, whether this is to bring up
|
|
|
|
new regions for your existing system, new environments (staging, prod, and test), or to ease testing.
|
|
|
|
|
|
|
|
Finally, Pulumi is [open source](https://github.com/pulumi/pulumi) and community-driven. So, to the extent that there
|
|
|
|
are custom needs, it is possible to make those customizations required, just like it would be with home-grown solutions.
|
|
|
|
For most customers, Pulumi replaces their custom solutions without any customizations necessary, but knowing that this
|
|
|
|
is an option should help know that Pulumi will be available in the long-term, and can evolve to meet your growing needs.
|