devopsy.kinsta.cloud

Tag: Cloud Computing

AWS AI Agent Surfaces Recommendations to Optimize Cloud Computing Environments

Amazon Web Services (AWS) today made available a preview of an artificial intelligence (AI) agent that surfaces recommendations to optimize cost, security, performance and resilience based on the business objectives an organization defines.

Jill Fariss, vice president of AWS Support, said the AWS Well-Architected Agent generates code that can be implemented via a command line interface (CLI), an infrastructure-as-code tool or some type of runbook automation.

The overall goal is not to eliminate the need for humans to manage IT infrastructure but rather make it simpler for engineers and IT administrators to manage workloads at much higher levels of scale, added Fariss. That capability is critical because most organizations today simply don’t have enough IT staff to effectively manage and optimize the workloads they currently have deployed, an issue that is only going to be further exacerbated as advances in AI make it possible to build and deploy even more applications, she noted.

The AWS Well-Architected Agent is designed to function much like a cloud architect that continuously correlates metrics, resource configurations, and application topology that are then analyzed using a set of best practices that AWS has defined across more than 65 of its services. Based on the goals an organization might have, it will then surface recommendations that highlight the tradeoffs that might need to be made to achieve one goal versus another, said Fariss.

In addition to presenting those consolidated findings, the AWS Well-Architected Agent also provides step-by-step remediation guidance and, when applicable, the costs that might be incurred. DevOps engineers or an IT administrator can define the business goals they are trying to meet or, alternatively, opt to run AWS Well-Architected Agent simply to discover issues and suggestions for resolving them.

It’s not clear what the future will hold for DevOps engineers and IT administrators in the AI era, but the only thing that is certain is the level of expertise required to manage complex IT environments will continue to steadily decline. In some cases, organizations will opt to rely on smaller teams of engineers to manage workloads at much higher levels of scale. In other cases, organizations may opt to augment IT administrators that typically cost less to hire and retain.

Regardless of approach, each organization will ultimately need to determine the scope of the tasks that it is comfortable with an AI agent automating with little to no intervention on the part of an IT professional necessarily being required. For now, however, AI agents that are deployed to optimize IT operations still need to establish a level of trust, said Fariss.

IT teams, ultimately, should expect the number of AI agents being made available by providers of IT infrastructure to only increase in both number and capabilities. The challenge and the opportunity then becomes determining precisely where the separation of duties and responsibilities between various AI agents and the humans that supervise them is going to lie not just today but, more importantly, a few short months from now as the capabilities of AI agents continue to expand and evolve.

October 1, 2026
Your DevOps Pipeline Is Already a Sustainability Program

During my doctoral research on modern engineering practices and operational efficiency, one pattern kept surfacing that I did not expect to find. The engineering teams making the most measurable progress on sustainability were not the ones that had appointed green committees. They were the ones running tight DevOps discipline: right-sized fleets, lean pipelines, tuned alerting, progressive rollout, carbon-aware routing. The same practices that cut cost and toil were quietly cutting emissions at the same time. Nobody was measuring it that way.

That observation became a thread I kept pulling. The more I looked at how modern engineering practices drive operational efficiency, the more I found sustainability outcomes hiding inside work that engineering teams were already doing, and already getting credit for on the cost side. The carbon savings were real. They just were not being captured. The problem is not that enterprises lack green intent. It is that sustainability is being treated as a separate program with a separate mandate, when the evidence points to it being a byproduct of engineering discipline that already exists.

Separated programs fail for a structural reason. When the sustainability initiative does not control the pipeline, the link between the action and the saving never closes, because the team driving the outcome is not the team measuring it. Meanwhile, cost and carbon move together in a way that is easy to underestimate. At enterprise scale, idle compute across hundreds of services compounds into material emissions, not rounding errors, and the savings do not stack in isolation either. Better pipelines, leaner fleets, and smarter deployments reinforce each other over time, so each practice makes the next one easier. The gap has never really been about action. Most teams are already doing the work. Few are capturing the outcome. The greenest practice is often just good engineering, measured.

