devopsy.kinsta.cloud

Category: Cloud Management

From Reactive to Predictive: Capacity Planning Systems That Actually Work
I used to think capacity planning was about setting up CloudWatch alarms and hoping they’d fire before things broke. Spoiler: that’s not capacity planning—that’s just reactive firefighting with extra steps.

Real capacity planning means knowing you’ll need more database capacity three weeks from now, not three minutes after your site starts timing out. It means being able to confidently tell your team, “We’re good until mid-January, then we need to scale,” instead of scrambling during a production incident.

After years of being on the wrong side of this problem, I finally built a system that works. Here’s what I learned.

The Problem With How Most Teams Do Capacity Planning

Most engineering teams fall into one of two camps:

Camp 1: The Reactive Firefighters
They wait until something breaks, then throw resources at it. CPU hits 90%? Spin up more instances. Database slow? Upgrade the tier. This works until you’re burning budget on over-provisioned resources or, worse, you’re down because you scaled too late.

Camp 2: The Over-Engineers
They build elaborate forecasting models with machine learning, multiple data sources, and dashboards that take longer to understand than the problems they’re solving. These systems are impressive but rarely used because they’re too complex for day-to-day decisions.

I’ve been in both camps. Neither works long-term.

What Actually Makes Capacity Planning Work

After multiple iterations, I’ve learned that effective capacity planning needs three things:
1. Simple, Actionable Metrics
  You don’t need fifty metrics. You need the right five. For most systems, that’s:
- Resource utilization trends (CPU, memory, disk)
- Request rate growth patterns
- Database connection pool usage
- Storage growth rate
- Network throughput trends
The key is tracking these consistently and understanding what “normal” looks like for your system.
1. Historical Context That Matters
  Raw metrics are useless without context. You need to know:
- What happened during your last traffic spike
- How your system behaved during that product launch
- What “seasonal” patterns exist in your usage
I keep a simple log of significant events alongside our metrics—product launches, marketing campaigns, major features. When I look at a utilization spike from three months ago, I can see it coincided with a feature release, not a problem.
1. Forward-Looking Projections Based on Reality
  This is where most systems fail. They either use naive linear projections (useless for growing systems) or overly complex models (unusable for actual decisions).
What works: trend analysis with growth factors that you adjust based on what’s actually happening. If you’re growing 15% month-over-month, project that forward. If a major feature is launching next month, factor in expected load based on similar past events.

Building a System That Your Team Will Actually Use

Here’s the architecture that’s worked for me:

Data Collection Layer
Pull metrics from your existing monitoring (CloudWatch, Datadog, Prometheus, whatever you’re already using). Don’t build a new metrics pipeline. Use what you have.

I built a simple script that runs daily and pulls:
- Average and peak utilization metrics for the past 30 days
- Week-over-week growth rates
- Month-over-month trends
Analysis Layer
This is where the magic happens, but it’s simpler than you think. For each critical resource:
1. Calculate the current growth rate (7-day, 30-day, 90-day averages)
2. Project forward using the most conservative (slowest) growth rate
3. Calculate time-to-threshold (when will you hit 80% capacity?)
4. Flag anything that’ll hit threshold in the next 60 days
I use Python with pandas for this. The entire analysis script is under 200 lines.

Alert and Reporting Layer
Here’s the crucial part: make it impossible to ignore.
- Weekly email summary to the engineering team showing resources projected to need scaling
- Slack alerts when time-to-threshold drops below 30 days
- Monthly capacity review doc that auto-generates and gets dropped into our team drive
The key is automation. If you have to remember to check a dashboard, you won’t.

The Guardrails That Keep It Honest

Early versions of my system gave terrible predictions because I made these mistakes:

Mistake 1: Trusting short-term trends
A three-day spike doesn’t mean you’re growing 300% per week. I added a rule: never project based on less than 14 days of data, and always compare against 30-day and 90-day trends.

Mistake 2: Ignoring known events
If there’s a major feature launch next month, your linear projection is worthless. I maintain a simple calendar of planned events that might impact capacity and manually adjust projections around them.

Mistake 3: Setting thresholds too high
Waiting until you’re at 90% CPU to scale means you’re already feeling pain. I alert at 80% capacity with 60 days runway. That gives us time to plan, provision, and test without panic.

What This Actually Looks Like in Practice

Here’s a real example from last quarter:

Our RDS database was sitting at 52% CPU utilization. Traditional monitoring said we were fine. But my capacity system showed:
- 30-day growth rate: 3.2% per week
- 90-day growth rate: 2.8% per week
- Projected to hit 80% CPU: 47 days
Without this, we would’ve kept ignoring it until we hit 85% and had to do an emergency scaling operation during business hours. Instead, we scheduled a maintenance window, upgraded the instance class, and validated performance; all without impacting users.

That’s what predictive capacity planning actually delivers: boring, planned infrastructure changes instead of exciting 2 AM emergencies.

The ROI You Can’t Ignore

Since implementing this system, we’ve:
- Eliminated emergency scaling incidents (which used to happen every 6-8 weeks)
- Reduced over-provisioning by right-sizing based on actual projections
- Cut time spent in war rooms discussing “do we need to scale?” from hours to minutes
More importantly, our team sleeps better. When you know what’s coming, you can plan for it. When you’re constantly reacting, you burn out.

Starting Your Own Capacity Planning System

If you’re building this from scratch, start small:

Week 1: Pick your critical resources
What are the three things that, if they ran out of capacity, would take your system down? Database? Application servers? Cache layer? Start there.

Week 2: Set up automated data collection
Write a script that pulls utilization metrics for those resources daily. Store them somewhere: S3, a database, even a CSV in git. Just make sure it’s consistent.

Week 3: Build your first projection
Take the last 30 days of data, calculate growth rate, and project forward. It doesn’t need to be fancy. A spreadsheet works.

Week 4: Add alerting
When time-to-threshold drops below 60 days, send an email. That’s it. You now have a working capacity planning system.

Everything else—dashboards, ML models, sophisticated forecasting—can come later if you need it. But this core system will save you from most capacity-related incidents.

The Mindset Shift That Matters Most

The biggest change isn’t technical, it’s cultural. Capacity planning only works when your team believes that preventing problems is more valuable than heroically solving them.

Early in my career, I got praise for staying up all night scaling systems during an outage. Now I get praised for the outages that never happened because we scaled two weeks early.

That shift from reactive hero culture to proactive engineering culture is what makes capacity planning sustainable. The system I’ve described is just the tool that makes that culture possible.

What’s Next

Capacity planning isn’t a project you finish; it’s a practice you refine. As your system grows and changes, your capacity planning needs to evolve with it.

The system I’ve built continues to get better as I learn what matters and what doesn’t. Some quarters I add new metrics. Other times I simplify and remove things that weren’t adding value.

The goal isn’t perfection. It’s having enough visibility and lead time to make good decisions instead of panicked ones.

