Even before moving into a DevOps role I always found the topic of DevOps an interesting one and spent time researching, reading, and investigating DevOps approaches and practices and still always take the opportunity to learn more when I can and see what other organizations are doing.

I was recently on the panel at a technical event and a discussion took place around the publicized success stories from other organisations and how these can be frustrating to organisations just starting out on their DevOps implementation when things aren’t going to plan. I found this interesting as I think it’s easy to forget that although some organisations have had DevOps in place for years with a very mature operation, others are just starting out and the discussions that followed raised a great point; organisations may publish a success story but how many times did they fail before they eventually succeeded?

For me, this is really key and something I have related to many times when looking back at where PA Media Group was to where we are now. I always hold a meeting with my team at the end of each year as we start to wind down for our Christmas change freeze and we use it as an opportunity to look back over the previous 12 months, looking over our achievements and failures and understanding what we can learn from them and what direction the team should take going forward.

I don’t think you should ever be afraid to fail, as usually if you don’t fail you aren’t trying new challenging concepts, but you should use it as an opportunity to learn from it, understand what went wrong, know when to accept that an idea or plan has failed and enjoyed the successes when they do happen.

These factors led me to think ‘is there a right or wrong way to implement DevOps?’

When thinking of DevOps the first thing that always springs to my mind is ‘culture’ and at PA Media Group we have tried to use DevOps as an enabler to assist in creating a culture of collaboration and cross-functional working. PA Media Group use Development squads made up of multi-skilled engineers which function well for delivering new products or feature enhancements, and although we have a dedicated DevOps team, we try to use DevOps practices, principles, its approach, and tooling across other areas of the department and a lot of our focus over the past few years has been around applying a DevOps culture within IT Operations.

We have worked to try to build a culture that is moving towards an automation-driven NoOps environment. One example of this would be building up the knowledge and skills of the organisations’ Desktop support team and moving the build and management of the desktop estate to Chef, seeing it more as infrastructure as code.

This doesn’t mean everything we have tried has been a success. We have had many bumps in the road and had to make big decisions, one of which we made a few years ago when we decided to remove the traditional style system administration role and instead created a larger DevOps team whose remit, alongside working within development squads and supporting the business, includes removing manual repeatable tasks and investigating ways to automate system and service recovery.

Fortunately, this change proved to be a good decision and we have seen great benefits from it. But as with all changes, there will always be challenges, and this was a big change. It required the traditional system administration engineers to shift their mentality and change their culture, and we lost both Sysadmin and DevOps engineers along the way. Luckily we had enough engineers who could see the benefits it would bring, but many times along this change we almost saw a failure. Had we not had enough engineers with this mentality present within the teams, then this could quite easily have been marked down as a failure for us.

Another aspect that I feel helped this change succeed was when we realised the need to try and standardise and simplify our tooling and technology choices. We moved to SaaS solutions where possible to remove the need for engineers to have a vast array of technical knowledge, to remove the need for them to carry out manual maintenance, and instead, putting the ownership and management of these technologies on the people who have the best knowledge of the product.

Our journey has since furthered and we have brought our SysOps Support engineers (the current entry point into IT Operations) closer to DevOps, giving them more freedom to learn and be involved with newer technologies such as Terraform. We have started exploring how Agile principles can be implemented within an ITIL-focused environment to complement existing processes and have moved to a Swarm support model.

This has started to increase the SysOps support engineers’ technical knowledge and we are hoping it will bring greater engagement between engineers of all levels/skillsets, increase service knowledge across all the teams, and will move us closer towards working as a single team.

We are constantly reviewing this process to understand how it’s working. Some may look at this change and see it as a bad choice, a failure waiting to happen. Why would you want multiple engineers getting held up on a Swarm call when a ticket could just be passed to one high-level engineer and be resolved at the same time?

But could keeping this mindset of just passing things over also be classed as a failure? A failure to share knowledge and upskill engineers of various levels? What we hope to see, is that we hit a peak then a downward slope in the amount of Swarm calls required, or a reduction in the length of time Swarm calls run for, but only time will tell if this is successful or is marked down as a failure.

Looking back at one of the original questions ‘is there a right or wrong way to implement DevOps?’, then no I don’t feel there is. The right way is one that works for your organisation and I don’t believe there is a ‘one size fits all’ approach. Just because Swarm has worked within other organisations, it doesn’t mean it’s guaranteed to work for us. The same as just because removing our System administration team worked for us, doesn’t mean it will everywhere else. Businesses vary in so many ways and every IT Department has different technologies, levels of engineering skillsets, and budgets.

So every approach should be different, this isn’t to say that what one organisation does won’t work within your organisation. To me, DevOps should be what you want it to be and you should take the approach of making sure it is right for your business model. You shouldn’t get down heartened if you try something that worked somewhere else and it fails within your organisation!

