Turtles, Grilled Cheese, and Innovation All the Way Down

Getting the developer and operator workflows right is a key success factor in the next wave of cloud adoption and innovation

Tim Zonca

This week touted a number of great re:Invent talks, especially around serverless best practices. But it was a section of David Richardson’s session that really grabbed me. As the VP of Serverless, of course David did a great job using customer stories and speakers from the BBC, Capital One, Coca Cola, and Discovery Golf to demonstrate the value of serverless. But it was the tail end of the presentation—where he focused on changing roles that are required as organizations evolve their cloud practices—that I outline here.

In this post I highlight how:

  1. Roles are changing as organizations move to the cloud.
  2. Organizations are evolving to deliver developer autonomy and centralized governance.
  3. Infrastructure-as-code (IaC) empowers collaboration and unlocks best practices for teams developing, delivering, and running modern applications.

Screen_Shot_2020-12-16_at_11.15.27.png

Roles are changing as organizations move to the cloud

As cloud technologies evolve—especially as more powerful abstractions are created—we see roles evolving. Operators are becoming more development savvy. Application developers are being more operations - and infrastructure-minded. In fact, most of the engineering teams I talk to are responsible for delivering and running the applications they build. And, infrastructure engineers are helping create modern cloud platform teams (or evolve traditional release teams to support more modern practices). In every case, these roles are evolving.

Though there are different patterns to accommodate for organizational idiosyncrasies, there is one common thread: those that shape their new roles most successfully place a premium on strong collaboration across teams. Specifically, that establish clear understanding of what they expect from supporting roles (like what a developer needs from a cloud platform engineer), and what the others should expect of them.

One of the biggest areas that needs a shared understanding as roles evolve is how do teams resolve the tension of developer autonomy and centralized governance …

Organizations are evolving to deliver developer autonomy and centralized governance

Balancing developer speed with enterprise scale and governance has become an age-old challenge. One of the common pattens David highlighted is around the role of the team responsible for providing developers with modern, secure, and scalable platforms. We usually see these shared services teams called a Cloud Center of Excellence, a cloud platform team, a DevOps team, and other similar variants. In any case, though, these teams are responsible for providing consistent, secure, updatable application platforms—in a way that accelerates autonomous development, rather than hindering it.

One of the common foundational practices for unlocking autonomous development, in a way that works for these centralized teams, is to treat infrastructure as code. Let’s dig into why this practice is so powerful—and necessary in modern development …

Infrastructure-as-code (IaC) empowers collaboration and unlocks best practices for teams developing, delivering, and running modern applications.

David was spot on when he said, that a “core approach for collaboration is Infrastructure-as-code.”

Why? Because it gives operators and infrastructure engineers a way to architect, build, provision, operate, and update infrastructure just like a developer does.

For decades developers have been able to version control their work, have peers review it, automate testing and delivery … and a whole lot more. But before infrastructure-as-code was a thing, there was no easy way to version control infrastructure. You can’t check in a server, or unit test a switch like you can application code.

But when you treat infrastructure as code, it unlocks agile and collaborative development practices that have been proven for decades.

Today operators, administrators, infrastructure engineers can describe their platforms in a way that allows them to adhere to development best practices. What’s more, it allows them to communicate with developers in a way that makes sense to them. All roles now have the same practices and tools at their disposal, making collaboration across teams much more seamless than ever before.

One of the most massive—but least understood—benefits of serverless is that describing infrastructure as code is a requirement. Not just a recommended practice. This powerful collaboration device is embedded in the foundation of a serverless approach!

Summary

One of the most poignant quotes what when David said, “Getting the operator and development workflow right is critical. If you get it wrong you’re back in old days of Central IT as friction.”

There is no single practice or technology that unlocks this, rather a mix of technology, workflows, and collaborative practices that help teams get the operator and development workflows right. But technologies like serverless (that make adopting a best practice like infrastructure-as-code), and new innovation like AWS Proton (that helps central teams support developer speed and autonomy while enforcing modern security and governance best practices) are just a couple examples of how AWS helps team modernize and succeed in the next era of cloud adoption.

DEMO STACKERY

AND COFFEE ON US!
Join uscoffee graphic

UPCOMING EVENT:

AWS LAMBDA CONTAINER IMAGES

JAN 27 | 12 PM PST

REGISTER TODAY

Learn More

Quick links to get familiar with Stackery

Related posts

Strengthening Your Security Posture
ReinventStrengthening Your Security Posture

Serverless Best Practices for Evolving Applications

Serverless for the Enterprise
ReinventServerless for the Enterprise

What to look for at re:Invent and what's next for serverless

Curious about Stackery and its capabilities?

Learn more