DEV Community: Daniel Hagen

DevOops, We've Done It Again: The Continued Silos Between AppDev and Ops

Daniel Hagen — Mon, 21 Apr 2025 14:38:38 +0000

Remember when DevOps was supposed to break down walls?

It was a movement, not just a methodology. A promise that developers and operations would finally work hand-in-hand, shipping value faster, safer, and smarter. No more throwing code “over the wall.” No more ops folks getting paged at 2AM for things they had no hand in building.

Instead, we got a new title.

“DevOps Engineer.”

And just like that… the wall was back.

The Original Vision

DevOps was born out of frustration:

Developers couldn’t ship without Operations.
Operations couldn’t support what they didn’t understand.
Releases were painful, manual, and filled with guesswork.

Then came infrastructure as code, pipelines, and continuous delivery. Suddenly, a single engineer could deliver a full slice of value—code, infrastructure, monitoring, tests—all the way to production.

For a moment, we were living the dream:

Cross-functional, empowered product teams with shared ownership.

Then Came the "DevOps Engineer"

But instead of enabling developers to own more, we added a middleman.

“Let’s hire a DevOps engineer.”

Which usually meant:

An Ops engineer in a new costume, still the one holding the pager, managing the CI/CD pipeline, and maintaining the Terraform modules.

Meanwhile, app devs kept shipping code and creating tickets.

We recreated the wall—just with shinier tools and cooler job titles.

DevOps ≠ Ops++

Let’s be clear:

DevOps is not a team. It’s a cultural shift.

It’s about shared responsibility across development and operations. Not shifting the burden. Not offloading hard things.

Yet here we are—again—with DevOps engineers doing Ops work, and app devs waiting for green pipelines. Silos have returned, just with new labels.

Enter Platform Engineering

And now we’re seeing the rise of Platform Engineering.

Done well, it’s a game-changer.

Done poorly, it’s DevOops 2.0.

The idea of an internal developer platform is powerful:

Common paved paths
Certified infrastructure modules
Golden pipelines
Reusable patterns

But let’s be careful.

A platform is not a team that takes responsibility away.

It’s an internal product. A practice. A self-service toolbox built with empathy.

Platform engineering should be inner-sourced, not offloaded.

Built alongside the teams using it, not in a vacuum.

Treat it like an internal cloud with APIs, docs, support, and SLAs.

Not like a vending machine where developers throw a ticket and wait.

Embracing the Cognitive Load

Yes, understanding application development and infrastructure is hard.

And yes, cognitive load is a real problem.

But here’s the thing:

Avoiding it doesn’t solve the problem—it just shifts responsibility.

When developers sidestep infrastructure and delivery concerns, that burden doesn’t disappear.

It lands on someone else’s plate—usually a DevOps or Platform engineer—who may have less context about the app, its dependencies, or its business logic.

We shouldn’t run from the hard stuff.

We should build shared muscle around it.

Owning infra doesn’t mean being on-call 24/7.
Writing pipelines doesn’t mean reinventing Jenkins from scratch.
Understanding how your code hits production doesn’t require mastery—just participation.

We don’t need every developer to know everything. But we do need every developer to care.

And caring means being willing to engage with the system holistically—from pull request to production, from cloud resource to customer value.

The Last Excuse: Gone

Let’s be honest—part of what sustained the silos was the belief that no one could possibly do it all.

"I’m not an infra person."
"Pipelines aren’t my thing."
"I just want to write frontend code."

But now?

AI has leveled the playing field.

With tools like:

GitHub Copilot filling in code scaffolding,
Cursor guiding development in real time, and
Agentic tools like Windsurf orchestrating complex workflows…

…we no longer have the excuse that one person can’t manage the full stack.

AI isn’t replacing engineers. It’s amplifying them.

A single engineer, with the right mindset and tooling, can:

Build infrastructure as code
Deploy a service with observability baked in
Write tests, pipelines, and documentation
Ship product faster than a team of siloed specialists ever could

We’ve never been more empowered to deliver end-to-end.

Now is the time to lean into true ownership—with AI as our co-pilot, not our crutch.

The DevOps We Were Promised

It wasn’t just about YAML, Terraform, or CI/CD.

It was about empowered teams delivering value with autonomy, confidence, and shared accountability.

We’ve come too far to go back to throwing things over the wall.

Let’s stop saying DevOps and doing Ops.

Let’s build the future we signed up for.

What’s your experience been like? Are you building platforms that enable—or isolate? Have you seen the cognitive load turn into a team’s superpower? I’d love to hear how others are navigating this.

DevOps #PlatformEngineering #FullStack #InfrastructureAsCode #AIEngineering #TeamCulture #DeveloperExperience

AWS Amplify, Secured DevOps - Part 2, Regenerate

Daniel Hagen — Wed, 08 Dec 2021 04:37:16 +0000

Ok, so if you've read Part 1, you know that you should protect the aws-exports.js file. The first method I will show is using only AWS Amplify tools.

Why store it when it gets generated every time, right? In part 1, I mentioned that amplify init, amplify pull, and any amplify add <feature> or amplify remove <feature> will cause the aws-exports.js file to be recreated.

I've committed the source tree on several projects with dependencies on src/aws-exports.js, which will more than break the build if it doesn't exist.

So let's say that you're on your laptop. You've successfully amplify init to create your environment or used the AWS Amplify Studio UI to set up your environment and then run amplify pull --appId <snip> --envName dev. You've got your src/aws-exports.js setup, and you're building locally. You commit your code in and move over to your desktop, and pull your code down. But running dev breaks, src/aws-exports.js doesn't exist.