The old saying, “Water water everywhere, not a drop to drink,” is so apt. When you are in the middle of an ocean surrounded by water all around but because of the salinity of the water, you are unable to drink it. The same can be extended to the amount of data available today. I draw a corollary from this saying and modify it in the context of the data — “Data data everywhere, not a place to store.”

With the percolation of internet in the lives of all and the rapid digitisation across the world, it has practically become impossible to have a tape storage, magnetic storage or any mode of storage to be sufficient enough to cater to the needs of data storage and further its processing. Gone are the days when you were required to have the data with you for you to use it. Today is the era of cloud storage and data availability is “on-the-go.”

What is cloud computing?

Cloud computing is the usage of different services on the internet for performing operations such as storing, managing and processing data on a common storage that can be accessed from anywhere rather than one particular system. Instead of being stored directly on your own personal device, cloud-based data is stored on servers owned by companies such as Amazon, Microsoft and Google and is made accessible to you via the internet. Whether you are accessing your Gmail or streaming your movies through Netflix or listening to your favourite songs on Spotify, you are a customer of a cloud services provider.

This data owned by the user is stored physically on a server of the service provider and is maintained by the third party and can be accessed by a person having the security credentials. This is a disadvantage. However, by proper security and passwords, the data can be given some security.

It is not essential that only the known names own these cloud infrastructures. Cloud computing may be public, private and hybrid depending on the user’s needs. A private cloud refers to a cloud entirely owned by an organisation and all the computing resources are exclusively used by the employees and customers of the organisation, usually over the internet or over their own private networks. In contrast, Public clouds are owned and operated by a third-party cloud service providers and Hybrid clouds combine public and private clouds by technology that allows data and applications to be shared between them.

The type of Cloud services may be SaaS (Software as a Service), PaaS (Platform as a Service) and IaaS (Infrastructure as a Service). PaaS is designed to make it easier for developers to quickly create web or mobile apps, without worrying about setting up or managing the underlying infrastructure of servers, storage, network and databases needed for development. Software as a service is a method for delivering software applications over the Internet, on demand and typically on a subscription basis.

With SaaS, cloud providers host and manage the software application and underlying infrastructure and handle any maintenance, such as software upgrades and security patching. Users connect to the application over the Internet, usually with a web browser on their phone, tablet or PC. The most basic cloud computing service is IaaS wherein you rent IT infrastructure such as servers and virtual machines (VMs), storage, networks, and operating systems from a cloud provider on a pay-as-you-go basis. The most popular IaaS is Microsoft Azure and Amazon Web Services (AWS).

Is cloud computing truly a future technology?

Cloud computing provides a cost-efficient way of storing data by eliminating the capital expenses of buying hardware and software and setting up, running and maintaining on-site data centres. It also enables delivering the right amount of computing power, storage and bandwidth that too as per the requirements of the user. The access to data is on-the-go and you as a user are literally carrying your data wherever you go thus making the data availability more robust and lesser prone to device crashes.

One of the key characteristics of cloud computing is that the reliability factor is extremely high as the data is generally mirrored at multiple redundant sites on the cloud provider’s network instead of concentrating at a single location.

With businesses going online and more organisations moving to cloud platforms, it’s important to guarantee that cloud service providers can make a secure framework to ensure the wellbeing of their customer’s information. When storing data in cloud, it is stored in not just one data server but on multiple servers of the network. This reduces the chances of data getting lost. If it’s not available on one data server there is always a chance that it will be present in another server. When data is stored together, the cost for its security and maintenance is low, otherwise its very expensive to guard and protect the data from hazards. It eliminates the down time as it takes care of patching.

Is cloud computing just part of an engineering course?

Cloud computing is a specialised field of study today which finds its mention in courses ranging from computer science and engineering to civil engineering and physics to chemistry. It provides a platform for advanced technical knowledge in various fields of study and universities today are offering specialisations at undergraduate, post graduate and doctoral level in cloud computing.

The need for people qualified in various aspects of cloud computing be it full-stack cloud developers, cloud solution architect, cloud security engineers, cloud consultants, cloud service developers, development operations engineer, cloud system administrator, cloud data engineer, information technology architect, cloud network engineer is in great demand.

According to Forbes, there are more than 18 million jobs in cloud computing available worldwide. Realising the power, ease and potential of cloud computing, the top Indian companies too are transitioning from traditional data-based approach to cloud-based applications thus causing a surge in the demand of cloud computing professionals.

CUPERTINO, Calif.–(BUSINESS WIRE)–Indium Software, a leading digital engineering solutions company, announced today that it has achieved AWS Select Consulting partner status. Amazon Partner Network Consulting Partners help customers design, architect, build, migrate, and manage cloud solutions built on AWS.

With experience from 150+ App Migration/Modernization, 20+ Petabytes Data Migration, 70+ Cloud-native App & SaaS development, and 250+ CI/CD pipelines; Indium provides deep technical and domain expertise required to help customers build digital extension of their core business and increase customer intimacy. Armed with AWS partnership and home-grown IPs on Text Analytics and Digital Assurance, Indium is well suited to deliver continuous digital improvements and help customers realize the full potential of their business applications and data on AWS.