Seven practices show that pattern most clearly. Each produces a sustainability outcome as a direct consequence of engineering done well. None of them require a GreenOps mandate to deliver results.

Cloud Right-Sizing and Autoscaling

Idle compute is waste an enterprise pays for and emits for at the same time. Horizontal autoscaling adds and drops instances as real demand rises and falls, and right-sizing matches instance type to actual CPU and memory profiles rather than to a conservative guess made at provisioning time. Scaling to zero lets idle services drop to nothing overnight instead of running unattended, and spot or burstable capacity absorbs fault-tolerant workloads that most organizations still run on full-price, always-on instances. At enterprise scale, the blocker is rarely technical. It is that the team owning the deployment configuration is rarely the team paying the cloud bill. Closing that ownership gap is what makes the tooling work.

Build and Pipeline Efficiency

A 30-second build saving multiplied over 500 daily builds across 50 teams is a material compute reduction, and most organizations have never measured it. Layer and dependency caching, incremental builds, smart test selection, and slimmer container images each look like housekeeping in isolation. At fleet scale, run thousands of times a day, they are compounding efficiency. The saving is not in any single build. It is in the multiplication.

Git Discipline

Undisciplined Git practices are one of the most overlooked sources of wasted CI/CD compute in large engineering organizations. Every unnecessary pipeline run, stale branch scan, and redundant trigger is compute nobody asked for and nobody noticed. Deleting merged branches, scoping pipeline triggers to the events that actually require them, avoiding redundant runs from duplicate pushes and manual re-runs, and enforcing artifact retention policies are governance decisions as much as hygiene. Every pipeline that did not need to run is compute that was paid for and emitted, and Git discipline is where that starts.

Alert-Driven Provisioning

Noisy alerts drive reactive over-provisioning, and the reason it persists is an asymmetric incentive: teams get paged for under-provisioning but face no consequence for carrying excess capacity. Killing false positives, alerting on user-facing symptoms rather than internal blips, grouping and deduplicating alert storms, and provisioning to measured load rather than to worst-case fear all change provisioning behavior, not just on-call quality. Fear-based buffers can be a major sustained source of idle compute in mature fleets, and the provisioning problem is downstream of the alerting problem.

Zombie Environment Cleanup

Orphaned development and test environments persist not because nobody thought to clean them up, but because ownership is ambiguous and deleting them requires confidence that nothing still depends on them, confidence most organizations do not have. Ephemeral environments that spin up on demand and tear down after use, a strict expiry on every sandbox with no extension unless a named owner renews it, and infrastructure-as-code reproducibility that rebuilds an environment instead of keeping it warm indefinitely all remove the reason to let one linger. Legacy environments that predate infrastructure-as-code adoption need their own remediation track before teardown is safe. A zombie environment burns compute for no one, and the fix is ownership mapping, not just automation.

Progressive Rollout and Blast Radius

Shipping to a small slice of the fleet first and ramping traffic only as health signals stay green cuts the compute cost of a failed deployment directly, since a contained failure costs a fraction of what a full rollback requires. The larger sustainability gain is second-order. When blast radius is bounded, teams no longer need to carry excess standing capacity as insurance against a full-fleet incident, so the safety buffer shrinks because the risk that justified it shrinks first. At enterprise deployment frequency, the cumulative compute saved by avoiding full rollbacks compounds significantly over time. Fewer failed deploys means less wasted compute, and a smaller blast radius means less standing capacity carried just in case.

Carbon-Aware Cloud Routing

Static region assignment is a legacy architecture decision dressed up as an operational default. Modern cloud governance can route workloads dynamically on traffic patterns, risk-tolerance windows, time-of-day load profiles, and carbon-intensity signals from providers including Electricity Maps and the cloud providers themselves. Batch and reporting workloads can shift to off-peak windows in lower-carbon regions. Failover and cutover rules built for resilience can carry carbon intensity as a weighted factor alongside latency and cost, so that when a resilience event triggers a regional shift, routing toward a cleaner grid is a policy option rather than an afterthought. The infrastructure already supports this. Most teams have not built the routing policy to use it, and framed correctly, carbon reduction arrives as the byproduct of resilience architecture rather than as a separate mandate.