It's pretty straightforward. We're going to run amplify pull --appId <snip> --envName dev again to have it pull down all the backend settings and generate your src/aws-exports.js for you.

A quick note there, if you added a feature on your desktop, let's say new storage (S3) for the application, the next time you commit and switch to your laptop, you'll perform another amplify pull to get back in sync. You can always run amplify status to see if you are up to date against the deployed version.

Now let's talk builds and CI/CD. One of the most fantastic features that you get pretty much out of the box in Amplify is a complete CI/CD pipeline. I'll look at doing a dedicated post for that feature, but I'm going to leave the details out of scope for now. The big thing that I want to point out is how it to can generate the src/aws-exports.js

Each build is executed inside a container in the AWS build environment; it inherits the IAM role provided, which allows it to authenticate to the Amplify framework and pull down the settings. This permission configuration happens by default with the default build settings. In Part 3, I'll show you how to override or specify these settings using Environment Variables.

The key to this, though, is to think of it as doing a amplify pull at the beginning of every build. If you're modifying your aws-exports.js file (you never should), those modifications will not make it in this build. If the backend had changed and you didn't amplify pull before developing, validating, and committing, your backend references may be out of sync.

AWS Amplify, Secured DevOps - Part 1, Why It Matters

Daniel Hagen — Mon, 06 Dec 2021 17:57:56 +0000

Well, fresh off an awesome AWS re:Invent, I wanted to put out a short series of posts about a common issue I run into talking with people about CI/CD. These posts center around the aws-exports.js that the CLI will generate when initializing or pulling from the Admin/Studio UI. If you're unfamiliar with this, I'd recommend starting at the Getting Started section of the AWS Amplify Documentation.

What is inside the aws-exports.js file that makes it such a big deal, and why do we exclude it in the first place?

First, you have to understand why committing credentials into a source code repository is generally seen as a bad idea. For a good read on this, take a look at Why storing secrets and passwords in Git is a bad idea. TL;DR: It's not a good idea, don't do it.

So with that established, let's look at the aws-exports.js file:

// WARNING: DO NOT EDIT. This file is automatically generated by AWS Amplify. It will be overwritten.

const awsmobile = {
  aws_project_region: 'us-east-1',
  aws_cognito_identity_pool_id:
    'us-east-1:<SNIP>',
  aws_cognito_region: 'us-east-1',
  aws_user_pools_id: 'us-east-1_<SNIP>',
  aws_user_pools_web_client_id: '<SNIP>',
  oauth: {
    domain: '<SNIP>',
    scope: [
      'phone',
      'email',
      'openid',
      'profile',
      'aws.cognito.signin.user.admin'
    ],
    redirectSignIn:
      'https://<SNIP>,<SNIP>',
    redirectSignOut:
      'https://<SNIP>,<SNIP>',
    responseType: 'code'
  },
  federationTarget: 'COGNITO_USER_POOLS',
  aws_cloud_logic_custom: [
    {
      name: 'AdminQueries',
      endpoint: 'https://<SNIP>.execute-api.us-east-1.amazonaws.com/dev',
      region: 'us-east-1'
    }
  ],
  aws_appsync_graphqlEndpoint:
    'https://<SNIP>.appsync-api.us-east-1.amazonaws.com/graphql',
  aws_appsync_region: 'us-east-1',
  aws_appsync_authenticationType: 'AMAZON_COGNITO_USER_POOLS',
  aws_appsync_apiKey: '<SNIP>'
};

export default awsmobile;

Just look at all the places I removed information and put in <SNIP>. If you wouldn't post it in a Dev.To blog post, here's a good rule of thumb, you probably shouldn't commit it.

While SPA and some SSG apps might end up embedding some of these values, generally, these are keys and values that the end-user should not get ahold of, or they could start running attacks on your backend surfaces.

Imagine someone getting the aws_appsync_apiKey along with the aws_appsync_graphqlEndpoint and just starting to DDoS or brute force their way past your auth. Or just overall knowing what the architecture for your application backend is. The less information the attacker has, the slower and more challenging it is to get in and do bad things.

Now, let's talk about what generates aws-exports.js. Like I mentioned at the beginning when you launch amplify init or run amplify pull with the variables given from the Admin/Studio UI. When you first run those commands, it will ask you where your source folder is (default is /src), and it will generate this file in that folder. Every time you run amplify pull from then on, it will regenerate the aws-exports.js file with any changes on the backend. It will also regenerate if you use amplify add <feature> with those features' security details.

Amplify will, by default, exclude aws-exports.js in the .gitignore file. Here is an example of a .gitignore file I had locally:

#amplify
amplify/\#current-cloud-backend
amplify/.config/local-*
amplify/mock-data
amplify/backend/amplify-meta.json
amplify/backend/awscloudformation
build/
dist/
node_modules/
aws-exports.js
awsconfiguration.json
amplifyconfiguration.json
amplify-gradle-config.json
amplifyxc.config

If you didn't read the linked article earlier, you might be inclined to remove these lines and commit these files anyway. I hope you don't.

Lastly, this aws-exports.js file is what you're going to use to configure your Amplify Libraries SDK in your project. Eventually, I'll add an "aws-modifications.js` tutorial for a simple trick I use for modifying that file in runtime.

Hopefully, that gives you a little more idea of what is going on under the hood and why you don't want to break it. Next, I will show you a few real-world scenarios that I've used for dealing with these and other security values. Keep an eye out for Part 2.