“Indium has been at the heart of digital transformation for customers ranging from Fortune 100 to innovative start-ups, across 4 continents. This AWS partnership enables us to offer an end-to-end customer experience – consulting, system integration and AWS-based vertical solutions – and add scale and velocity to customer’s digital and AWS journey,” said Karthik Bala, EVP – Strategic Partnerships, Indium Software.

“Indium’s AWS-based service/solution offerings deliver value to customers, regardless of where they are in their AWS journey. Through our offerings, we help customers take advantage of cloud-native features and innovate on AWS, while maximizing their investments on AWS cost effectively,” stated Satish Pala, CTO, Indium Software.

He added that “Indium will continue to prioritize talent development, training and recruitment of AWS certified Consultants, Specialists and Architects to meet the ever-growing demand and enable continuous building of IP-led innovation, advising customers on the most efficient way to build, operate and manage solutions on AWS.”

Indium Software

Indium Software is a leading growing Enterprise Digital Transformation firm with deep expertise across App Migration/Modernization, Big Data Analytics, AI/ML, DevOps, IoT and Digital Assurance. With a team of 1,400+ associates, Indium has served 350+ clients globally from Fortune 100 to Global 5000 over the past 2 decades. Indium’s mission is to provide customer-centric, high-quality technology solutions that deliver business value.

Indium provides solutions across Banking, Healthcare & Life Sciences, Retail & ECommerce, Gaming, Education, Logistics, Utilities. Indium has operations in the U.S, India, Europe, and SE Asia.

DURHAM — Google announced plans Thursday to create a hub in Durham for hundreds of engineers working on its Google Cloud products.

The company said in a statement that it is already recruiting for the site and that it plans to employ 150 people by the end of the year. The company said it will aim to add 300 more employees next year and 500 more in 2023. The site will eventually support more than 1,000 jobs and be one of Google Cloud’s top engineering hubs.

According to the Triangle Business Journal, Google will lease space from Duke University in downtown Durham and is evaluating several locations for a permanent location.

The California-based company said in a release that the office will serve as a hub for the Google Cloud’s engineering team and will eventually grow into one of Google Cloud’s top five engineering hubs in the county, joining the Bay Area in California, New York, Seattle, and Kirkland, Washington, says TBJ.

The Google service uses cloud-based computing to help companies with a range of needs including managing databases, collaborating remotely and running business applications.

The company said it will begin by subleasing space in downtown Durham and is currently scouting other locations for a permanent home. Google also operates a data center in Lenoir and an office in Chapel Hill. Durham was one of several places around the country where Google is planning new locations.

“Today is an exciting day for Google Cloud in North Carolina. We help businesses and organizations digitally transform, and to meet this challenge, we need the most talented team possible and the Triangle region has some of the best and brightest engineers in the world,” Google Vice President of Engineering Marian Croak said in a statement.

“Powerful jobs announcement for North Carolina today: Google to bring new engineering hub to Durham, up to 1,000 jobs as part of U.S. expansion. Our state’s economic identity and success as a tech center is creating good-paying jobs in our communities,” said N.C. House Speaker Tim Moore (R-Kings Mountain).

As it is the beginning of the new year and our mail inboxes are filled with graduate students’ emails for summer internship applications. But most of the time we received this kind of emails:

This shows that the applicant has not spent a single minute to research about the company and did not even bother to address the name or greetings. So, definitely, the question which you have asked is very much relevant for an internship applicant to – How to apply for an Internship? So, here are few suggestions from my end:

• Never send blind emails in BULK.
• Target few companies and write personalized emails.
• Address the right person in the company. (Contact with someone in the company and ask them for the right person).
• Keep the subject line and introduction short.
• Research about the company’s engineering and stack’s they use (Check out their BLOG section to get the idea).
• Highlight those stacks in your application. (Be mindful – company is not interested in what you know, they are interested in what you know that they can use).
• You can emphasize on how you’d be a good addition to the team.
• Have an online portfolio (LinkedIN profile – You can highlight all your project works in the portfolio)
• Prepare a CV that highlights your strengths and modify it for the target company accordingly and keep your resume short. (Officials usually don’t spend more than 30 seconds to go through any resume.)

To all internship aspirants, next time you apply for an internship, not only for software companies in Chennai or Bangalore? – it’s for every software company, use this post as a checklist. All the best!

Internship Help:- Our company (Cotocus) also accept internship for 3 months and 6 months. If you want to apply for this – you can connect to Biraj Kumar (L & D Manager – +91 9686829970) or you can drop an email at career@cotocus.com

AWS is enabling teams to address application weaknesses with the introduction of the AWS Fault Injection Simulator at is virtual AWS re:Invent 2020 conference this week. The simulator is a chaos engineering tool expected to be generally available in 2021.

