As your IT operations team moves toward an integrated DevOps methodology, it needs to ensure compliance with internal standards and cost controls by monitoring and tracking the infrastructure services that the development team uses.
Transparent operations can help. In this model, dev teams consume infrastructure and platform resources directly from application lifecycle tools, and operations teams can track those subscriptions to monitor infrastructure costs and usage.
Using transparent ops is vital, regardless of where you are in your DevOps journey.
Transparent ops: Why you need it
What DevOps means for the relationship between developers and operations teams is not always clear. Development teams, under enormous pressure to release software more frequently, tend to go around the control mechanisms that IT operations teams have in place. They consume infrastructure and resources in a manner that operations teams cannot control.
One obvious way that IT ops can lose control is if the dev team goes directly to a cloud service provider for the infrastructure it requires, but much the same effect can result even if dev uses IT's self-service portal. For instance, if the dev team requests 25 virtual machines of a particular configuration and the operations team responds by provisioning the machines with just the operating system image on them, ops will have no more insight into how those resources are used than it would have had if dev had used a cloud service provider.
Whether teams use a cloud service provider or the IT self-service portal, there are three distinct disadvantages.
1. Inability to verify compliance with internal standards. If your ops team delivers machines with only the operating system intalled on them, it will not know if the application servers and the database servers that the development team is using are compliant with organizational standards. And it will have no idea what versions of software the development team is using or whether the software and tools have been properly patched against security defects.
Similarly, when developers consume directly from a cloud provider, the operations team has no visibility into the machines, the applications, and the databases that the developers are using to build software. Ops can never be certain if the development team is using the same things that the IT operations team is using.
2. No visibility into infrastructure utilization efficiency. Moreover, when operations teams have only limited control over the infrastructure and platform services dev teams consume, they don't know how efficiently the resources are being utilized. If dev subscribes to a cloud-based machine for six months, how do you know if it is using it all the time, one week every month, or one day each month? How do you know what sort of return on investment the organization is getting? And even if the machine is borrowed from IT ops, you have no visibility into utilization levels and you don't know when the resource will be released back into the pipeline.
3. Lack of cost control. Finally, developers who procure IT infrastructure directly from a service provider are unlikely to see the benefits of scale that the IT ops team has when procuring infrastructure services. A dev team that approaches Amazon Web Services or Microsoft Azure with a request for 25 machines with a particular configuration doesn't have the same negotiating leverage as an IT ops team that needs 1,000 configured machines.
The solution: Use an IT ops-hosted service catalog
Instead of offering a traditional self-service portal, consider offering developers the ability to request and consume cloud services from an IT operations-hosted service catalog. Operations can then track the consumption of those services by way of show-back reports and other mechanisms.
Instead of provisioning bare infrastructure, ops teams would create precertified templates for application servers, database servers, and other platform services across the organization. As long as development and testing teams deploy using those templates, the ops team needn't worry about patches, versions, and lifecycle management.
Transparent ops is about having a cloud management platform that provides a self-service portal and catalog for brokering services right from your software development pipeline. Developers can subscribe to it on demand and release it when they are done. They can subscribe to precertified machines at any point in the application development lifecycle.
With this approach, a tester in the QA phase can subscribe to a service that has been precertified by the operations team, test the application immediately, and then release the machine back into the pipeline at the end of the workflow.
Transparent ops: The start of a beautiful DevOps relationship
With transparent ops, your operations team can broker and aggregate services regardless of where those services are coming from, and it can provide them through a self-service catalog. It can determine what templates it will use behind the scenes and can precertify that all deployments are consistent and compliant.
A close relationship between ops and dev is critical to implementing an integrated DevOps methodology. Moving to transparent ops is key to making that transition a success.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