The organizations that will lead on sustainable engineering will not be those that stood up the most ambitious green programs. They will be those that added carbon and compute efficiency as measured outputs of the engineering work they were already running, tracked continuously alongside reliability and cost, rather than treating it as a retrospective claim. Eliminating the waste produces both financial savings and emissions reductions, because they are the same signal measured from two directions. Right-sized fleets support better alerting thresholds, better alerting supports tighter provisioning, and tighter provisioning reduces the capacity buffers that inflate rollback blast radius in the first place. Each practice makes the next one easier. That measurement, byproduct rather than branding, is what most organizations are still missing.

September 4, 2026
DevSecOps In Digital Banking: Balancing Fast Releases With Regulatory Compliance

In the digital banking sector, fast releases of new features and security patches have become the norm. Unfortunately, many institutions lack the organization or the processes necessary to make the speed of necessary releases coincide with the need to follow strict regulatory guidelines. A failure to accurately test and ensure compliance can lead to critical errors. Slow processes to confirm these aspects often lead to delayed release dates. By implementing a unified DevSecOps into their processes, institutions can find an efficient middle-ground between the pressure to release frequently and the necessity of maintaining security and compliance.

Challenges in Implementing DevSecOps

Siloed Processes

Historically, organizations tended to keep development, security, and operations as separate teams. Even financial institutions that have done some work to modernize their development systems may still suffer from siloed departments and processes. A lack of overt processes designed to integrate these aspects of new feature development, release, and management can lead to teams failing to work with each other when necessary. As a result, there is a lack of efficient collaboration that contributes to delayed releases and unsatisfactory results.

Fragmented Workflows

Siloed departments usually go hand in hand with fragmented workflows that cut productivity and efficiency. Developers work on the feature independently of workflows designed to provide effective testing and audit preparation. This approach creates an excess of gatekeepers who can stop production working toward the final deployment. Progress can slow down or even stop based on conflicting timelines, diverging expectations, or even a single person taking an extended leave.

Team Conflict

This friction often contributes to conflict between teams that can be difficult to resolve mid-development. Developers may resist heavy scrutiny of their code and resent security and ops teams for flooding their queues with issues to resolve, when they are already pressured to perform quickly. Compliance teams feel squeezed between the pressure to avoid overcomplication and the legitimate need to ensure the system works correctly. All teams lack a sense of ownership over the whole.

High-Stakes Decision-Making

Everyone working on the release feels the pressure of getting it right, and for good reason. A simple oversight could lead to millions of dollars in penalties or lost productivity, or even a failed release. An increase in the frequency of the release schedule does not necessarily relieve the pressure for accuracy and competency. Rather, it triggers a seemingly unending cycle of stress about the next big goal, leading to burnout and continued resistance.

How to Integrate DevSecOps Into Digital Banking Processes

Create Unified Teams

To start integrating DevSecOps into existing systems, institutions need to create unified teams that have a shared vision and set of goals for the integration. Although the team development discussion necessarily involves details about what each release is intended to accomplish and how it will be done, it must also tie in a broader conversation about the importance and practical uses of DevSecOps integration. Gaining buy-in from all parties leads to less conflict when implementing new processes and systems.

Integrate Workflows and Timelines

A seamless feature release requires integration of workflows and timelines. Organizations should aim to standardize their processes for the release of new features, which will minimize extraneous discussion and disagreement during design phases. Instead of siloing workflows between departments, these processes and timelines should be integrated into the whole. Aligned goals and plans decrease bottlenecks in productivity and increase the likelihood of reaching deployment on the planned date.

Automate Processes

Automation becomes a key tool in achieving true integration of these aspects of feature releases without compromising efficiency or compliance. Automated processes like continuous monitoring, code scanning, and audit record-keeping can reduce the workload of testing and often increase accuracy. QA teams spend less time trying to replicate a problem when the system can automatically highlight the circumstances that trigger it. As such, developers receive updated feedback on their code as they develop it, leading to fewer issues near the end of production.

