 |
VOOZH | about |
|
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
Once upon a time, provisioning a new server meant waiting weeks for physical hardware to arrive, then manually installing and configuring the operating system over a matter of days. The evolution to virtual machines (VMs) meant that servers could be spun up in minutes, ushering in welcome efficiency. Tools like Ansible, Puppet and Chef then came on the scene, introducing infrastructure automation. The emergence of cloud computing later demanded a new crop of infrastructure tools, like Terraform and Docker. Most recently, the shift to microservices and Kubernetes has spurred the arrival of tools like Crossplane and Pulumi. At each stage of this ever-continuing evolution, new infrastructure automation tools have served a single ultimate purpose: enabling faster application delivery.
But one of the biggest challenges for developers right now is the time-consuming complexity of automating application deployment across multiple infrastructure platforms and their associated tools. While new born-in-the-cloud companies use cloud native technologies and workflows out of the gate, the majority of established companies are still a major transformation away from fully implementing advanced approaches like Kubernetes or GitOps. Instead, most still use on-prem or cloud VMs to run applications. Doing so requires that developers deploy applications to work with multiple continuous integration (CI) pipelines, and multiple Terraform or custom scripts. Supporting applications post-deployment is, well, just as complex.
Today’s developers grapple with multiple complex application deployment pipelines, as in this example.
This complexity and poor application control slows development speed, limits application support and drives friction between developer and operations teams. Complexity only grows as an organization’s environments, development teams and applications do, rendering these challenges increasingly difficult.
Organizations commonly focus on control planes that automate provisioning for infrastructure and services, with DevOps teams adapting automation tools for application deployment. For example, organizations implementing Kubernetes and GitOps will need to build new pipelines, security controls, etc. These efforts quickly feed tool sprawl, disunity in application controls, and discord between developers and the platforms and DevOps teams they view as obstacles.
Many organizations then try to keep up with this complexity by throwing resources at it, namely additional expensive tools and expanded staff. Building internal developer platforms (IDPs) are an outsized example of this. The intention with IDPs is to abstract infrastructure and empower developers to ship and support applications faster. In practice, however, a developer dashboard doesn’t solve complexity or provide core business value to customers. IDPs are often left to rot after years of wasted investment, regular downtime and insufficient security.
A better approach focuses on the application layer itself: Build a common application operating model.
An AppOps model allows developers to deploy and manage their applications in the same way, no matter what control plane — Kubernetes, VMs, etc. — supports their projects and pipelines. By doing this, DevOps can change control planes as necessary, without any impact on developer activities. Organizations should have the flexibility to plug any platform across their existing stack into the application operating model, making it a standardized solution. DevOps is then able to define security and controls using this centralized control layer, automatically enforcing those controls on every deployed application and removing that burden from developers. Lastly, a common application control model should use available infrastructure to automatically create all the resources that applications require.
AppOps — providing the automated infrastructure and application layer to meet an organization’s actual goals for accelerating application development — should be viewed as a category and not a singular tool. Like the waves of automation achieved with the arrival of VMs, cloud computing and microservices, the emergence of AppOps can usher in a new crop of transformative solutions. Adjacent to continuous integration, application performance management, application security and other categories, AppOps should seamlessly enable velocity, security and control in a unified operating model designed to drive application development.
The prediction that Kubernetes will disappear into a transparent tool that no longer burdens developers with its complexity speaks to the possibilities of AppOps. For developers working to deploy, manage, support and secure their applications, AppOps can make the underlying infrastructure, CI pipeline and control plane invisible and irrelevant.
As this approach evolves, AppOps promises to operationalize away the chief infrastructural distractions that limit developer productivity, finally enabling the full developer focus on development that the industry has long pursued.
To learn more about AppOps and other cloud native technologies, consider coming to KubeCon+CloudNativeCon North America 2021 – Oct. 11-15.