According to the company, the new offering will come packed with pre-built templates for creating the desired disruptions whether that’s for server latency or database errors. It also contains controls and guardrails such as automatically rolling back or stopping the experiment if certain conditions are met. Then teams can quickly roll back to the pre-experiment state.

Teams will also have access to a range of fine-grained controls during the experiments to gradually or simultaneously impair how different resources perform in a production environment as it is scaled up, according to AWS in a post.

“With a few clicks in the console, teams can run complex scenarios with common distributed system failures happening in parallel or building sequentially over time, enabling them to create the real world conditions necessary to find hidden weaknesses,” AWS explained on its website.

AWS explained the new offering will be especially useful for simulating game days by creating the high-traffic conditions, a new launch or for integration right into continuous delivery pipelines so that teams can repeatedly test the impact of faults in the SDLC.

Fault Injection Simulator can be used to generate tests in many AWS services such as AWS services, such as Amazon EC2, Amazon EKS, Amazon ECS, and Amazon RDS.

What Is AWSSSMChaosRunner?

AWS engineers open-sourced a chaos engineering tool called AWSSSMChaosRunner, which they used to test fault injection in Prime Video. The library is built on top of AWS Systems Manager (SSM) and enables teams to remotely execute fault-injection commands against targeted EC2 instances. By simulating real-world failure conditions, teams can validate whether their countermeasures — such as timeouts, retries, and circuit breakers — actually work under stress.

The tool was described by Varun Jewalikar, Software Engineer at Prime Video, and Adrian Hornsby, Principal Developer Advocate (Architecture) at AWS. Their core argument: typical chaos engineering scenarios like resource exhaustion or a slow network are rarely tested with confidence using unit or integration tests alone.

How It Works: AWS Systems Manager as the Foundation

AWS Systems Manager is an operational management service that can execute tasks across AWS resources. Its key component for AWSSSMChaosRunner is the SSM Agent, which:

• Comes pre-installed by default on many AWS-provided Windows and Linux AMIs.
• Supports SSM Documents — declarative runbooks that define sequences of commands to execute.
• Can run arbitrary shell scripts, which AWSSSMChaosRunner leverages for fault injection.

The SendCommand API in SSM allows commands to be dispatched to multiple instances simultaneously, with filtering by AWS resource tags. This makes it straightforward to target a specific tier of your infrastructure — for example, all instances tagged as role=video-streaming. Logs from all targeted instances can be aggregated in a single view using Amazon CloudWatch.

Faults are specified declaratively as a collection of commands. The SSM Agent handles security concerns such as creating a dedicated execution user on the EC2 instance, reducing the operational overhead for the team running the experiment.

Supported Fault Injection Types

AWSSSMChaosRunner supports failure injections at the infrastructure layer and the AWS service layer. Examples of what it can simulate include:

• Network latency: Introducing artificial delay on a specific network interface.
• Packet loss / TCP drop: Silently dropping all outgoing TCP traffic on a specific port.
• CPU hogging: Consuming CPU resources to simulate a resource-exhausted host.

It is important to note that AWSSSMChaosRunner works against EC2-based workloads and also supports Amazon ECS. However, it cannot be used with AWS Lambda because Lambda is a fully managed, serverless service where the underlying infrastructure is not accessible. For Lambda fault injection, other approaches and tools exist.

How Prime Video Used It

Prime Video, which relies heavily on AWS services internally, used AWSSSMChaosRunner to test how its systems performed when dependent services experienced high latency. The chaos experiments, combined with a load generation component that simulated real-world traffic, exposed issues that would be difficult to reproduce in a standard testing environment.

One concrete outcome: the team identified and fixed a bug in their Elasticache timeout configuration. Without chaos engineering, this misconfiguration might only have surfaced during an actual production incident.

Architecture Overview: From SSM Documents to Chaos Runner

AWSSSMChaosRunner originated as a set of raw SSM Documents written to inject faults into AWS resources. The library abstracts this further:

1. Define fault scenarios declaratively as a collection of SSM commands or documents.
2. Execute the document via standard SSM Agent APIs, targeting instances by tags.
3. Run the load generation component in parallel to simulate realistic traffic against the application under test.
4. Observe results in CloudWatch logs to determine whether the system behaved as expected under the injected fault.

How AWSSSMChaosRunner Compares to Other Chaos Engineering Tools

Chaos engineering as a discipline has matured significantly, with several tools and frameworks available:

• Netflix Chaos Monkey: One of the earliest chaos engineering tools, designed to randomly terminate EC2 instances to test resilience.
• LinkedIn Project Waterbear: LinkedIn’s internal chaos engineering framework.
• Twitter’s Python library: A Python-based framework developed by Twitter for their own fault injection needs.
• Gremlin: A commercial fault injection platform offered as a managed service.
• AWSSSMChaosRunner: AWS-native, open source, and tightly integrated with SSM, EC2, and ECS — making it a natural fit for teams already operating in the AWS ecosystem.