Front-Load Security Checks and Audit Prep

A standardized plan to front-load security checks and audit prep can help to keep the project on the rails and minimize extensive, unexpected delays shortly before the planned release date. Integration of systems like fraud and risk management solutions can seamlessly capture necessary data to generate issue tickets for developers or integrate into reporting systems. The ultimate result converts these processes into useful, practical steps toward the final release, instead of gates that hinder efficiency.

Integrating DevSecOps is not without its challenges. Institutions may face resistance from managers and teams who worry about how implementation could affect their processes. In most cases, DevSecOps can solve problems plaguing digital banking releases, like slow review processes or security lapses. By following these best practices, organizations can minimize the hurdles involved in a DevSecOps integration, while maintaining a strong commitment to accuracy, security, and compliance.

January 13, 2026
System Initiative Extends Reach of IT Infrastructure Automation Platform

System Initiative today revealed it is now extending the reach of its digital twin platform for automating the management of IT infrastructure to any cloud computing environment, including now out-of-the-box support for Microsoft Azure, Digital Ocean and Hetzner services, along with existing support for Amazon Web Services (AWS).

Nick Stinemates, vice president of business development and community for System Initiative, said the company’s namesake platform can now also discover all the application programming interfaces (APIs) being employed across any cloud service.

Armed with those capabilities, DevOps teams can now take advantage of templates to more easily redeploy workloads across those environments using visual tools that are integrated with the core System Initiative platform, he added.

Additionally, IT teams can create disaster recovery plans that span multiple cloud services, noted Stinemates.

At the core of the System Initiative platform is an IT infrastructure automation platform that creates a programmable model of an IT environment to provide an abstraction layer that enables software engineering to employ reactive code to manage IT infrastructure. In effect, it provides DevOps teams with a high-fidelity digital simulation to map the relationships between the various components of an IT environment. Instead of using infrastructure-as-code using more complex tools such as Terraform, DevOps teams can then make use of small amounts of reactive functions to configure the physical IT infrastructure that System Initiative has mapped.

System Initiative has also created a set of artificial intelligence (AI) agents to make its IT infrastructure automation platform even more accessible. Collectively, those capabilities make it possible to both visualize every live resource and relationship, including security and compliance checks and actionable suggestions to improve resiliency and performance.

It’s not clear to what degree DevOps teams are ready to rely on AI agents to manage IT infrastructure, but it’s apparent that, given the number of misconfigurations that exist, existing workflows are deeply flawed. It’s simply too easy for developers using tools such as Terraform to make a mistake. The System Initiative platform fundamentally reduces dependencies on scripts that are simply too brittle to manage IT environments at scale, said Stinemates

Of course, AI agents might also be prone to making mistakes, but there will be fewer of them, especially as those AI agents become more familiar with the specific IT environment they have been tasked to automate using the guardrails that System Initiative provides to ensure they only access relevant data, noted Stinemates.

No matter how IT infrastructure is provisioned, there will always be a requirement for it to be reviewed by a DevOps engineer, he added. The challenge and the opportunity now is to automate the management of IT infrastructure at a level of scale that doesn’t necessarily require a small army of DevOps engineers to build, maintain and document thousands of scripts.

In the meantime, however, DevOps teams would be well-advised to re-evaluate how existing workflows are managed with an eye toward streamlining as many existing processes as possible as the number of workloads that are deployed start to exponentially increase.

November 18, 2025
How AIOps is Revolutionizing DevOps Monitoring in the Cloud Era
Cloud computing and distributed systems move at lightning speed and standard monitoring tools are at risk of falling behind. The shift to more dynamic, interconnected and microservices-driven applications creates a deluge of telemetry data from distributed logs, metrics and traces that DevOps teams must sift through. AIOps is the next step in advancement, integrating modern-day smart tools – helping organizations by proactively detecting, diagnosing and resolving incidents in real time.

Why Traditional Monitoring Doesn’t Work

