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:
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 …
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 …
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!
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.
Serverless Best Practices for Evolving Applications
Enabling Serverless in the Enterprise
And Enterprise IT gets to figure it all out …
What to look for at re:Invent and what's next for serverless