If you’re tired of reactive firefighting and want to build something better, start with the basics I’ve outlined here.
January 9, 2026
Observability, SRE and Uptime in Telehealth Platforms: A DevOps Playbook
Virtual care went from nice to have to must have during the COVID-19 pandemic and while in-person visits are starting to pick up again, telemedicine is here to stay. Its growth will continue: health-tech companies are predicting the telemedicine market will be $143.49 billion by 2025 (it will be $167.74 billion in 2025 and $584.99 billion by 2033 at 16.9% growth rate).

Telehealth platforms handle sensitive health information, manage appointments, stream live video, link to patient EMRs and of course must be fully HIPAA compliant. Anything that goes wrong and we mean anything can harm patient care, erode trust and bring on a whole bunch of regulatory headaches. For DevOps teams who build and run these platforms, having a system that’s rock solid and always available is no longer a nice to have; it’s a patient safety feature.

This guide is all about where observability, SRE and uptime management come together in telehealth. Based on research, real case studies and hard-won experience of actually managing DevOps teams in healthcare, it outlines a bunch of practical steps you can take to get your production platform ready for production while meeting all the compliance and user experience requirements.

Why Telehealth Reliability Matters

Telehealth users expect the same uptime as traditional clinical systems. According to a 2024 survey of healthcare organizations, 93% of patients expect digital health services to be available 24/7 and downtime incidents cost an average of $7,900 per minute. Hospitals and clinics operate on thin margins and outages have a ripple effect: staff have to go back to paper processes, appointment backlogs grow and patient safety declines. The 2024 CrowdStrike-related Microsoft outage cost the healthcare industry about $1.94 billion with individual organizations losing about $64.6 million.

Regulators are paying attention. North Memorial Health, for example, paid $1.55 million after a HIPAA violation related to inadequate safeguards and lack of business-associate agreements. Downtime during compliance incidents damages not only finances but also patient trust. As Mitesh Rao, former chief patient safety officer at Stanford Health Care, said, telehealth outages “affect every aspect of patient care”. DevOps teams need to engineer telehealth platforms that deliver continuous availability while meeting security and regulatory requirements.

Beyond Monitoring: Building Observability

What Is Observability?

Monitoring checks if specific metrics are within thresholds. Observability goes further; it provides a holistic view of system health by correlating metrics, logs, traces and events. Bri Morgan of Splunk says healthcare observability is “the path to achieving resiliency across mission-critical services”. Observability tools let IT teams see into the system’s internal state based on its external behavior and gather insights into clinical and operational workflows. John Wilson of SolarWinds adds that observability “helps identify security threats and potential breaches” and helps with HIPAA compliance.

Observability is different from monitoring in its predictive and diagnostic capabilities. It includes distributed tracing, a forensic technique that visualizes the flow of requests across microservices to find bottlenecks and anomalies. Predictive analytics can forecast potential issues so organizations can respond proactively. Patrick Lin, general manager of observability at Splunk, says observability integrates with DevSecOps so teams can catch security issues before they hit production without slowing down the development cycle.

Telehealth‑Specific Observability

The unique challenges that come with telehealth platforms. Video streams, asynchronous messaging & all the rest – remote monitoring devices, EHRs, billing systems – observability needs to cover everything from network to application, & that includes video performance & device health too. Take Codebridge’s advice for a moment – setting service level objectives (SLOs) right from the get-go is a good place to start: 99.95% uptime, video join times of 5 seconds or less, & call drop rates under 2%. Those SLOs translate patient expectations into real targets – something to aim for.

Observability isn’t just about catching errors, though that’s part of it. You need to see the whole picture: all those user journeys & interactions that are happening. For example, if patients are bailing out on authentication all the time, metrics are just the first place to look. You need to dig deeper to find out if it’s the identity provider, network, or the timeouts that are the problem. You should be able to see interactions with all those peripheral devices – digital stethoscopes & blood pressure monitors, that sort of thing. And remote site observability means your telehealth services are running smoothly, patient data & device health are getting checked, & you’re keeping an eye on medical equipment too. DevOps teams want to be able to get that device data, so they can pick up on data quality issues before it’s too late for clinicians.

As the world moves on, more & more of these observability platforms are including AIOps – AI-driven analytics that can spot anomalies & say “here’s how to fix it”. That AI observability stuff can collect & analyze all the data – events, metrics, logs & traces, to name a few – & spot system issues before they become problems, keep downtime to a minimum & make sure services like EHRs, telehealth & imaging are always available. Those AI models can even spot the really subtle stuff, like a slow memory leak or the odd bit of network congestion that you might otherwise miss.

Implementing Observability:
- Instrument all your bits and bobs – use open standards like OpenTelemetry to add monitoring to your code, infrastructure, and networks. Get a handle on metrics (latency, throughput, error rates) and logs (the lowdown on what’s happening, in context) – and don’t forget about those cross-service workflows, captured via distributed tracing. For telehealth, pay attention to video streaming (looking at WebRTC metrics), call quality (packet loss and jitter can be a real problem), and device connectivity.
- Gather all your data in one place and get some visibility across the board. Use a unified observability platform to collect telemetry data and spot problems as they appear, across different parts of the system. And make sure distributed tracing ties user actions back to the processes that are actually working on them – that way you can stop teams from bouncing between different dashboards to try and figure things out.
- Set up your alerts and anomaly detection to save you time and stress. Use machine learning to spot when things are behaving strangely, and get real-time alerts when there’s an issue. And make it easy to fix things fast with some run-book automation to help sort out problems as soon as they come up.
- Put data privacy at the top of your list – observability has to comply with HIPAA and GDPR. Make sure any sensitive data stays encrypted while it’s in transit and when it’s stored, limit who can access it with role-based controls, and draw up business associate contracts. And don’t forget that HIPAA needs end-to-end encryption, audit trails, and frameworks like NIST and zero-trust architecture. Your data pipelines have to fit the bill, too.
Site Reliability Engineering: Turning Metrics into Reliability

SRE is the application of software engineering to operations. Google made it popular by treating reliability as a product feature and quantifying it through service level indicators (SLIs), SLOs and error budgets. Healthcare can benefit a lot from SRE.

A 2024 research paper says Google’s SRE team maintains 99.99% uptime for critical services and the Cleveland Clinic reduced critical incidents by 40% and MTTR by 60% after adopting SRE. A HIMSS survey found 70% of healthcare IT professionals believe SRE practices improve system reliability and performance.

SRE Practices for Telehealth

Design for graceful degradation, so if the video doesn’t work, for example, the system can fall back to audio or chat. Provide asynchronous options like secure messaging or offline notes so care can continue even when live sessions drop.

Do chaos engineering: Simulate node failures, network partitioning and API timeouts to see how the system behaves. In telehealth scenarios, testing should include streaming services, device connectivity and EHR integration. Use the results to enhance failover strategies and client-side resiliency.

Track patient-centric SLIs: CPU and memory metrics are not enough. Monitor metrics like join time, call drop rate, video quality (jitter, packet loss), authentication latency, prescription fulfillment success, and device connectivity. These SLIs are patient-facing. When you put multiple microservices together, use distributed tracing to correlate patient-level transactions across authentication, scheduling, video streaming, EHR integration and billing.