Before the cloud-native shift, DevOps teams could rely on fixed infrastructure and predictable application behavior. Monitoring tools would collect metrics like CPU usage, memory consumption and response time from static servers. But that doesn’t work today. The challenges include the following:
- Ephemeral architectures: Unlike traditional architectures, the architecture of modern-day applications are ephemeral with containers, serverless functions and microservices used to create short-lived components that can scale and handle massive workloads.
- Data explosion: The volume, variety and velocity of telemetry data (i.e., logs, traces and metrics) grow exponentially in today’s applications, which is extremely difficult to handle with traditional monitoring techniques.
- Human bottleneck: Manual efforts in legacy systems can’t keep up with the real-time demands of today’s applications that need high scalability. Moreover, legacy applications are not adept at leveraging AI and machine learning techniques for anomaly detection, predictive maintenance, or automated remediation.
AIOps removes these bottlenecks by automation, root-cause analysis and anomaly detection across massive, fast-changing environments.

What is AIOps?

AIOps is a practice that blends the power of AI with IT operations to improve operational processes in an organization. It achieves this via automation and optimization and enhancement of IT operations in an enterprise, and provides real-time visibility and predictive alerts to minimize operation issues and proactively resolve them if they arise. The key benefits of AIOps include the following:
- Reduced downtime
- Cost Savings
- Enhanced security
AIOps in Cloud-Native and Hybrid Environments

Cloud-native architectures make AIOps more useful than ever before. With dynamic scaling, multi-cloud deployments and serverless services, observability gets more and more complicated. AIOps simplifies this with unified data views, accurate analysis, and adaptive insights.

The key benefits of AIOps in cloud and hybrid environments include the following:
- End-to-end visibility across cloud platforms and on-prem systems through centralized observability.
- Dynamic scaling that can auto-allocate resources.
- Anomaly detection across distributed traces and service meshes.
- Hybrid data correlation for consistent incident management across cloud and legacy systems.
Integrating AIOps Into the DevOps Pipeline

To fully realize the potential of AIOps, you should integrate its capabilities at various stages of the DevOps lifecycle. These integration points include the following:
- CI/CD pipelines: AIOps is able to autonomously detect any anomalies in the build process, as well as in the deployments, and roll back. AI-powered insights are able to determine the best time to push releases out and to make the best use of available resources.
- Monitoring and Logging: Integrating AIOps into observability stacks by using monitoring and logging tools such as Prometheus, Grafana and Open Telemetry improves observability. It should be noted here that AIOps implements predictive rather than reactive monitoring.
- Incident Management: AIOps integrated with systems like ServiceNow facilitates the creation of tickets, setting priorities and prioritization of incidents.
- Security and Compliance: You can blend AIOps into the DevOps pipeline to identify any compliance issues and security threats in a proactive manner, thereby boosting the security of your DevOps workflow.
By analyzing the effects of any code changes in the application, operational events and incidents, AIOps can come up with insights to help future development, test coverage and operational practices in an enterprise.

Figure 1: Integrating AIOps into DevOps

The Future of AIOps in DevOps

AIOps is all set to have an excellent future in the years to come. It is predicted that with the introduction of generative AI, contextual chatbots will be capable of engaging in conversation with DevOps engineers at the systems level, synthesizing alerts and generating responses dynamically.

Here’s what the future holds for AIOps in DevOps practices:
- AI-driven conversation in operational dashboards
- A move from reactive to proactive capacity planning in complex multi-cloud systems
- A move toward AIOps integrated with GitOps workflows for deployment automation
- Continuous model retraining with contextual analytics on incidents
AIOps is likely to fulfil the long-standing goals of DevOps – helping you to build systems that are fully autonomous, resilient and self-optimizing. AIOps systems are capable of converging machine learning, big data analytics and automation in order to predict possible issues, rather than just react to them.

Conclusion

AIOps changes how companies observe, control and fine-tune IT activities within the context of the cloud and its services offered. With machine learning, analytics and automation, instance responses to actions are replaced by the more sophisticated predictions that AIOps can generate.

