There's something new on the horizon, taking the principles of devops to a new area. It's called infrastructure as code (IaC), and it's how you configure cloud-based infrastructure via applications, using APIs.
This is a hard turn from the old days of configuration management, with sys admins controlling the platforms on behalf of developers.
There are compelling reasons for this new approach:
- Applications are now configurable for only the platform resources they need, programmatically. You can allocate the right amount of storage, memory, and processor instances. There is no more adapting the applications for the limitations of the platform; you can make the platform anything you want.
- The costs should drop for each application, considering you use only the resources you need. (If you check server utilization at any data center, you'll see it's typically less than 3 percent. The excess capacity represents wasted dollars.)
- You don't need as much management and operations resources, both people and technology. You give up control to developers, so those items are now redundant.
The larger question: Is passing control of the infrastructure to developers a good thing? You bet. With the rise of devops and its tight coupling of developers and operations, the ability for developers to dynamically configure their deployment platforms via APIs is a better way to manage many applications and many platform instances.
You can now match platforms to applications, one to one. This is different from the past, where developers had to accept whatever platform was set up, then fight for any necessary configuration changes.
That said, this new approach requires culture change. People who are part of legacy processes and roles won't easily accept this new process, and I suspect they will push back hard on IaC. However, organizations will discover that IaC works better, and the old guard will need to adjust. This notion simply makes sense.