Skip to content

Fixing possible odd word choice for end of sentence #4

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
natebru wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Fixing possible odd word choice for end of sentence #4

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion manuscript/introduction.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -72,7 +72,7 @@ This is a question we get asked a lot. As more and more workloads start running

**Legacy**. Ephemeral workloads might be the Now Hotness, but we all have (and likely always will have) workloads that require a lot of delicate configuration, need to run in their own VM, and are special snowflakes. DSC can be great at helping to keep these properly configured. You might not ever use DSC to initially build one of these serves, but you might well use it to help control configuration drift on them.

**State-Coupled**. We all have plenty of workloads where the configuration of the workload itself--it's "state," if you will--is part of its install. That is, perhaps the data used by the workload is elsewhere, but the workload's identity and "bootstrap" code is part of the "system drive." Think Exchange Server, SharePoint Server, and SQL Server. These are "kinda special snowflakes" in that they're difficult to rebuild, and by their very nature you wouldn't just tear them down and rebuild them all the domain. Domain controllers fall into this category, because can you imagine the replication workload if you just tore down half your Dns and built them from scratch every night? DSC can also be good at maintaining configuration on these workloads.
**State-Coupled**. We all have plenty of workloads where the configuration of the workload itself--it's "state," if you will--is part of its install. That is, perhaps the data used by the workload is elsewhere, but the workload's identity and "bootstrap" code is part of the "system drive." Think Exchange Server, SharePoint Server, and SQL Server. These are "kinda special snowflakes" in that they're difficult to rebuild, and by their very nature you wouldn't just tear them down and rebuild them all the time. Domain controllers fall into this category, because can you imagine the replication workload if you just tore down half your Dns and built them from scratch every night? DSC can also be good at maintaining configuration on these workloads.

We do _not_ see a world where DSC is running on _every single computing workload you own_. The trick is in finding the right place and time, and using the tool how it was intended to be used. Nobody's taking a Camry to an F-1 race, but nobody's saying a Camry is a bad car. You just need the right tool for the workload at hand.