Automate remediation: Combine observability data with automated runbooks to reduce MTTD and MTTR. According to IRJET, advanced monitoring allowed one hospital to detect and resolve 80% of incidents before they impacted end users; 75% of organizations using advanced monitoring reported improved availability and reduced downtime.

Prioritize patient data integrity. There’s no use being reliable if the data is wrong. SRE practices should include thorough validation and error handling. The Cleveland Clinic reduced errors in data entry by 80% and increased the accuracy of records to 95% by implementing full data validation.

DevOps Playbook for Telehealth

Now that we have the theory, let’s turn it into a playbook for DevOps teams to build telehealth platforms.

1. Know the Domain

Telehealth is regulated and patient-centric. Know HIPAA, HITECH and regional regulations. Map data flows and ensure PHI is secure. During planning, involve compliance specialists and clinicians to understand functional requirements (e.g. e-prescriptions and remote monitoring) and non-functional requirements (e.g. uptime, latency and security). As an example of how domain expertise drives success, ScienceSoft telemedicine solutions enable audiovisual patient-doctor communication, patient monitoring and remote care delivery while reducing healthcare costs and increasing care accessibility. This shows that telehealth software must balance technical complexity with clinical usability.

2. Define Reliability Objectives and Architecture

Set SLOs for each user journey: session setup time, video quality, messaging latency, device connectivity and data synchronization. Document error budgets and attach to business objectives. Build architecture diagrams showing redundancy, failover paths, encryption layers and integration points. Decide to use commercial video SDKs or build a custom WebRTC infrastructure. As an example, Codebridge recommends 99.95% uptime, with call drop rates less than 2%; adjust to your clinical use cases.

3. Instrument and Automate

Instrument from day one: OpenTelemetry in microservices; quality metrics in video streaming components and log for EHR integration. Infrastructure as Code (Terraform, Ansible) and CI/CD pipelines for consistent environments and repeatable deployments. SAST and DAST in your pipeline, performance tests. Canary deployments and feature flags to control the blast radius of new features. Strong CI/CD pipeline reduces manual errors: Northwell Health’s 95% error reduction is proof.

4. Operate with SRE Principles

Create on-call rotations and incident response playbooks. Use run-books to automate standard remediation tasks – such as scale pods and restart services. Run game days and chaos experiments to validate failover. Track incident metrics: MTTD, MTTR; have blameless postmortems. SRE is not about heroics; it’s about creating systems that self-heal and freeing engineers to focus on automation instead of firefighting.

5. Continuously Improve Based on Observability Data

Observability should be the driving force that guides where your development and ops teams focus their efforts. Take a close look at those system traces to figure out where you’re really getting bottlenecked – then use that info to tweak code, snag those pesky database queries & network routing issues. And let’s not forget using predictive analytics to stay one step ahead, so you can spot impending hardware doom before it becomes a disaster.

Throw those observability dashboards up on the screen for your clinical stakeholders to see, so they can get a handle on how the platform is doing and maybe even make a strong case for some much-needed investments. In the words of LogicMonitor, you can proactively sniff out issues and keep EHR, telehealth & imaging systems always accessible when you use a hybrid observability platform powered by AI.

6. Prioritize Compliance and Trust

Reliability and compliance go hand in hand – so don’t forget it. Encrypt that data, set up proper access controls and keep track of all those audit trails. Plus, make sure you’re in compliance with the major security frameworks like NIST CSF & zero-trust network segmentation – that’s a given. Then toss in some regular risk assessments & penetration tests for good measure. Document all those data flows, have all the necessary business associate agreements in place with your vendors and make darn tootin’ sure the customer feels safe knowing their data is protected and their care won’t be put in jeopardy from some avoidable security screw-up.

Conclusion

Observability and SRE are key to uptime and reliability in telehealth platforms. By doing proactive monitoring, automated response and DevOps, teams can make every virtual visit seamless, secure and always available when patients need it most.
December 18, 2025
The Leadership Mindset for Sustainable DevOps Cost Optimization
Organizations increasingly leverage DevOps for its ability to accelerate delivery, enhance reliability and spark innovation with enhanced automation ideas. But what happens when the very success of scaling automation and cloud infrastructure leads to costs that silently spiral out of control? It’s a common, frustrating scenario: One day, you’re staring at a doubled cloud bill with no clear answers. Through my work advising and guiding numerous technical initiatives across various teams, I’ve consistently found that true cost optimization isn’t about arbitrary mandates or a sudden realization or reactive response after looking at the monthly costs.

Instead, it’s about cultivating a leadership mindset that empowers teams to proactively embed cost awareness right from scratch till the release and delivery, making it a natural, continuous part of their process. In this article, I’ll outline how this leadership mindset, and the practical strategies that stem from it, can drive significant cost optimization across organizations of all sizes, from agile startups to well-established enterprises handling applications at any scale.

Mindset Shift: From Cost-Cutting to Cost Ownership

The instinctive reaction to ballooning cloud expenses is often reactive cost-cutting: Slashing budgets, freezing innovation, or issuing blanket restrictions. While these measures might offer short-term relief and temporarily rein in spending, they rarely create a lasting impact. Worse, they can demoralize engineers and drive workarounds that ultimately make costs even harder to control.

Sustainable optimization starts when leaders reframe the conversation: From seeing costs as an external burden imposed by finance to recognizing them as an integral signal of engineering health. In this mindset, cost is not a punishment—it’s a form of feedback, much like consistently tracking performance metrics or ensuring uptime.

When teams feel ownership over cost outcomes, they’re more likely to make intentional choices about architecture, capacity and tooling. Rather than waiting for top-down directives, they proactively consider questions such as:
- “How much will this design pattern cost at scale?”
- “Can we automate the cleanup of unused resources?”
- “What trade-offs are we making between speed and spend?”
- “Who are the end users for this, and when do they use it?”
Leaders can cultivate this mindset by making cost data visible, normalizing conversations about trade-offs, and celebrating examples of thoughtful decision-making. This approach shifts cost optimization from a reactionary exercise to a shared, continuous practice embedded in everyday work.

Build a Culture of Transparency

Even when teams understand that cost is a valuable signal, they can’t act on what they can’t see. This lack of cost visibility is one of the most common reasons cloud expenses become unmanageable, regardless of company size. Whether it’s a lean startup or a sprawling enterprise, if detailed spend data is siloed with finance teams or a handful of managers, developers remain fundamentally disconnected from the financial impact of their daily decisions

Leaders have to set the tone for transparency by making cost data accessible, contextual and non-punitive. Instead of monthly reports buried in a finance portal, consider surfacing real-time spend metrics directly in engineering workflows. For example, tagging resources by team, environment and application can help everyone understand exactly where money is going.

When developers can see that an idle staging environment has been quietly consuming thousands of dollars over a quarter, they’re far more likely to take ownership and act.