AIOps should not only be viewed as an addition to the existing DevOps practices; instead, it should be seen as the core element of the next generation of operational excellence. AIOps positions companies to gain unparalleled dexterity, originality and prosperity throughout their digital transformation pathway and beyond.
November 4, 2025
Developing Software That Solves Real-World Problems – A Technologist’s View

From automation of financial transactions to telemedicine, contemporary software architecture is critical to solving various challenges in finance, healthcare, automotive, education and many other sectors.

As a technologist, I have seen how well-designed software can determine the success or failure of a project. What makes one technology more effective than the other? It often depends on the answer to this: Are we creating a product that will be useful, or are we creating a product just because we can?

This is where a lot of digital initiatives go wrong: Before writing code, we need to define the problem to be solved. One of the most challenging requirements I have come across is the ‘a system should work for everything’ concept. If I try to design a software system that works for ‘everything’, it surely will become very complicated. If we apply the Pareto Principle, about 20% of the features would be most valuable to 80% of its users. In high-risk sectors such as healthcare and finance, where compliance is a major issue, not only does the software have to work properly, but it also has to be developed properly.

For instance, a hospital’s challenge to enhance the patient’s waiting time and the accuracy of the diagnosis is not only a technical issue but also a human one. Developing software for that environment implies understanding clinical workflows, patient activities and legal regulations. It also means that you are likely to be working with people who are not technical and may not be able to speak the same language as developers do. This is where software architecture converts business requirements into a structured and scalable system.

The Importance of Software Architecture in the Achievement of Real Solutions

Software architecture is not just a technical plan but a way to turn an idea into reality. A good system can model users’ behaviors and usage, expand to meet demand, secure data and combine well with other systems. It takes the concepts of distributed systems, APIs, security layers and front-end interfaces into one cohesive and easy-to-use product. I have been involved with building APIs that are crucial for the integration of multiple products to provide a consistent user experience to consumers of these products. Along with the group of architects, we played a crucial role in breaking down these complex integrations into manageable components and designing easy-to-implement API interfaces. Also, using cloud services, these APIs were designed to be highly resilient.

For instance, in the financial industry, developing a mobile banking application is not only about designing the user interface but also focuses on data protection, preventing fraud, handling a large number of transactions and fulfilling legal requirements across different countries. A good architectural base allows all those layers to be integrated without introducing risk or complexity to the end product. We were migrating some of our applications from on-prem data centers to cloud services. These applications have considerably basic security implemented. While planning for migration, we established clear guidelines to secure the application by implementing advanced authentication, web application firewall, rate limits for APIs and distributed denial of service (DDoS) prevention.

We have observed that microservices, event-driven architecture and cloud-native approaches help maintain and update the systems without disturbing the product. But architecture is not just selecting popular technologies or cloud platforms; it is creating a system that meets the specific business needs of the organization and the specific issues it is trying to address.

Fintech has changed the way customers experience things with the help of software. Other financial apps teach users how to manage their money, while banks prevent fraud with real-time alerts. These innovations are supported by strong data systems that enable organizations to ingest, process and analyze large quantities of data within milliseconds. The architecture is for agility and security simultaneously, something that can only be achieved through proper planning.

Software in healthcare includes the ability to conduct remote consultations and AI diagnosis, among others. However, the issue here is not just the issue of access but also trust. Patients have the right to their information. Doctors need tools that simplify their work, not ones that add unnecessary complexity. Successful platforms focus on interoperability (HL7, FHIR), privacy (HIPAA) and user experience. This is achieved by making architectural decisions that consider privacy, performance and usability as equal factors.

Automobile manufacturers are now shifting toward electric and autonomous vehicles, and this is due to software. From infotainment to diagnostic to predictive maintenance, software is the new wheel. The real-time communication between sensors, cloud platforms and driver interfaces is a complex architecture with high performance and low latency. Many current vehicles are equipped with over-the-air updates, which would be impossible without highly modular and resilient software systems that can efficiently deliver changes without affecting the essential product features.

Balancing Innovation With Responsibility

