Thread by @lizthegrey

Next in the #devops track at #gluecon: @lindydonna on using code to accomplish immutability!

What if we could just use real code rather than domain specific languages for immutability? What are the advantages of this approach? [ed: p.s. I'm super excited to have met her in person finally!!!] #gluecon

Previously worked at Azure on Azure Functions. Letting people be really productive using serverless offerings.

Where did people struggle? Doing deployments in repeatable fashions. The problem is not the atoms of code, it's deploying the dependency graph. #gluecon

Example: your cloud function won't work if a storage bucket it depends upon doesn't exist yet. This isn't just a problem with Azure, it's a problem with all cloud platforms. #gluecon

People no longer have just 4 services to think about, and the way we build apps has changed to using managed services rather than self-managing on top of raw VMs. #gluecon

.@lindydonna doesn't think "serverless" is a meaningful term; "servicefull" is a better way of thinking about it.

Instead of using raw VMs, we're just using higher level abstractions on managed services. #gluecon

Application developers have to understand the cloud. [ed: standing ovation]. Your ops team won't do this for you. The burden is on *you* as an app developer. #gluecon

People are being given business directives to just use the cloud services rather than writing it themselves. But people struggle because of boundary between how appdev and devops think about the cloud.

Who manages your managed services? #gluecon

"The console is a technical debt generator" -- friend of @lindydonna. [ed: yes yes yes]. Every time you do a bespoke cloud console operation, you have something that's now non-reproducible. #gluecon

The tutorials don't tell you that because they *want* you to have techdebt, they tell you to use a web UI because they don't want to scare you off with YAML. #gluecon

There's a disconnect between experienced DevOps people that say "of course you should do it with config" and people new who are afraid and want to use the console.

Why is this? Because config languages are hard to use and require very specific custom syntax. #gluecon

The best in class tools are still based on the idea of using a DSL. Terraform gives you a higher level model but lacks loops, conditionals, and models. And it's still considered best practice.

There's a class of people turned off by learning curve of config languages. #gluecon

People wind up specializing and being pigeonholed into being the 'terraform experts' who wind up doing just that job and everyone else blocks on them. [ed: I'm now recognizing this pattern in one of my clients...] #gluecon

They also don't promote code reuse. People wind up copying and pasting rather than refactoring to common code.

We use code as the template for every new project we start, then we can't fix it in one place. #gluecon

We don't tolerate cut/paste in application code. Why do we tolerate it in config?

Your code reviewers wouldn't tolerate you copy pasting an entire NPM module into your code. #gluecon

Defining infrastructure in JavaScript or Python and transforming it into declarative plans is the best of both worlds.

Common language and toolchain between operators and developers. #gluecon

Move people towards everyone being empowered to deploy infrastructure rather than one or two "experts" on a team. #gluecon

[ed: you'll get some... interesting stories, both positive and negative, if you ask Google SREs about how we use vanilla-ish Python to configure Monarch.] #gluecon

500 lines of cloudformation to develop a "simple" service winds up missing abstraction because it doesn't match how we think about the problem. No hierarchy/decomposition, just tons of low level assembly-like code. #gluecon

"Your tutorials on how to do basic setup of your dependencies should not be so complex that they require a congratulations message at the end." --@lindydonna #gluecon

We need to abstract our low level building blocks into common patterns that we can instantiate. Use libraries/packages in a real programming language instead. #gluecon

If you do this right, you don't need to do specialized toolchain work to support your DSL, because the native toolchain of your real language will do documentation/completion/typechecking/etc. for you. #gluecon

Giving someone a graphical console for the raw building blocks (or even an API to do the raw building blocks) is insufficient. Reusable and customizable libraries around the API are what you really need. #gluecon

And if you're sneaky and clever, you can make your application code check if its dependencies exist, and launch its dependencies on the fly using the libraries for talking to the cloud provider! #gluecon

Separation of the config from the application code is a purely artificial construct. [ed: this is making me think about the fact that all the production DSLs at Google that aren't already Python dialects rapidly become Turing-complete, but w/ custom syntax] #gluecon

Adding steps into your pipeline needs to be modular rather than procedural.

Should every person need to know how to provision a new pubsub topic, and wire up a new service to push to a ML service and receive results? Ugh. Of course not. So you need a library. #gluecon

If you've done it right, it's *easier* to stand up a new instance via pulling in a library and plugging in your code than doing the clicky clicky work in the web console. Give your developers the right incentives, so they do things the immutable, reproducible way. [fin] #gluecon

[and there was a cool cat picture/video demo].

[ed: it's a super pitchy talk, but I happen to *love* where they're going and think it brings the public world to where Google SREs have been for a while so it's hard for me to mind the pitchiness.] #gluecon

[ed: because, oh goodness, I *hatehatehate* seeing people use the console to provision more than toy resources, and I *hatehatehate* seeing SRE pigeonholed as "the people who do terraform" so any way forward is great] #gluecon