Transparency also means normalizing conversations about cost during planning and retrospectives. Encourage teams to ask:
- “What would this feature cost to run over the next year?”
- “Are we provisioning more than we need?”
- “Have we set clear budgets or thresholds for experimentation?”
When leaders model these questions openly without blame, teams learn that cost awareness isn’t about finger-pointing; it’s about making informed, responsible choices together. Over time, this transparency transforms cost from an afterthought into a shared, everyday consideration that shapes how software is designed, built and maintained.

“You can’t optimize what you can’t see.”

Empower Teams with the Right Data and Tools

Even the most motivated teams can’t improve what they can’t measure—or act on what they only see in hindsight. Leaders need to do more than surface spend data; they must equip teams with practical ways to factor cost considerations into their daily decisions.

One effective strategy is making cost insights more accessible in the tools and workflows teams already use. For example:
- Include cost trend reports in sprint reviews so teams can see how recent changes have affected spend.
- Share monthly or bi-weekly cost summaries by environment or project via Slack, email, or dashboards.
- Provide self-service reporting portals where teams can easily look up usage and cost by tag or account.
When teams have resource-level visibility, they can better evaluate whether the convenience of keeping certain configurations or environments running is worth the sustained expense. This context allows them to weigh long-term versus short-term benefits and make deliberate choices that align with both technical goals and financial priorities. For example, Teams might realize over time that the cost of running numerous microservices outweighs the benefits at steady-state usage, leading them to consolidate services or adopt simpler deployment models.

Beyond visibility, leaders can enable teams through policies and defaults that make cost-conscious behavior the norm. Examples include:
- Auto-expiration policies for non-production environments to prevent forgotten resources from accumulating costs.
- Budget thresholds with pre-approved spending ranges, so teams have clarity about how much experimentation is acceptable without extra approvals.
- Default instance sizes and storage configurations that strike a balance between performance and efficiency.
The goal isn’t to impose rigid constraints that retard innovation but to create guardrails that allow teams to move fast while staying mindful of the financial impact. When cost considerations are woven naturally into planning, development and operations and are not tacked on at the end, teams feel empowered to make smart, sustainable decisions without constant oversight.

Align Costs with Business Value

Even with strong cost visibility and thoughtful practices, many organizations struggle to connect spending decisions to real business impact. Leaders can help teams avoid optimizing in a vacuum by anchoring cost discussions firmly to customer value and strategic priorities.

Instead of asking only whether a workload or environment is expensive, consider whether it meaningfully contributes to outcomes that truly matter like customer adoption, product quality, or revenue growth. A workload that costs more may still be the right choice if it demonstrably drives measurable business success. Conversely, a cheaper approach isn’t always superior if it compromises critical aspects such as reliability, security, or the agility required for rapid innovation.

To make this vital connection clear, leaders should share concrete examples where targeted investments created positive business results, as well as situations where indiscriminate cost-cutting caused unintended setbacks. Encourage teams to think beyond short-term efficiency and deeply consider long-term trade-offs and strategic implications.

Balancing Innovation and Cost: A Symbiotic Relationship

This focus on cost ownership and business value isn’t about stifling innovation or denying engineers the resources to build. Quite the opposite. When teams deeply understand the financial implications of their decisions, they become more innovative, not less.

They’re challenged to find smarter, more efficient ways to achieve outcomes, rather than simply throwing resources at a problem.

For “thirsty engineers” looking to create the best, this reframed approach offers a powerful benefit: It ensures their valuable work isn’t just technically brilliant, but also sustainable and impactful to the business. It shifts the conversation from “why is this expensive?” to “how can we achieve this groundbreaking outcome while being mindful of our resources?” This encourages creative problem-solving within realistic constraints, ultimately leading to more resilient, cost-effective and successful innovations, whether for external customers or internal projects. Leaders play a crucial role here by providing the right visibility, encouraging experimentation within guardrails and celebrating efficient innovation, not just innovation at any cost.

Over time, aligning costs with business value helps organizations prioritize improvements that deliver meaningful impact, rather than chasing optimization for its own sake.

Best Practices and Realistic Takeaways

Cost optimization in DevOps is rarely a straightforward process. It doesn’t start with sophisticated tooling or perfect policies. All it starts with education, cultural change and consistent reinforcement. In my experience leading cost optimization initiatives and advising many other firms and individuals, most teams focus first on building what serves customers, and only later realize that costs can silently grow out of control.

Here are a few practices and lessons that proved most effective over time:
- Invest in education first – Early on, there was little understanding of why cost awareness mattered or how to approach it. Organize workshops, in-person synergy groups and practical sessions to help engineering leaders and their teams see cost as a signal of health rather than a burden. Without this baseline education, no dashboard or policy would stick.
- Celebrate and reward early wins – To overcome initial pushback, pair real-time visibility with consistent positive reinforcement. When teams achieved measurable savings or adopted better practices, share kudos publicly over shared channels and in team meetings. Recognizing these efforts encourages others to follow suit and develops the culture.
- Make finance a partner, not a gatekeeper. Working closely with finance helps to uncover which resources are qualified for higher discounts, where committed spend could be leveraged and what alternatives are more cost-effective. This collaboration turns cost discussions into shared problem-solving rather than top-down enforcement.
- Share learnings openly. Documenting best practices, publishing internal blogs and highlighting success stories across lines of business were essential to building momentum. Over time, this transparency creates a sense of community around cost ownership.
- Treat cost optimization as a living practice. The most important lesson I learned is that this work isn’t a “set it and forget it” exercise. Cost awareness has to become part of how teams think and operate every day, without requiring constant reminders. When it becomes part of your culture – an ongoing habit rather than a project, savings and smarter decisions follow naturally.
Conclusion

Sustainable cost optimization in DevOps isn’t about chasing the lowest bill or enforcing rigid controls that drain morale. Understand that you are on your own journey, trying to make your application more sustainable day by day. It’s about leadership creating the right visibility, empowering teams to own their decisions and aligning costs to outcomes that genuinely matter.
July 17, 2025
AWS Cloud Migration Strategy
Cloud migration is moving data, applications or other services to a cloud computing environment from an on-prem data center. Migrating your project means moving your data from the on-premises data center to the cloud. In this case, the cloud is the virtualization used over a data center to make the functionalities more flexible. Many companies like GoDaddy, Expedia, Netflix, startups, etc., have recently moved their business to the cloud. Migration is a big task and AWS facilitates migration in phases.

Need for Migration

Business is no easy task when handling situations like security, scaling up or down, etc. Let’s look at a few scenarios where AWS Migration could be a better resort.
1. More users coming in amid high-performance
2. Faster implementation and deployment needs
3. Expensive to manage a growing database
4. Datacenter mishap went down
We can conclude that the following are key reasons to migrate to the cloud:
- Zero capital cost on infrastructure
- Security
- Scalable (vertically and horizontally)
- Productivity
- Pay what you use
- Easy to manage services
- Reduced operational costs
If you migrate to the cloud, the abovementioned problems will be handled automatically. Let’s move further and understand what migration is.