The primary advantage of AWSSSMChaosRunner for AWS-centric teams is its deep integration with existing AWS tooling — no additional agent installation is required on instances that already have the SSM Agent, and access control can be managed through standard IAM policies.

Why Chaos Engineering Matters for Production Reliability

As Jewalikar and Hornsby noted, most engineering teams have countermeasures for failure scenarios — timeouts, retries, fallback logic — but these are rarely validated with high confidence before a real incident. Unit and integration tests operate in controlled environments that cannot replicate the complexity of degraded network conditions or resource contention at scale.

Chaos engineering bridges this gap by deliberately introducing failure in a controlled way, allowing teams to observe system behavior, identify misconfigured settings (like the Elasticache timeout Prime Video discovered), and build confidence that their systems will degrade gracefully under real-world stress.

Video: AWS Chaos Engineering Playlist

Source: InfoQ. Original reporting by Hrishikesh Barua. Authors of the referenced AWS blog post: Varun Jewalikar and Adrian Hornsby.

Books, blog posts, and conference talks describe individual aspects of DevOps — cultural transformation, CI/CD pipelines, site reliability engineering — but very few frame DevOps as an engineering problem that deserves an engineering solution. That framing matters, because engineering problems respond to structured practices, measurable criteria, and repeatable blueprints. DevOps, treated as an engineering discipline, can do the same.

The Core Problem: DevOps Without a Blueprint

The most common frustration heard from both DevOps leaders and practitioners is a variation of: “We think we are doing DevOps, but we are not getting the business results we expected.” This is not a motivation problem. It is a guidance problem.

Most organizations approach DevOps adoption through one of these incomplete paths:

• Tool-first adoption: Deploy a CI/CD tool, call it DevOps, and wonder why delivery speed or reliability did not improve meaningfully.
• Culture-only framing: Focus entirely on organizational culture and collaboration without engineering the supporting processes and pipelines.
• Cargo-cult implementation: Mimic the visible practices of high-performing organizations (daily standups, sprint planning, shared dashboards) without understanding the engineering infrastructure underneath.

What is missing in each case is a structured, step-by-step engineering prescription that accounts for an organization’s starting point, goals, people, processes, and technology choices.

What an Engineering Approach to DevOps Looks Like

Applying engineering discipline to DevOps means treating the transformation as you would treat any large, complex system design problem:

1. Understand the current state. Assess your existing pipelines, team structures, deployment processes, and technical debt before defining a target state.
2. Define clear goals. Engineering problems require success criteria. For DevOps, that means defining specific, measurable outcomes — deployment frequency, lead time for changes, mean time to recovery (MTTR), change failure rate.
3. Apply proven engineering practices. Structure the implementation around a recognized taxonomy of DevOps practices rather than ad-hoc tool selection.
4. Iterate through maturity levels. DevOps is not a binary state. Organizations progress through maturity levels across people, process, and technology dimensions.
5. Operationalize and expand. Sustaining DevOps requires operationalizing what works and systematically expanding it across teams and value streams.

The Three Ways: A Foundation for Engineering DevOps Maturity

The Three Ways, originally articulated in The Phoenix Project and elaborated in The DevOps Handbook, provide a useful conceptual framework that an engineering approach can operationalize:

• The First Way — Continuous Flow: Engineer the flow of work from development through operations to the customer. This includes CI/CD pipeline engineering, value-stream mapping, and eliminating bottlenecks that slow delivery.
• The Second Way — Continuous Feedback: Engineer fast, continuous feedback loops from production back to development. This includes continuous monitoring, alerting, and telemetry that give teams actionable information.
• The Third Way — Continuous Improvement: Engineer a culture and process of experimentation and learning. This includes post-incident reviews, chaos engineering, and systematic practice refinement.

An engineering blueprint maps specific practices — CI/CD pipeline design, elastic infrastructure, continuous security (DevSecOps), site reliability engineering (SRE) — to the appropriate maturity level within each of these three ways.

Nine Pillars of DevOps Engineering Practices

A useful way to organize DevOps engineering practices is to group them into functional pillars. A typical taxonomy relevant to engineering implementations includes:

1. Value-Stream Management (VSM) — Mapping and optimizing the end-to-end delivery pipeline from idea to production.
2. Application Release Automation (ARA) — Automating the packaging, deployment, and release of applications across environments.
3. Version Management — Source control strategies, branching models, and artifact management.
4. Continuous Security (DevSecOps) — Integrating security scanning, policy enforcement, and compliance checks into the pipeline.
5. Service Catalog and Governance — Standardizing approved services, APIs, and toolchains to reduce sprawl and maintain control.
6. Site Reliability Engineering (SRE) — Defining and maintaining service level objectives (SLOs), error budgets, and reliability practices.
7. CI/CD Pipelines Engineering — Designing and maintaining the build, test, and deployment automation pipeline.
8. Continuous Test Engineering — Integrating automated unit, integration, performance, and security testing throughout the pipeline.
9. Continuous Monitoring Engineering — Instrumenting systems to provide real-time observability, alerting, and performance data.