One of the most important lessons I have learned as a technologist is that just because we can build something does not mean we should. While working on a project related to financing a car, we were able to collect personally identifiable information (PII). Initially, we had it stored for a long duration. However, we were unaware of the implications. When we discussed the situation with the architecture and security teams, we found out that we don’t have ownership of the data and it was very risky to store that data for a long period. We mitigated the risk by reducing the data retention period to what will be useful to users. It is important to consider the ethical implications, security and future maintainability of innovation. The best solutions are not always the most complicated; they are the ones that serve a purpose and do it effectively, robustly and sustainably.

Other issues include what data to collect, how to use AI ethically or how to handle the edge cases in a critical system. Early decisions in a project have lasting effects, which is why mature software development cultures value business input, user feedback and technical excellence equally. For example, while working on applications that collect PII. To ensure privacy and data security, we decided early in the design process that all information must be encrypted at all stages. Additionally, logs were masked to further protect sensitive data. We also put in robust monitoring so that the development team gets alerted in case of any leakage.

The Human Factor in Software Design

At its core, software is a product of human activity. We develop it for people to make their work, decisions and lives better. Code coverage and performance metrics are important, but so is empathy. Technologists need to know what it means to create something that is going to be used in the real world. Whether it is a doctor using a clinical decision support tool or a student trying to access learning materials on a shared device.

Solving real-world issues with software is not only about creating the biggest and the best system, but creating the right one. Combining user understanding, technical expertise and architectural planning is important. In our contemporary world, digital products are almost everywhere, and technologists have a responsibility to design with purpose, clarity and effect.

The future of software includes staying abreast of the problems we aim to solve before writing code. When we get that right, we don’t just build better systems; we build a better world.

May 8, 2025
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 Cloud Developer Environment Adoption Gaining Momentum

A global survey found that while 95% of developers and business leaders are familiar with cloud development environments (CDEs), the reasons for adopting one vary widely. The survey polled 223 developers and business leaders working for organizations with more than 2,000 workers and 250 developers.

Conducted by Coder, a provider of a CDE, the survey, for example, found that while 15% cited optimizing the developer environment setup process as a reason for adopting a CDE, another 14% cited making management tasks such as onboarding or improving remote access easier.

Coder CEO Rob Whiteley said while CDEs clearly improve the productivity of application development teams and improve security by reducing the amount of source code running on notebook and desktop workstations, organizations looking to adopt CDEs need a significant amount of cultural resistance. Application developers have historically set up their own development environments on their own local machines. That approach, however, means that in addition to making it more challenging to collaborate also requires organizations to spend significant time and effort locking down each endpoint being employed by their developers, noted Whiteley.

In fact, those issues are why many platform engineering teams formed to centralize the management of DevOps workflows are implementing CDEs, he added. The ultimate goal is to establish a set of guardrails while still enabling developers to self-service their tooling requirements, noted Whiteley.

In fact, many DevOps teams have already built a homegrown version of a CDE that they currently maintain. Coder and other providers of CDEs are making a case for using a platform supported by a vendor rather than devoting resources to supporting a custom CDE, said Whiteley.

As DevOps workflows continue to evolve in the age of artificial intelligence (AI), it’s only a matter of time before more organizations embrace CDEs, he added. The sheer volume of data that developers will be working with will make it impractical to continue to use local machines to build applications, said Whiteley.

Regardless of the motivation for adopting CDEs, significant cultural changes are coming to DevOps workflows that need to evolve as application development continues to become more distributed. In the post-COVID-19 era, it’s now not uncommon for application development teams to consist of IT professionals working in different time zones. That creates a pressing need to leverage cloud services to provide the level of collaboration those teams need to achieve.

It’s not clear how many CDEs have been deployed, but as the pace at which applications are being built and deployed continues to accelerate, the days when organizations could allow each developer to maintain their own development environment are coming to an end. Organizations need to determine as quickly as possible whether the code being created will actually run in a production environment. The more time spent trying to reconcile differences between development environments and the production environment where the application runs, the longer it will take to complete any given project.

Unfortunately, time is the one thing that most DevOps teams no longer have the luxury of spending on application development initiatives that, in addition to multiplying, are also becoming much more complex to manage with each passing day.

March 26, 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