Phases of AWS Migration

AWS Cloud Migration is a step-by-step process that consists of planning, preparation and discovery, migration and optimization. However, it is more complex as the process involves different phases. Let me now talk about the various phases of migration.

Phase 1: Migration Preparation and Business Planning

In this phase, you identify the need, objective and benefits of cloud migration. You perform a POC and verify the outcome to compare the performance and costs. There are also times when you need not move your entire business to the cloud. This is where segregation is important. You need to identify the applications which can be migrated and those which cannot. This is what the first phase is all about.

Phase 2: Assessment — Choosing Your Migration Method (Discovery and Analysis & Assessment)

The first step is to identify the assets that need to be migrated to the cloud — gather the details such as the number of servers to migrate, road map to migration, record business-critical activities, server size, memory utilization, CPU utilization, environment type and data. You can use the ‘AWS Application Discovery Service’ to check the technical details by installing it in your server. Depending on the data, AWS provides different ways to migrate your application, e.g., AWS Snowball, AWS Snowmobile, AWS Direct Connect, etc. Also, assess the cost of renting servers, storage, network and support. Prepare the checklist for regulatory and compliance assessment and perform the security assessment.

Phase 3: Proof of Concept (POC) for AWS Storage/Designing

Once you know how and what you are migrating, next, you must plan your delivery priorities and design the AWS Cloud Migration process. You will identify the dependencies (upstream and downstream components). Define the organization or account strategy for users, VPC strategy and what cloud pattern it will be (hybrid/fully cloud) and other parameters like security.

Phase 4: Migration to AWS

Now that you have all the prerequisites such as the blueprint, migration tools, a list of assignments, backups, and its synchronization with your on-premises data repositories, you can finally migrate your project/application to AWS Cloud. Once you have migrated your project to the cloud, reliability and durability are the added benefits you get. For application code/server migration use AWS Server Migration Service, for database, you can use AWS Database Migration Service and other import/export AWS services.

Phase 5: Enterprise Cloud Operations (Operate and Optimize)

At this point, you have already migrated to AWS and it will bring updates that you would need to incorporate in your existing architecture. Optimize your architecture, have your support team ready to look for the new features and cost optimization, improve the applications using serverless, use AWS monitoring and logging services and implement CloudFormation and DevOps.

Application Migration Strategies ‘The 6 Rs’

The complexity of migrating existing applications varies, depending on the architecture, Amazon came up with different strategies which they commonly termed as 6 R’s. Let’s look into each of them:

Benefits of AWS Migration
1. Elasticity: Adding and removing capacity whenever it is needed is the greatest benefit of
2. Disaster Recovery: With 95% guaranteed uptime, businesses can be confident knowing that their data will always be available.
3. Enhanced Cost Management: The IaaS platform provides two major First, an IaaS such as Amazon Web Services is available as a monthly service. Second, it eliminates the need to continue to purchase and maintain physical hardware.
Services for AWS Migration

Out of the many tools provided by Amazon to automate data migration, I will be talking about the more commonly used ones.

AWS Migration Hub: AWS provides a single location for tracking the migration process. Migration Hub gives you the freedom to choose your migration partner and tools that fit your needs.

AWS Server Migration Service (SMS): AWS SMS is an agentless service that helps migrate loads of on-premises workload to AWS easily and faster. It allows you to automate migration and track the replication of the server. It makes coordinating with your large-scale-server migration easier.

Amazon S3 Transfer Acceleration: This makes the transfer of files over long range to the AWS S3 bucket faster and more secure.

AWS Snowball: It is a petabyte-scale data transfer solution that uses secure devices to transfer a large amount of data in and out of AWS.

AWS Snowmobile: It is an exabyte-scale data transfer solution to move an extremely large amount of data to AWS. Snowmobile makes the transfer of massive volumes of data easier.

Amazon Kinesis Firehose: It is the easiest out of all the methods. It can capture and automatically load streaming data into Amazon S3. You can analyze real-time data to get timely insights of the migration.

Now that you know everything about AWS, and AWS Migration, let me show you a use case where you will be migrating a Virtual OS from my local machine to AWS Cloud.

AWS Data Migration

Data can be moved from on-prem to AWS Datacenter using the following means:
- Amazon S3 Transfer Acceleration — for faster transfer over the internet change the endpoint you use with your S3 bucket and acceleration is automatically applied.
- AWS Snowball — a petabyte-scale data transport solution that uses secure appliances to transfer large amounts of data into and out of AWS.
- AWS Direct Connect — you establish a dedicated network connection between your network and one of the AWS Direct Connect locations for transfer.
Demo: Implementing Migration Using the Import/ Export Method

You will be migrating an on-premises Virtual OS running on VMWare to AWS using the import/export (AWS Direct Connect) method.

Pre-requisite
Create a .vmdk export file for Ubuntu 14.04.
1. Download and configure AWS
1. Create an IAM
IAM – User —Add User —AccessType (Programmatic Access) —Attach Admin Access Policy —Create User.
1. Create an S3 bucket and add a file (image file of the OS).
2. You can upload the file using AWS CLI aws s3 cp “source path” <s3 bucket>
3. Once the file is uploaded, create an AMI for the imported image
Aws ec2 import-image –description “AWS Linux” –disk-containers file://containers.json
1. Now your AMI is available, and you can see it under AMI in EC2 and run it as and when
Thus, we have successfully migrated a virtual OS on AWS.

By now you should have a fair idea about the AWS Cloud Migration strategy and the process, tools and transfer mechanisms available.
August 31, 2024
Polyfill Becomes a Supply-Chain Risk to 100,000 Websites

A Chinese company in February bought the domain and GitHub account for Polyfill, a popular open-source library used by more than 100,000 websites to deliver JavaScript code.

In the months since the acquisition by Funnull, the domain – cdn[.]polyfill[io] – has been used to deliver malicious code to devices via the websites that embedded the domain, redirecting users to sports betting and pornographic websites based on their region and opening the door to other attacks, such as formjacking, clickjacking and other data theft, according to researchers.

“This incident is a typical example of a supply chain attack,” the threat intelligence group of cybersecurity vendor Sansec wrote in a blog post. “The code has specific protection against reverse engineering, and only activates on specific mobile devices at specific hours. It also does not activate when it detects an admin user. It also delays execution when a web analytics service is found, presumably to not end up in the stats.”

Some users were presented with a fake Google Analytics domain that redirected them to these other sites, according to Simon Wijckmans, founder of security firm c/inside. In early March, those maintaining the Polyfill domain also added a Cloudflare Security Protection header to the site, though the purpose of the header wasn’t clear.

Cloudflare officials wrote in a blog post the company “has never recommended the polyfill.io service or authorized their use of Cloudflare’s name on their website. We have asked them to remove the false statement, and they have, so far, ignored our requests. This is yet another warning sign that they cannot be trusted.”

100,000 Sites at Risk

“This attack places an estimated +100k websites at immediate risk,” Wijckmans wrote in an alert. “When a once safe domain is embedded in thousands of websites and concealed like JavaScript threats are, it becomes a tempting path for malicious actors.”