A Seven-Step DevOps Transformation Blueprint

Rather than treating DevOps adoption as a single event, an engineering approach structures the transformation as a repeatable, expandable process. One practical framework organizes this into seven steps:

1. Visioning — Establish a shared understanding of what DevOps success looks like for your organization and why it matters.
2. Alignment — Align leadership, teams, and stakeholders around the goals, scope, and resource commitments of the transformation.
3. Assessment — Evaluate the current state of people, processes, and technology against a DevOps engineering maturity model.
4. Solution Engineering — Design the target-state DevOps architecture: pipelines, toolchains, team structures, and governance models.
5. Realization — Implement the engineering solution incrementally, starting with a pilot value stream or product team.
6. Operationalize — Embed the new practices into daily operations, including runbooks, on-call procedures, SLOs, and feedback mechanisms.
7. Expansion — Scale successful patterns across additional teams, value streams, and business units.

This seven-step pattern is deliberately iterative. After Expansion, organizations cycle back through Assessment and Solution Engineering to evolve from First Way maturity toward Second and Third Way implementations.

Three Dimensions of DevOps Maturity

DevOps maturity should be assessed across three dimensions, not just the toolchain:

• People: Team structure, skill levels, collaboration patterns, and training programs. Engineering a DevOps capability requires investing in continuous learning.
• Process: Development workflows, release processes, incident management, and change management. These must be redesigned — not just documented — to support flow.
• Technology: Pipeline tooling, infrastructure automation, observability platforms, and security tooling. Technology choices should follow process design, not precede it.

Treating all three dimensions with equal rigor is what separates an engineering approach from a tool-procurement exercise.

Disaster Mitigation, Recovery, and Looking Beyond Continuous Improvement

A complete engineering approach to DevOps also encompasses operational resilience. Disaster mitigation and recovery engineering — defining recovery time objectives (RTOs), recovery point objectives (RPOs), runbook automation, and failover testing — must be built into the DevOps blueprint rather than treated as an afterthought.

Looking further ahead, emerging technologies are reshaping what DevOps engineering practices need to cover. Areas such as AI-assisted operations (AIOps), platform engineering, internal developer platforms (IDPs), and GitOps are expanding the scope of what DevOps practitioners must understand and engineer. Building a DevOps training program that supports continuous learning is essential for keeping engineering skills current as the discipline evolves.

Why Scope Engineering Practices at the Right Level

One important characteristic of a durable engineering approach to DevOps is scoping guidance at the level of engineering practices rather than specific tool versions or vendor products. Tools change. Platforms evolve. But the engineering practices — pipeline design principles, feedback loop requirements, maturity assessment criteria — remain relevant across implementations and over time.

This is why prescriptive DevOps guidance framed as engineering practices is more actionable and longer-lasting than guidance framed as “use tool X and configure it this way.”

Summary

If your organization is doing DevOps but not getting the results you expected, the most likely root cause is the absence of a structured engineering approach. Applying engineering discipline to DevOps means assessing your current state, defining measurable goals, selecting and implementing engineering practices systematically across people, process, and technology, and evolving your capability through well-defined maturity levels. The Three Ways provide the strategic framework. A seven-step transformation blueprint provides the operational roadmap. And a taxonomy of DevOps engineering practices — from CI/CD pipeline design to SRE to continuous security — provides the implementation detail.

DevOps is complex. But complexity, properly engineered, becomes manageable.

Background: AT&T’s DevSecOps Challenge

At AWS re:Inforce 2019—Amazon’s inaugural dedicated security conference—John Maski delivered a session titled “Integrating AppSec in your DevSecOps on AWS.” Maski spent 32 years at AT&T, most recently as Director of Production Resiliency & DevSecOps Enablement, before joining Veracode to help customers integrate application security into their delivery pipelines.

His talk addressed a challenge familiar to most large enterprises: software development optimised purely for speed, with security treated as an afterthought. At AT&T’s scale, development pipelines varied enormously across teams, skill levels were inconsistent, and there was no unified approach to application security.

Why Executive Support Is Non-Negotiable

Maski was direct on this point:

“In an organisation the size of AT&T, you can’t make meaningful progress without the support of executive leadership. It is absolutely critical to drive the necessary cultural changes.”

— John Maski, former Director, Production Resiliency & DevSecOps Enablement, AT&T

On the positive side, AT&T already had pockets of advanced CI/CD knowledge, a significant CI/CD platform under development, and—crucially—executive appetite for rapid, wide-ranging progress. That appetite provided the mandate Maski needed to connect partner organisations around a shared goal: securing AT&T’s entire application landscape. By the time he left the company, that goal was nearly complete.