The Polyfill open-source project lets websites use modern JavaScript features in older browsers by including only necessary polyfills based on the user’s browser, Wijckmans wrote.

Companies have been reacting since the reports from cybersecurity researchers about the situation came out this week. Google started blocking ads for e-commerce sites that use the Polyfill domain and Cloudflare reportedly implemented real-time rewrites of the domain to its own version. In addition, the domain registrar and web hosting company Namecheap put the domain on hold.

That will eliminate risks for now, but Sansec is encouraging developers to remove Polyfill references in their code.

Polyfill Comes Back Swinging

That said, the owner of Polyfill.io isn’t backing down. They reportedly have relaunched their JavaScript content delivery service (CDN) under a new domain and are pushing back against the accusations, claiming in a post on X (formerly Twitter) that media reports were slandering them and that there are no supply chain risks.

In another post targeting Cloudflare for its “repeated, baseless and malicious defamation” and its “unethical strategy of suppressing competition before promoting their own products,” the Polyfill.io owner said they are “fully dedicated to developing a global CDN product that surpasses Cloudflare, showcasing the true power of capital.”

They said they’ve secured $50 million in startup funding and finalized the product design.

Early Warnings

The industry was warned about Polyfill soon after Funnull bought it, with Andrew Betts in a post on X telling websites using the domain to “remove it IMMEDIATELY.” Betts explained that he created the project but never owned it and had no influence over its sale.

In addition, c/side’s Wijckmans that many popular CDN providers “have since created their own forks, giving users a safer choice. Most browsers have evolved to make this no longer necessary anyway.”

He pointed to another website, Polykill, created three days after the sale to Funnull to make developers aware of what the site’s developers called a “major JavaScript supply chain vulnerability.”

“There are many risks associated with allowing an unknown foreign entity to manage and serve JavaScript within your web applications,” the Polykill creator wrote. “They can quietly observe user traffic, and if malicious intent were taken, they can potentially steal usernames, passwords and credit card information directly as users enter the information on the web browser.”

A Perfect Storm

The situation caught the attention of the security industry. Eyal Paz, vice president of research of OX Security, said the “recent Polyfill supply chain attack highlights a critical issue with current-day web development: the trust placed in third-party libraries. Add to it the fact that many organizations lack the ability to track the longtail of the software supply chain and we’re looking at the perfect storm of unmanaged cybersecurity risk.”

The case raises concerns about the security standards for the open source ecosystem when a company is acquired by another nation, said Sarah Jones, cyberthreat intelligence research analyst at Critical Start.

“Polyfill.io’s widespread adoption across various industries, including e-commerce, finance, media and entertainment, and healthcare, provides a vast network of websites for malicious actors to exploit,” Jones said.

Polyfill and other platforms that host widely used open source code are typically considered trusted sources, but carry a “use at our own risk” warning, said Ngoc Bui, cybersecurity expert at Menlo Security.

“Due to the extensive reach of open-source repositories like these, the potential impact of any issues will be difficult to measure,” Bui said. “Secure coding practices are crucial to ensure that modifications sourced from these repositories do not result in damage.”

June 28, 2024
RIP CentOS. Hello AlmaLinux Rocky Linux, CentOS Stream or RHEL
CentOS 7’s official end of life is June 30th, 2024. What should a DevOps team do? Here are your choices.

Back in December 2020, Red Hat, CentOS‘s Linux parent company, announced it was “shifting focus from CentOS Linux, the rebuild of Red Hat Enterprise Linux (RHEL), to CentOS Stream, which tracks just ahead of a current RHEL release.” CentOS users were upset, and many never stopped using the last supported version of “classic” CentOS, CentOS 7.

Just how popular is CentOS 7? According to LanSweeper, an IT asset management company, 26% of the 200,000 Linux devices they scanned run CentOS. According to Web Technology Servers’ count, CentOS is still used by 2.4% of all websites.

Why have so many stayed loyal to a dying operating system? For years, CentOS was the default choice of web hosting companies. The Linux distribution was fast, free, and reliable. Sure, if you needed top-notch tech support, RHEL was the operating system of choice in the Red Hat Linux family. But not everyone needs handholding. If you could manage a Red Hat Linux variant without tech support, especially for the express purpose of web serving and related server applications in the Linux, Apache, MySQL, PHP/Python/Perl (LAMP) family, CentOS was all you needed. And DevOps, like anyone else, are happy to operate on the “If it ain’t broke, don’t fix it” sentiment.

Now, however, it’s time to change. “Operating on a deprecated version of CentOS poses several significant risks,” said Esben Dochy, Lansweeper’s senior technical product evangelist. “Without continued support, these systems will no longer receive critical security updates, leaving them highly vulnerable to cyberattacks. Additionally, compliance with industry regulations and standards will be jeopardized, potentially leading to severe legal and financial consequences. Operational inefficiencies are also a concern, as deprecated systems may face compatibility issues with new software and hardware, causing disruptions and decreased productivity.”

Using a deprecated operating system may be okay for personal needs – but not for DevOps teams responsible for an organization’s infrastructure. If you really, really can’t switch from RHEL 7/CentOS 7, you might consider purchasing RHEL 7 Extended Lifecycle Support.

CentOS Alternatives

So, what can you do? The good news is you have several choices:

Red Hat, of course, hopes you’ll switch to RHEL 8 or RHEL 9. The company tries to make the transition easier using Red Hat’s DevOps tools, such as Red Hat Insights (which comes with RHEL subscriptions), the Red Hat Satellite add-on, and Convert2RHEL to convert multiple systems at the same time. Concert2RHEL can also be used to move from other RHEL-style Linux distros to RHEL. Ansible users can also use this powerful infrastructure as code (IaC) DevOps tool to automate CentOS to RHEL.

For CentOS users who run instances on the major hyperclouds, including AWS, Azure, and Google Cloud, Red Hat offers Red Hat Enterprise Linux for Third-Party Linux Migration. These migration tools are designed to assist users of CentOS 7 in smoothly converting in-place instances to RHEL 7.

Some of you may be asking – with reason: Wait, doesn’t RHEL 7 also reach its end of life on June 30th? Well, yes, sort of, but not really. Red Hat recently announced a new program, Extended Life Cycle Support (ELS) for Red Hat Enterprise Linux 7. Subscribers get a four-year add-on to provide security patches and updates through June 30, 2028.

Or, if you’re bound and determined to stick with CentOS 7, you can choose one of several third-party companies that offer CentOS 7 extended support, with critical updates and security patches beyond the official end-of-life date. These include:
- CIQ Bridge: CIQ offers a service that extends CentOS 7’s operational lifespan by up to three years, including critical updates and security patches.
- OpenLogic: OpenLogic’s long-term support program extends support through December 2029. Indeed, it even provides support for the long out-of-date CentOS 6.
- TuxCare: TuxCare offers extended lifecycle support for CentO S 7, ensuring continued security and stability for systems that cannot be immediately migrated.
You could also move to CentOS Stream, Red Hat’s RHEL development Linux distro. Stream is a rolling-release Linux distribution, which means it continuously receives updates, including the latest features, bug fixes and security patches.

On the plus side, Stream is free and offers the newest updates. On the other hand, Stream is not designed for production use. As a continuously delivered distribution, it doesn’t have the same level of stability as traditional CentOS or RHEL. It also doesn’t have an upgrade mechanism between major versions, nor does it have commercial support.

From my perspective, Stream is fine for cutting-edge developers but not for business use. Even if you automate managing CentOS as much as possible with DevOps tools, it will be a pain to manage.

You can also switch to a third-party RHEL clone, such as AlmaLinux 8.10 or Rocky Linux 8.10. Both are free to use and work quite well. I use both on my own servers. I’m far from alone. According to statistics collected by the Fedora Extra Packages for Enterprise Linux (EPEL) Special Interest Group, a project that tracks the RHEL Linux family’s use of popular third-party Linux applications, Rocky Linux is now the most popular RHEL-style Linux with close to a million instances running, followed by RHEL and AlmaLinux.

Both AlmaLinux and Rocky Linux offer CentOS 7 migration tools. With Ascender, an open-source Ansible AWX fork, you can also automate the transition from CentOS to Rocky Linux. if you haven’t looked at either yet, it’s high time you did.

You see, the clock has run out. CentOS 7 has been a loyal servant for years, but it’s time to let that servant retire and move on to something new and safer. Yes, you can keep using it with third-party support, but it’s time to move on.
June 6, 2024
Tools for Sustainability in Cloud Computing

Cloud computing is a primary driver of modern technological advancements. However, as cloud services adoption continues to soar, so does a concern for their environmental impact. The further expansion of cloud infrastructure will demand more energy, which means the need for sustainable solutions has never been more acute.

Due to their scale, cloud vendors operating large data centers have a greater impact on minimizing the IT’s industry overall carbon footprint than do smaller on-premises deployments. In this article, we highlight the main benefits of migrating business operations to the large-scale cloud providers known for their established sustainable practices, and point to useful resources.

Follow the Leaders

Major cloud platforms, including Google Cloud Platform, Amazon Web Services and Microsoft Azure, have pledged to achieve net-zero carbon emissions in their data centers by 2030. These platforms are well-positioned to lead the adoption of sustainability principles in cloud engineering due to their reputation and global reach.

Microsoft’s study on the carbon benefits of cloud computing showed that an enterprise could reduce its carbon footprint by up to 98% by migrating to Microsoft Cloud, compared to running its IT operations in the on-premises data center.

As for Google Cloud, all of its cloud products are carbon neutral. Google achieves this by purchasing renewable energy to reduce the carbon footprint from operations performed on its infrastructure, as well as by using high-quality carbon credits to compensate for its remaining carbon emissions.

By moving your operations to the cloud and focusing on developing cloud-based applications, you can contribute to sustainable business practices and overall carbon footprint reduction.

Increase Energy Efficiency

Public cloud platforms rely on large-scale data centers with advanced infrastructure technologies. That allows them to reduce electricity consumption for overhead tasks such as lighting, cooling, and power conditioning. For example, according to Google’s environmental report, its data centers consume half the energy needed to power an average on-site data center.

Energy efficiency is also driven by higher server utilization rates and the ability to manage workloads flexibly. These are the main factors that allowed AWS to make its data centers 3.6 times more energy efficient than a median data center run by a U.S. company.

Additionally, the innovative approach applied to server architecture design in large data centers enables cloud service providers to develop custom hardware optimized for their customers’ workloads.

Big Names are Committed to Sustainable Software Development Practices

Another environmental benefit of running IT operations in the cloud is that public cloud platforms are committed to sustainable software engineering – and they want to make it feasible for anyone who uses their platforms.

Green (or sustainable) software starts at the design phase, considering carbon emissions as a project requirement. According to the Green Software Foundation, sustainable software applications are carbon efficient (can run on fewer machines and resources), energy efficient (require less energy to perform the same tasks), carbon aware (prioritize renewable energy sources as a power source) and hardware efficient (use less hardware).

IT operational efficiency is a fundamental of sustainable software engineering. Since cloud service providers already apply advanced technology to improve the energy and hardware efficiency of their infrastructure, cloud migration is a good start for supporting green coding.

Microsoft developed eight principles of sustainable software development for engineers to follow when they build, design, and deploy applications. You can apply these principles to all types of applications, whether deployed on-premise or in the cloud.

Amazon released a sustainable architecture guide with strategies for applying sustainability practices to optimize AWS infrastructure compute, storage and network layers. AWS also provides guidance on applying environmental best practices for designing and operating workloads in the cloud.

A Tools Roundup for Measuring and Reporting Carbon Emissions

In addition to implementing sustainability practices in their business operations, cloud platforms offer clients tools to monitor and measure carbon emissions linked to cloud service usage and report their overall carbon footprint following greenhouse gas protocol standards.

Google Cloud provides users with an emissions calculator. Using Carbon Footprint, you can track the emissions from running your applications. The tool lets you view and analyze data related to gross carbon emissions and use derived insights in emissions reports.

AWS also offers the Customer Carbon Footprint Tool for emissions tracking. You can calculate their carbon emissions associated with using AWS services, track emissions after migrating to the cloud, and use the data for sustainability reporting purposes.

Microsoft customers can access the Emissions Impact Dashboard to estimate their carbon footprint related to Microsoft Azure and Microsoft 365 cloud services. Microsoft also offers Cloud for Sustainability for tracking and managing carbon emissions. It gives you visibility into your organization’s environmental impact, aggregates data from various sources, and offers practical recommendations for reducing a carbon footprint.

Energizing Thoughts

Achieving “net zero” is not solely the responsibility of large-scale cloud providers. Businesses must also contribute. Itransition’s cloud consultants believe that if more companies move their IT operations from on-premises servers to the public cloud, overall energy consumption and related carbon footprint will decrease.

By leveraging renewable energy sources, optimizing infrastructure for energy efficiency and employing innovative technologies, these leading cloud platforms can attract a cohort of environmentally conscious clients. Those users may consider switching to the cloud not only for direct business benefits but also to make their operations more sustainable.

Photo credit: Aimable Mugabo on Unsplash

April 12, 2024
Survey Sees AI Playing Larger Role in Test Automation

A survey of 1,028 senior IT professionals and application developers in the United Kingdom, U.S., Germany and Singapore finds nearly half (47%) still use manual testing for mobile applications. More than a third (38%) noted that their organization could save between half and three-quarters (51-75%) of funding allocated to testing per year by fully automating mobile application testing.

Conducted by the market research firm Censuswide on behalf of Tricentis, a provider of a test automation platform, the survey also found that just under half of respondents (49%) reported their organization is already applying artificial intelligence (AI) to application testing. Another 21% plan to apply AI in the next six months. Almost three-quarters (74%) said their organization’s general sentiment toward AI in mobile software development testing is positive.