Integrating Security into the CI/CD Pipeline

A core theme of Maski’s talk was that application security professionals must understand their organisation’s development tooling—not just the security tools. Speaking an engineering team’s language is prerequisite to influencing how they work.

The general model Maski described places manual processes at the two ends of the pipeline and automated testing in the middle:

• Threat modelling (start of pipeline): Still a human-driven activity. Even with tools that help visualise and document architecture, understanding system design and its attack surface requires human judgement.
• Penetration testing (end of pipeline): A final litmus test before any critical application is promoted to production. Not a replacement for earlier automated testing.
• Automated testing (throughout the pipeline): Three primary categories—Static Application Security Testing (SAST), Software Composition Analysis (SCA), and Dynamic Application Security Testing (DAST)—each targeting different vulnerability classes.

Static Application Security Testing (SAST)

SAST analyses application source code for a broad range of security flaws without executing the application. It can be integrated at two levels:

• IDE plugins: Provide real-time, in-editor feedback while developers write code. Guidance at this stage is advisory rather than mandatory, making it most effective at reducing flaws in newly written code. Veracode’s data (cited in Maski’s presentation) suggests this approach helped organisations reduce newly introduced flaws by 60 percent.
• CI pipeline: Scans triggered on code commit or pull request. Results are surfaced through the team’s ticketing system, creating a structured feedback and compliance loop. For high-security applications, Maski recommended a full-scope scan before each deployment to prevent security defects from reaching production. Teams typically run CI-triggered scans in a “sandbox” mode so that results remain within the development team before being escalated.

Software Composition Analysis (SCA)

SCA identifies known vulnerabilities in open-source libraries that the application depends on. The remediation path is almost always upgrading to a patched library version rather than modifying open-source code directly. SCA typically integrates at the same pipeline stages as SAST—IDE and CI—and feeds into the same ticketing workflows.

Dynamic Application Security Testing (DAST)

DAST interacts with a running application through an instrumented browser that crawls and audits the application from the outside—mimicking how an attacker would probe it. Unlike SAST, DAST can detect runtime and server-configuration issues that are invisible at the code level. It is typically run in the QA stage against a staging environment and, where appropriate, against the production server. Some vulnerability classes are only detectable via DAST, making it a complement to—not a substitute for—SAST and SCA.

Five Tips for Getting Traction with a DevSecOps Initiative

Drawing on his experience at AT&T, Maski offered five practical recommendations for anyone launching or scaling a DevSecOps programme:

1. Partner with stakeholders. Identify and align with partners in software development early. Understand their workflows and respect their constraints. A security programme that ignores the developer experience will fail to get adoption.
2. Pick the right metrics. Define what success looks like before you start. Agree on metrics with sponsors and engineering partners upfront—do not retrospectively try to prove value with numbers no one cares about.
3. Don’t try to boil the ocean. Take an Agile approach. Select pilot applications, learn from the process, then expand. Document lessons at each stage and use them to improve the programme iteratively.
4. Run an internal communication campaign. Raise awareness about why AppSec matters to the business. Connect application security to the company’s mission. Use internal communications as an education channel to raise the security knowledge baseline across DevOps teams.
5. Demonstrate progress regularly. Report programme progress against agreed metrics to maintain executive support and budget. Tailor the reports to the audience—senior leaders need different data from engineering partners.

Three Key Learnings from AT&T’s Programme

Maski closed with three high-level takeaways from running an enterprise-scale DevSecOps programme:

• Executive leadership drives cultural change and secures budget. Without visible sponsorship from the top, security initiatives struggle to overcome organisational inertia.
• Use managed platforms to accelerate onboarding. If speed matters, choose scanning and AppSec services built on robust, maintained platforms. This lets teams focus on onboarding applications rather than building and operating scanning infrastructure from scratch.
• Build a strong team and hold a flexible plan. Map out and communicate the plan with confidence, but be prepared to learn and adjust. Setting bold goals helps drive meaningful progress even when the path changes.

Takeaways for DevOps and Security Engineers

The AT&T story demonstrates that large-scale DevSecOps transformation is achievable, but it requires more than tooling. The combination of executive mandate, developer-centric integration (meeting engineers where they work), incremental rollout, and clear metrics is what allowed AT&T to move from fragmented, speed-first development toward a consistent, security-embedded pipeline across its entire application portfolio.

For teams at any scale, the pipeline model Maski described—threat modelling, SAST in the IDE and CI, SCA, DAST in QA and production, and penetration testing before release—provides a practical template for layering security into existing delivery workflows without blocking delivery speed.

Benefits of DevOps

Organisations that adopt DevOps practices correctly report improvements across several areas:

• Improved cross-team communication. DevOps breaks down silos between development, QA, security, and operations departments, encouraging shared ownership of product quality.
• Faster, more reliable releases. Continuous integration and continuous delivery (CI/CD) pipelines automate build, test, and deployment steps, reducing the time from code commit to production.
• Higher software quality. Automated testing and continuous feedback loops catch defects earlier in the development cycle, when they are cheapest to fix.
• Stronger security posture. Integrating security practices into the pipeline (often called DevSecOps) makes security a shared responsibility rather than a last-minute gate.
• Faster response to feedback. Monitoring, logging, and alerting tools give teams real-time visibility into how software performs in production, enabling rapid iteration.
• Greater automation. Repetitive manual tasks — provisioning infrastructure, running tests, deploying code — are automated, freeing engineers to focus on higher-value work.

Core Principles Behind DevOps

DevOps is often summarised around three interconnected pillars: people, processes, and tools.

People

DevOps requires a cultural shift before it requires any tooling change. Developers, operations engineers, QA testers, and security specialists must collaborate continuously rather than hand work off in isolated stages. This shared responsibility model means that everyone on the team has a stake in the reliability and quality of what ships to production.

Processes

DevOps streamlines the workflows that move software from idea to production. This includes adopting agile planning practices, defining clear definition-of-done criteria, establishing CI/CD pipelines, and conducting blameless post-mortems when incidents occur. The aim is to identify and eliminate bottlenecks at every stage so that work flows smoothly across teams.

Tools

Tooling supports — but does not replace — the cultural and process changes. A typical DevOps toolchain spans version control (e.g., Git), CI/CD platforms (e.g., Jenkins, GitHub Actions, GitLab CI), infrastructure-as-code tools (e.g., Terraform, Ansible), container orchestration (e.g., Kubernetes), and observability platforms (e.g., Prometheus, Grafana). The right tools are those that fit your team’s existing workflows, not those that are most popular in the industry.

Is DevOps Right for Your Business?

DevOps is not a universal solution, and adopting it without organisational readiness can create as many problems as it solves. Before committing, consider the following questions:

• Is leadership aligned? DevOps transformation requires executive sponsorship. Without it, teams revert to old habits under deadline pressure.
• Are your teams buried in manual work? If engineers are spending the majority of their time on manual deployments, server maintenance, or firefighting incidents, the foundation for DevOps is not yet in place. Address the immediate operational debt first.
• Do you have basic automation in place? Teams that already run automated tests, use source control consistently, and have some deployment automation are far better positioned to benefit from a full DevOps adoption.
• Can you define clear success metrics? Common DevOps metrics include deployment frequency, lead time for changes, mean time to recovery (MTTR), and change failure rate. Without agreed metrics, it is hard to demonstrate value or course-correct.
• Are all stakeholders willing to change? DevOps is a collaborative endeavour. If key departments are resistant, adoption will stall.

If your team has some automation in place, has reduced routine operational bottlenecks, and leadership is committed to cultural change, DevOps adoption is likely to deliver meaningful improvements. If you are still dealing with frequent unplanned downtime, no version control discipline, or siloed teams with no shared goals, resolve those foundational issues first.

How to Implement DevOps

Because every organisation is different, there is no single DevOps implementation blueprint. However, a structured approach helps teams avoid common pitfalls.

1. Build a Shared Understanding

Start with training and alignment. Teams should understand DevOps principles, the CALMS framework (Culture, Automation, Lean, Measurement, Sharing), and the specific outcomes the organisation is targeting. Training programmes such as the DevOps Foundation certification (offered by organisations like the DevOps Institute) provide a structured introduction to these concepts.

2. Embed Security Early (DevSecOps)

Security should be integrated into the CI/CD pipeline from the start rather than bolted on at the end. This means adding static analysis, dependency scanning, and secrets detection to automated pipelines. DevSecOps training extends DevOps principles specifically into the security domain.

3. Modernise Your Testing Practices

Automated testing is the safety net that makes rapid deployment possible. Investing in unit, integration, and end-to-end test coverage — and understanding which tests belong in which stage of the pipeline — is essential to sustainable DevOps. This is the focus of disciplines like DevOps Test Engineering.

4. Start Small, Then Scale

Choose a single team or product to pilot DevOps practices. Establish baseline metrics, implement changes incrementally, and gather feedback before rolling out to other teams. Attempting a company-wide transformation simultaneously is a common failure mode. Lessons learned from the pilot team — including what tooling choices work and which process changes generate resistance — are invaluable when scaling.

5. Choose Tools That Fit, Not Tools That Are Fashionable

DevOps does not mandate specific tools. Project management platforms, CI/CD systems, monitoring stacks, and collaboration tools should be selected based on your team’s existing skills and your product’s requirements. The best tool is the one your team will actually use consistently.

Summary

DevOps is a meaningful investment for organisations that are ready for it. When adopted with genuine cultural commitment, clear metrics, and a phased rollout, it delivers faster releases, higher quality, and more resilient systems. If your teams are still overwhelmed by manual operations or lack basic automation, build those foundations first. DevOps amplifies good engineering practices — it cannot substitute for them.