Respondents also expected AI to improve mobile application quality (37%), increase productivity (36%) enhance end-user experience (34%) and to reduce the number of vulnerabilities and/or bugs (32%) in their applications.

Mav Turner, chief product and strategy officer at Tricentis, said that rather than continuing to rely on expensive testing services, more organizations are looking to reduce costs by automating a wider range of testing workflows within the context of a DevOps workflow. In fact, the survey finds just under a third of respondents (32%) expect their organizations will invest more than $1 million to further automate testing.

As modernization of testing processes continues, the return on investment in mobile application development will only continue to improve, noted Turner.

The survey identifies the primary benefits of investing in test automation, which are increased productivity (32%), increased revenue (31%), increased user retention (28%) and increased compatibility across devices (28%).

The primary obstacles organizations encounter as they strive to achieve that goal are competing priorities (28%), lack of technology and talent (25%), time (25%) and cost (24%), the survey finds.

A full 87% said the quality of mobile applications is critical to their business, with 90% noting that poor mobile application quality costs their business as much as $2.49 million in lost revenue per year. However, just over a quarter (27%) said they believe their organization’s current mobile application development and testing strategy exceeds expectations.

As part of efforts to automate testing, it’s not clear just how far responsibility for testing is shifting left toward developers, but there is no doubt many more are being exposed to the results earlier in the software development life cycle. The goal is to provide continuous testing capabilities without overly disrupting code writing. It’s also becoming simpler for developers to leverage generative AI tools to provide summaries of tests along with recommendations to improve code. The end result should be higher-quality applications that require less troubleshooting once deployed in a production environment.

In the meantime, as organizations continue to become more dependent on mobile applications to drive a wide range of digital transformation initiatives, the cost of testing will continue to pale in comparison to the potential amount of lost revenue that might occur when end users either don’t invoke a specific feature or capability or, more commonly, simply abandon the application altogether.

March 29, 2024
appCD Launches Platform to Securely Provision Cloud Infrastructure

appCD this week launched a namesake platform that analyzes an application about to be deployed to automatically generate the code needed to provision the IT infrastructure required.

Fresh from raising $6 million in seed funding, appCD CEO Sachin Aggarwal said that approach makes it possible to consistently create secure code for provisioning IT infrastructure versus requiring developers with little to no cybersecurity to manually write it.

Instead, appCD reviews Python or Java code to understand intent, identifies dependencies and then infers application programming interface (API), service configuration, ingress/egress and other environment variables. Terraform code or Helm charts are then automatically generated based on the static analysis of the code that has been reinforced using artificial intelligence (AI) learning techniques.

That approach also makes it simpler for platform engineering teams to centrally manage the provisioning of IT infrastructure using a set of pre-defined policies that are automatically implemented each time an application is deployed to ensure security by default, he added.

DevOps teams can also use appCD to visualize the deployment environment before and after an application is deployed, said Aggarwal.

While infrastructure-as-code (IaC) tools have accelerated the rate at which cloud infrastructure can be provisioned, they are also often the root cause of the security issues that plague cloud computing environments. Developers often misconfigure cloud infrastructure by, for example, inadvertently leaving ports open. The appCD platform reduces the potential such mistakes will be made, noted Aggarwal.

That capability also eliminates the need to attach cybersecurity specialists to a DevOps team because issues are automatically resolved by the guardrails enforced by appCD, he added.

In theory, at least, there may soon come a day when AI routinely improves the quality of the code being used to both build and deploy applications. The more the code used to train a large language model (LLM) is vetted, the more reliable the output becomes. In the meantime, platforms such as appCD are combining static analysis with AI reinforcement learning to achieve that same goal in a use case that is specific to generating code to provision IT infrastructure.

Each DevOps team will naturally need to determine the best path forward, but as regulations pertaining to securing software supply chains become more stringent, it’s only a matter of time before organizations will be required to embrace DevSecOps workflows. In the meantime, DevOps teams should assume that given the probability cloud infrastructure has been misconfigured, it’s all but certain there will be multiple cloud security incidents. In fact, cybercriminals are actively scanning for misconfigurations that they have already created playbooks to specifically exploit in a matter of minutes.

In the absence of being able to prevent all those issues from arising, the immediate priority becomes remediating as many issues as possible before cybercriminals exploit those vulnerabilities. However, it’s also important to draw a proverbial line in the sand to ensure that all cloud infrastructure being provisioned in the future is much more secure than it has tended to be thus far.

March 7, 2024
Permiso Makes Open Source Tool to Identify Cloud Threats Available

Permiso today launched an open source tool dubbed CloudGrappler that surfaces indicators of compromise in cloud computing environments.

Based on a cloudgrep project originally created by Cado Security, CloudGrappler detect patterns that Permiso, a provider of an identity threat detection and response platform, associated with tactics and techniques commonly used by various cybercriminal syndicates.

The tool enables DevSecOps teams to define the data sources they want to scope in a scan of an Amazon Web Services (AWS) or Microsoft Azure cloud. Via a JSON file, DevSecOps teams can access a list of predefined tactics, techniques and procedures (TTPs) that are commonly used to exploit cloud computing environments. DevSecOps teams can also dynamically add queries or a file with multiple queries to scan a specific data set. After scanning, CloudGrappler delivers a JSON report that provides a breakdown of the scan results.

Ian Ahl, senior vice president for P0 Labs, the research arm of Permiso, said that capability makes it possible for DevSecOps teams to identify issues in cloud computing environments that warrant further investigation before there is a major incident. The primary goal is to make it simpler for DevSecOps teams to determine if they need additional assistance to thwart a potential threat, he added.

Cybercriminals are, like almost everyone else, creatures of habit and often tend to leverage the same TTPs multiple times simply because they know they’re effective. However, those TTPs also provide clues to their presence in an IT environment. Once discovered, a DevSecOps team can decide if they can remediate the issue themselves or need to tap external cloud security expertise, noted Ahl.

In general, cloud computing environments may be more secure than most on-premises IT environments. However, the processes used to provision cloud computing environments are often flawed because developers typically don’t have much cybersecurity expertise. Misconfigurations are often rife across cloud computing environments.

Cybercriminals are also especially adept at stealing credentials to gain initial access to cloud computing environments, which they leverage to escalate privileges in a way that provides them unfettered access to the entire cloud computing environment.

Adoption of DevSecOps best practices has improved cloud security, but there are still plenty of instances where, for example, a port inadvertently left open has enabled cybercriminals to infest a cloud computing environment with malware that could lie dormant within cloud applications for months before finally being activated.

There are simply not enough cybersecurity experts available to secure cloud computing environments, so it’s going to be largely up to DevOps teams to secure them. The issue is that in the race to build and deploy applications as quickly as possible, cloud security best practices are either forgotten or simply ignored. Of course, it’s that very carelessness that cybercriminals are counting on to allow them to wreak havoc in an era where the percentage of mission-critical applications running in cloud computing environments will only continue to increase exponentially.

March 7, 2024