devopsy.kinsta.cloud

Tag: cloud automation

An Experience-Based Guide to Choosing the Right DevOps Provider in 2026
To stay competitive, companies need to deliver software updates and new features rapidly without compromising reliability and security. However, maintaining a specialized in-house team can be costly due to talent shortages, high salaries and fluctuating workloads. Whether through outsourcing, outstaffing or managed service models, partnering with a trusted DevOps provider offers a flexible way to fill talent gaps and scale expertise without the burden of maintaining a large in-house team.

This article outlines a four-phase approach for selecting and evaluating a DevOps partner to ensure alignment with your business objectives.

PHASE 1: The ‘Why’ (Internal Preparation)

Begin your search by evaluating your project needs. Assess the current state of your software systems, delivery processes and areas for improvement. This will help you define clear requirements and avoid misunderstandings as you align your project vision with that of the service provider.

1.1 Define Your Needs and Goals

Identify the challenges you want to solve through DevOps adoption and create a clear, organized list of goals. This list will become the foundation for selecting and evaluating potential partners. Here are a few examples of such goals:
- Increase developer productivity by establishing or optimizing a continuous integration/continuous deployment (CI/CD) pipeline.
- Implement infrastructure as code (IaC) to automate and standardize cloud environment management.
- Reduce deployment and release times while minimizing errors from manual processes.
- Improve system monitoring, alerting and logging to enhance visibility.
- Strengthen infrastructure security and compliance controls.
Define measurable success criteria (for example, reduce deployment time by 40% in six months or achieve 99.9% uptime on production). Providers perform better when expectations are transparent and quantifiable.

1.2 Align Stakeholders Early

Before engaging external DevOps partners, make sure all key stakeholders in domains such as engineering, operations, finance and security agree on priorities and success metrics. Misalignment often causes friction later when the provider’s goals do not fully match business expectations.

Max Petrichenko, team lead at IT Craft DevOps development company, notes:

“A clear understanding of your long-term goals and challenges is the foundation of a successful DevOps implementation. If your team is overloaded or lacks a comprehensive understanding of existing bottlenecks, a third-party system audit can provide valuable insights. It provides an outside perspective on your infrastructure, highlights hidden risks and helps refine your requirements before engaging an external DevOps partner.”

1.3 Assess Your Current Capabilities

Review your available resources and evaluate your in-house development team’s skills and capacities, as they closely collaborate with the outsourced DevOps team. Focus on identifying:
- Gaps in workflows that DevOps can help resolve.
- How much workload do your developers already carry?
- Existing DevOps-related skills and knowledge within the team.
- How satisfied are developers with current processes?
1.4 Determine Project Scope and Duration

Evaluate the scope and expected duration of your collaboration. Depending on your goals, you might need a short-term engagement to handle specific tasks, such as a cloud migration or a long-term strategic partner who acts as an extension of your in-house team, managing infrastructure maintenance and monitoring.

Understanding your project scope, key outcomes and timeline will help you determine how many DevOps engineers you need and what type of engagement model best fits your goals.

PHASE 2: The ‘Who’ (Initial Vetting)

Once your internal preparations are complete, proceed to evaluate potential service providers. Review the available candidates carefully and create a shortlist of those who meet your key requirements.

2.1 Experience and Expertise

A solid track record is the clearest indicator of a service provider’s expertise. Look for a partner that specializes in DevOps within your industry, not a general software development company. Their familiarity with your industry’s unique challenges can be a significant advantage.

Review case studies and client testimonials from similar projects, paying attention to experience with businesses of your size. Additionally, don’t hesitate to ask for references to verify their claims.

Ask how the provider measures DevOps’s success internally. Mature vendors often track metrics such as deployment frequency, change failure rate, lead time to change and mean time to recovery (MTTR)—known as DORA metrics. A team that is fluent in DORA indicates a metrics-driven mindset, not just tool familiarity.

2.2 Technical Proficiency and Tooling

Review the service provider’s technical stack. They should have proven expertise with core DevOps tools such as Docker, Kubernetes, Jenkins, Terraform or Grafana, ensuring they can support automation, orchestration and monitoring across your environment.

However, a reliable service provider shouldn’t be limited to a fixed set of tools. Instead, they should be skilled in a wide range of DevOps technologies and flexible enough to choose the ones that best fit your project’s specific needs and challenges.

Check whether the provider supports multi-cloud and hybrid environments. Various companies face tool sprawl across AWS, Azure and on-prem infrastructure. A capable partner should demonstrate how they unify observability and automation across different platforms. Ask for a real example of how they used automation to reduce operational costs or deployment errors in a similar environment.

2.3 Communication and Cultural Fit

The outsourced DevOps team should function as a seamless extension of your in-house team. Prioritize providers that promote transparency, proactive communication and flexibility in adapting their workflows to align with your existing processes.

A reliable service provider should ensure smooth communication and consistent project updates. They need to integrate with the project management tools used by your internal team and hold regular touchpoints such as daily check-ins and weekly planning meetings to keep everyone aligned.

Beyond English fluency, evaluate time-zone overlap, responsiveness during emergencies and clarity in reporting. A mature vendor provides structured communication rituals such as weekly status summaries, quarterly retrospectives and incident reports, following the DevOps blameless post-mortem model.

PHASE: 3 The ‘How’ (Deeper Evaluation)

After shortlisting and vetting potential providers, proceed to the technical and operational evaluation stage. The goal here is to verify their claims and gain a clear understanding of how they apply DevOps practices in real projects.

3.1 Technical Assessment and Methodology

Take a close look at how the provider applies DevOps in real projects. Ask them to walk you through a typical CI/CD pipeline and explain how they handle quality, security and process automation. Ideally, the provider can walk you through an end-to-end workflow, from estimation to production, explaining each step and the reasoning behind every decision.

Ask whether the provider performs infrastructure security reviews as part of CI/CD implementation. DevSecOps readiness, including vulnerability scanning, compliance checks and secret management, has become mandatory. Moreover, evaluate if they use automated testing frameworks and observability tools to detect performance regressions early.

3.2 Team Structure and Skill Set

Request to review the curriculum vitae (CVs) of the specialists assigned to your project and schedule interviews to discuss their experience, previous roles and upcoming responsibilities. Additionally, assess the provider’s replacement procedures and resource backup plans to ensure business continuity in the event of a key DevOps expert leaving the team.

3.3 Test the Partnership with a Trial Project

Begin with a small paid project to evaluate the DevOps team in a real-world setting. This allows you to observe their technical skills, communication style and overall approach to collaboration. Pay attention to how they respond to feedback and manage revisions, as this will reveal their flexibility and commitment to delivering quality results.

If possible, structure your trial project to simulate a real bottleneck or risk scenario, such as a sudden traffic spike or a failed deployment. Measure how the team collaborates under pressure. A strong DevOps partner demonstrates not only technical skill but also composure and clear communication when issues occur.

PHASE 4: The ‘What’ (Finalizing the Agreement)

After vetting and selecting a particular service provider from your list, focus on preparing a clear and comprehensive contract.

4.1 Pricing Models and Transparency

Whatever model you choose, whether fixed price or a dedicated team, ensure the pricing structure is fully transparent. Ask about potential risks of cost overruns and how they are handled. Confirm that the provider clearly outlines all expenses from the start to avoid unexpected charges later.

Request a detailed cost breakdown for each deliverable or sprint to prevent hidden charges. Clarify ownership of cloud accounts, licenses and infrastructure expenses. Moreover, establish a clear exit strategy—what happens to your infrastructure scripts, credentials and data if the contract concludes.

4.2 Clarify Terms and Protect Your Interests

Clearly document all deliverables in the contract and include key performance metrics in the service level agreement. These may cover uptime, mean time to recovery, lead time for changes and other relevant indicators. Review carefully the section outlining what happens if the provider fails to meet commitments and how accountability is ensured.

Beyond the SLA, include a continuous improvement clause. This ensures the provider regularly proposes process enhancements (for example, improving build time or deployment frequency) rather than just maintaining the status quo.

Review all contract terms with your legal team to ensure your interests are fully protected. The agreement should clearly define intellectual property rights, roles and responsibilities, and include provisions that help prevent misunderstandings or future disputes.

Final Thoughts: Continuous Partnership Evaluation

Even after signing, vendor management doesn’t end. Review your DevOps provider’s performance quarterly using key performance indicators (KPIs) such as:
- Deployment frequency and speed improvements
- Incident response efficiency
- Infrastructure cost optimization results
- Innovation contributions (for example, automation improvements or new tool adoption)
This ongoing evaluation keeps the relationship strategic, not transactional.
October 29, 2025
System Initiative Adds AI Agents to Infrastructure Automation Platform

System Initiative today announced it has added autonomous artificial intelligence (AI) agents to its infrastructure automation platform

Company CEO Adam Jacob said AI agents will now be able to interact with digital twins of IT infrastructure environments that System Initiative creates to enable DevOps teams to propose and safely execute changes to IT infrastructure.

DevOps engineers using natural language prompts can simply tell the System Initiative platform what outcome they want and the AI agent determines how best to accomplish that task. DevOps engineers then review that plan, which, if approved, will be executed by the AI agent, said Jacob.

AI agents will be able to complete tasks in a matter of minutes that previously would have required weeks for DevOps teams to manually perform, he added. AI agents will also be able to propose validated changes to IT infrastructure environments to optimize workflows and eliminate bottlenecks, said Jacob.

Additionally, DevOps teams can import existing infrastructure into the System Initiative platform to create a real‑time digital twin of every element of their IT environment that they can then use AI agents to help them explore and uncover hidden relationships between resources, noted Jacob. The digital twin platform created by System Initiative essentially functions as a knowledge graph that AI agents can use to understand the relationships between resources, he added.

DevOps teams will also be able to define custom guardrails and rules to limit the scope of the functions any AI agent is allowed to perform, noted Jacob. Built‑in policy checks and tests ensure every change adheres to compliance and operational requirements, he said.

In effect, AI agents will be integrated into existing DevOps teams without requiring any changes to existing workflows, added Jacob.

Ultimately, the goal is to make it much simpler for DevOps teams to employ AI agents to consistently employ best infrastructure management practices in a way that, for example, eliminates misconfigurations that might be exploited by cybercriminals, said Jacob.

As more menial infrastructure management tasks are automated, DevOps teams should also have more time to research how to optimize their environments for complex applications, he added.

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. Of course, AI agents might also be prone to making mistakes, but hopefully, 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.

No matter how IT infrastructure is provisioned, there will always be a requirement for it to be reviewed by a DevOps engineer. The challenge and the opportunity now is to automate the management of IT infrastructure at a level of scale that might not have not too long ago seem unimaginable.

August 27, 2025
Infrastructure-as-Code (IaC): The Key to Agile and Automated Cloud Deployments
My early years as a technical support engineer at Divox International provided me with the opportunity to gain hands-on experience with the difficulties encountered in manual infrastructure management. One incident stands out — we spent over 48 hours recreating a production environment for a client. Although having detailed documentation was helpful, the 48-hour crunch involved the added pressure of working with manual processes, which introduced inconsistencies that eventually led to significant failures. This experience provided me with a realization that automation and consistency are paramount for infrastructure management. My years of experience encompass a journey from a TechOps engineer at Mesame Technologies to a DevOps specialist at Woolworths, closely mirroring the industry’s move toward automation and agility. Infrastructure-as-code (IaC) has been at the forefront of this transformation, allowing teams to define, version and deploy infrastructure with the same ease and reliability as application code. Deployments are not just swifter under this new regime — they are also more reliable and scalable, which is vital in today’s helter-skelter digital economy. So, is IaC a panacea for poor cloud deployments? I will share my thoughts on the subject.

Evolution of Infrastructure Management

While I was working as a TechOps Engineer at Mesame Technologies, the provisioning of infrastructures was a tedious manual process that required long runbooks and conferring with multiple console-based configuration commands. These methods were highly prone to human errors, leading to unnecessary outages and serious inefficiencies in the company’s infrastructure.

As a DevOps engineer at RCG Global Services, I observed the ever-increasing intricacy of infrastructure demands. It was becoming untenable to rely on manual infrastructure configuration, with project timelines often hanging in the balance. We had to find a way to provision infrastructure that was not only consistent but also reliable and efficient at a large scale. In this context, undemanding simplicity made IaC a natural choice.

The infrastructure teams can define it declaratively. Hence, these setups have reproducibility, and there is a risk minimization associated with manual setups. Using Terraform and CloudFormation, one can provision environments and scale them within minutes. You can do this with a kind of speed that eliminates configuration drift and minimizes deployment time.

Core Benefits of Infrastructure as Code

As a senior system programmer at FIS, I led a project that overhauled our processes for deploying a complicated payment-processing system. Previously, setting up new environments manually took days, and the result was a series of inconsistently configured systems. Implementing IaC changed all that with:
- Dependability and Consistency: Each environment was defined in code, guaranteeing uniform setups spanning development, testing and production.
- Efficiency and Speed: We reduced the deployment time from days to hours, which, in turn, improved our time to market.
- Cost Optimization: Infrastructure expenses were reduced by 30% due to automated scaling policies and resource provisioning.
- Improved Teamwork: Storing infrastructure specifications in Git boosted teamwork for development, operations and QA. Visibility and governance increased and everyone was on the same page.
Essential IaC Tools and Practices

Throughout my career, I have made extensive use of Terraform and AWS CloudFormation to control my infrastructure.
- Terraform: Its declarative syntax and multi-cloud support made it our tool of choice for efficiently managing our AWS resources, Kubernetes clusters and hybrid cloud environments.
- CloudFormation: At TSYS, we leveraged CloudFormation for workloads centered on AWS, owing to its efficient integration with AWS services and its strength in handling rollback scenarios.
- Kubernetes and GitOps: At Workoi, we extended IaC principles to Kubernetes, using Helm and Argo CD and ensuring version-controlled, automated deployments.
Implementation Strategy

At ITC Infotech, I created a framework to assist organizations in their transition to IaC.
1. Begin Increments: Establish the fundamentals in a non-critical environment where it is safe to take risks and where final practices can be honed to perfection.
2. Team Training: At Woolworths, Terraform and CloudFormation workshops were held to upskill teams before full-scale adoption.
3. Management of State and Secrets: Secure handling of Terraform state files and secrets with AWS S3, Parameter Store and HashiCorp Vault prevented configuration drift and security leaks.
4. Automated Testing: Integrating tfsec, checkov and kube-bench into CI/CD pipelines guaranteed security and compliance.
5. Iterate and Expand: After validation, broaden the application of IaC to include additional services, ensuring the use of standardized, reusable modules throughout.
Best Practices and Patterns

My extensive experience across several organizations has helped me pinpoint vital best practices that guarantee successful IaC adoption:
- Modular Design: At FIS, we succeeded in creating reusable Terraform modules for VPCs, IAM roles and EC2 instances — virtually cutting our IaC redundancy in half and making our IaC maintainable.
- Security by Default: We embedded security policies within our IaC templates, ensuring compliance right from the get-go.
- Collaboration and Documentation: We maintained copious documentation and enforced pull requests for all infrastructure changes, inducing a culture of shared ownership.
- Testing and Validation: We implemented syntax validation, got good at running unit tests and even did some chaos engineering — all to better ensure that our deployments were resilient and fault-tolerant.
Future Trends and Innovations

The field of IaC is developing consistently, eliciting thrilling progress:
- AI/ML Integration: At Woolworths, we looked into machine learning models that would analyze infrastructure usage patterns dynamically to improve our deployments.
- Serverless IaC: With serverless computing emerging, managing AWS Lambda and Google Cloud Functions with IaC tools is becoming crucial.
- Fully Autonomous Infrastructure: The future points to infrastructure that can heal itself, drive itself with policies and optimize itself using real-time system metrics.
Conclusion

My work has given me firsthand experience of how IaC alters cloud infrastructure. The move to using code for automated, reliable cloud deployments is a necessity in modern cloud computing.

But today, building programs that control, provision and manage cloud infrastructures requires more than just coding skills — it demands strategic vision, stakeholder alignment and a well-planned change management process to upskill and motivate the people who will work in the new cloud-native model. And honestly, it takes some chalk smoke, using a few old-time and some new tools to get folks over the finish line and across the moat to the next tier in the cloud — higher agility and resilience. The payoffs are better cost efficiency, rapid scalability and a cloud that works more like a digital garden and less like a smoke signal.
May 8, 2025
How to Solve the GPU Shortage Problem With Automation
GPU instances have never been as precious and sought-after as they have since generative AI captured the industry’s attention. Whether it’s due to broken supply chains or the sudden demand spike, one thing is clear: Getting a GPU-powered virtual machine is harder than ever, even if a team is fishing in the relatively large pond of the top three cloud providers.

One analysis confirmed “a huge supply shortage of NVIDIA GPUs and networking equipment from Broadcom and NVIDIA due to a massive spike in demand.” Even the company behind the rise of generative AI–OpenAI–suffers from a lack of GPUs. And companies have started adopting rather unusual tactics to get their hands on these machines (like repurposing old video gaming chips).

What can teams do when facing a quota issue and the cloud provider runs out of GPU-based instances? And once they somehow score the right instance, how can you make sure no GPUs go to waste?

Automation is the answer. Teams can use it to accomplish two goals: Find the best GPU instances for their needs and maximize their utilization to get more bang for their buck.

Automation Makes Finding GPU Instances Easier

The three major cloud providers offer many types and sizes of GPU-powered instances. And they’re constantly rolling out new ones–an excellent example of that is AWS P5, launched in July 2023.

To give a complete picture, here’s an overview of instance families with GPUs from AWS, Google Cloud and Microsoft Azure:

AWS
- P3
- P4d
- G3
- G4 (this group includes G4dn and G4ad instances)
- G5
Note: AWS offers Inferentia machines optimized for deep learning inference apps and Trainium for deep learning training of 100B+ parameter models.

Google Cloud
- A2
- G2
- N1
Microsoft Azure
- NCv3-series
- NC T4_v3-series
- ND A100 v4-series
- NDm A100 v4-series
When picking instances manually, teams may easily miss out on opportunities to snatch up golden GPUs from the market.

Cloud automation solutions help them find a much larger supply of GPU instances with the right performance and cost parameters.

Considering GPU Spot Instances

Spot instances offer significant discounts–even 90% off on-demand rates–but they come at a price. The potential interruptions make them a risky choice for important jobs. However, running some jobs on GPU spot instances is a good idea as they accelerate the training process, leading to savings.

ML training usually takes a very long time–from hours to even weeks. If interruptions occur, the deep learning job must start over, resulting in significant data loss and higher costs. Automation can prevent that, allowing teams to get attractively-priced GPUs still available on the market to cut training and inference expenses while reducing the risk of interruptions.

In machine learning, checkpointing is an important practice that allows for the saving of model states at different intervals during training. This practice is especially beneficial in lengthy and resource-intensive training procedures, enabling the resumption of training from a checkpoint in case of interruptions rather than starting anew.

Furthermore, checkpointing facilitates the evaluation of models at different stages of training, which can be enlightening for understanding the training dynamics.

Zoom in on Checkpointing

PyTorch, a popular ML framework, provides native functionalities for checkpointing models and optimizers during training. Additionally, higher-level libraries such as PyTorch Lightning abstract away much of the boilerplate code associated with training, evaluation, and checkpointing in PyTorch.

Let’s take a look at an example:



import torch

import torch.nn as nn

import torch.optim as optim

# Assume model is an instance of a PyTorch nn.Module

model = nn.Linear(10, 1)

optimizer = optim.SGD(model.parameters(), lr=0.1)

# Define a path to save the checkpoint

checkpoint_path = ‘checkpoint.pth’

# Saving checkpoint

torch.save({

‘epoch’: epoch,

‘model_state_dict’: model.state_dict(),

‘optimizer_state_dict’: optimizer.state_dict(),

‘loss’: loss,

}, checkpoint_path)

# Loading checkpoint

checkpoint = torch.load(checkpoint_path)

model.load_state_dict(checkpoint[‘model_state_dict’])

optimizer.load_state_dict(checkpoint[‘optimizer_state_dict’])

epoch = checkpoint[‘epoch’]

loss = checkpoint[‘loss’]

# Resume training

model.train() # or model.eval() if you are not resuming training



In the snippet above, torch.save is called to save a dictionary containing the model and optimizer states and other relevant information like the epoch number and loss value to a file. To restore the training state, torch.load is used to load the checkpoint, and the load_state_dict methods are used to restore the model and optimizer states.

From a Kubernetes perspective, saving to a local file is not ideal. However, you can use a PersistentVolumeClaim to attach a non-ephemeral file system to your training job and go even further by using cloud-provided object storage.

If you modify it to save our checkpoints to an AWS S3 bucket, here is what the code looks like:

import boto3

import torch

import torch.nn as nn

import torch.optim as optim

import io

# Assume model is an instance of a PyTorch nn.Module

model = nn.Linear(10, 1)

optimizer = optim.SGD(model.parameters(), lr=0.1)

# AWS S3 Configuration

s3 = boto3.client(‘s3’)

bucket_name = ‘your-bucket-name’

checkpoint_key = ‘checkpoints/checkpoint.pth’

# Saving checkpoint

checkpoint_buffer = io.BytesIO()

torch.save({

‘epoch’: epoch,

‘model_state_dict’: model.state_dict(),

‘optimizer_state_dict’: optimizer.state_dict(),

‘loss’: loss,

}, checkpoint_buffer)

s3.put_object(Bucket=bucket_name, Key=checkpoint_key, Body=checkpoint_buffer.getvalue())

# Loading checkpoint

checkpoint_obj = s3.get_object(Bucket=bucket_name, Key=checkpoint_key)

checkpoint_buffer = io.BytesIO(checkpoint_obj[‘Body’].read())

checkpoint = torch.load(checkpoint_buffer)

model.load_state_dict(checkpoint[‘model_state_dict’])

optimizer.load_state_dict(checkpoint[‘optimizer_state_dict’])

epoch = checkpoint[‘epoch’]

loss = checkpoint[‘loss’]



The code snippet is not fully complete, as it misses Boto authentication. However, it does provide a good illustration of using the put_object call to save the model checkpoint rather than saving it to a local file.

You can also explore higher-level approaches, such as using PyTorch Lightning, a library designed to simplify much of the boilerplate code associated with training PyTorch models.

How to Find GPUs and Boost Their Utilization: Case Study

One of our customers was working on an AI-powered intelligence solution for detecting social and news media dangers in real-time. The engine analyzes millions of texts simultaneously to detect developing storylines and lets users create Natural Language Processing (NLP) models for defense.

Since the platform uses massive volumes of both classified and public data, its workloads frequently require GPU-enabled instances.

Teams working in the public cloud often create node pools (Auto Scaling groups) to be more efficient. While node pools accelerate the process of provisioning new instances, they can also be expensive, as you may end up paying for capacity that isn’t eventually utilized.

Thanks to automation features such as the autoscaler and Node Templates, the team could leverage more cost-efficient machine types, such as spot instances. Using a simple graphic UI, Node Templates allow users to set specific instance preferences instead of picking them manually. You set the scope, and the autoscaler does the rest, choosing from a wider pool of instances.

Moreover, Node Templates automatically enroll applications on newly-introduced instances, such as AWS P5. This is another task that automation removes from the engineer’s to-do list.

Our customer described their requirements, such as instance types, the lifespan of the new nodes to be added, and provisioning configurations, when setting up a Node Template. The team defined limits such as families it didn’t want to use (P4d, P3d and P2) and the preferred GPU manufacturer (in this case, NVIDIA).

The automation platform discovered five machines matching these specific parameters. When adding additional ones, the autoscaler now adheres to these limitations.

When the GPU task is completed, the autoscaler immediately decommissions instances to help minimize the costs of the entire operation.

Wrap Up

Automation is indispensable in a modern team’s toolkit, especially if they work with cloud-native technologies like Kubernetes and are looking for the most optimal cost-performance ratio for their GPU resources.

GPUs often generate high costs, so using automation to find the best options and maximize their utilization brings a two-fold benefit: It makes engineers’ lives easier and finance teams happier. Spot instance automation helps to reduce the cost of model training, and together with checkpointing, it allows to avoid expenses and trouble in case of interruptions.

To hear more about cloud-native topics, join the Cloud Native Computing Foundation and the cloud-native community at KubeCon+CloudNativeCon North America 2023 – November 6-9, 2023.
October 30, 2023
Broadcom Survey Surfaces Drive to Consolidate Automation Platforms

Broadcom this week published a global survey of 535 IT leaders that found more than three-quarters (78%) are moving to consolidate cloud automation tools and platforms. However, thus far, only 8% of respondents said they had completed that effort.

Overall, the survey also found more than 81% already have multiple cloud automation solutions in place, and 70% noted this issue had created significant challenges, including increasing time to automate (59%), time to report (52%) and time to remediation (52%) and higher costs (49%). In addition, 46% noted it’s more difficult to troubleshoot IT environments, while 41% noted multiple tools increase compliance risks.

IT teams also find that having multiple automation tools slows down software delivery (37%) and contributes to the over-provisioning of IT environments (32%).

Aline Gerew, head of automation for the Agile Operations Division at Broadcom, said the multiple islands of automation that have evolved on various cloud computing platforms now need to be centralized to reduce the current level of friction in the cloud. Those efforts need to start with platforms capable of unifying observability across all the platforms employed, she added.

The amount of consolidation that any IT organization can implement depends on the amount of political capital they have. In many cases, the applications and associated automation tools running in any given environment have been adopted by a department or business unit that exercises a lot of autonomy regarding IT. The issue that creates is multiple tools and platforms increase the total cost of IT. At a time when many organizations are experiencing economic headwinds, the need to reduce the total cost of IT naturally becomes a more pressing concern.

Rather than consolidate automation tools and platforms, the simpler option is to deploy an automation framework that is designed to be integrated with the various tools and platforms that are already in place, noted Gerew. That approach enables automation to be applied at much higher levels of scale to reduce costs without forcing every arm of an organization to standardize on the same tools and platform, she noted.

The survey found that, when it comes to cloud automation, the most important consideration factors are operational costs (62%), performance (53%) and operational efficiency (49%).

Responsibility for cloud automation will naturally vary from one organization to the next, but the survey noted that 67% of respondents currently have a cloud architect on staff and another 33% are planning to hire one.

That role is increasingly required as organizations find themselves managing a wide range of cloud computing environments, including software-as-a-service applications (57%), legacy applications that have been lifted into the cloud (56%), new cloud-native applications (46%) and legacy applications that have been refactored for the cloud (41%).

It’s apparent that cloud computing environments are becoming more complex with each passing day. There may come a day when artificial intelligence (AI) helps reduce the level of complexity; in the meantime, IT organizations need to find ways to streamline the management of cloud computing environments. Today, those environments are made up of applications based on a wide range of increasingly divergent architectures as the rate of application deployments exceeds the retirement of legacy apps.

September 1, 2023
Cloud Orchestration and its Impact on DevOps Teams
Cloud orchestration refers to the coordination and management of various interconnected cloud services and resources to automate and streamline complex IT processes. In simple terms, it is the process of integrating, synchronizing, and automating various cloud-based components to create a seamless and unified workflow.

Cloud orchestration aims to optimize the deployment, management, and use of resources in a cloud environment, improving efficiency, reducing costs, and ensuring that cloud services are delivered in a timely and effective manner. It is related to the concept of CloudOps (cloud operations), which uses cloud orchestration concepts to allow more efficient management of cloud resources. Cloud orchestration is a critical aspect of modern IT infrastructure management, as it enables organizations to manage and control their cloud resources more effectively.

Difference between Cloud Orchestration and Cloud Automation

Though the terms cloud orchestration and cloud automation are often used interchangeably, they have distinct differences.

Cloud automation refers to the process of automating individual tasks and processes within the cloud environment. It involves the use of scripts, templates and other tools to automate repetitive tasks, such as provisioning resources, deploying applications and configuring environments. The primary goal of cloud automation is to reduce the time and effort needed to manage cloud resources.

Cloud orchestration is a broader concept that encompasses not only the automation of tasks but also the coordination and management of the entire cloud ecosystem. It involves the integration of various cloud services, tools and resources to create a unified, streamlined workflow. Cloud orchestration ensures that all components in the cloud environment work together seamlessly, automating complex processes and managing dependencies between tasks.

In essence, cloud automation is a subset of cloud orchestration. While cloud automation focuses on automating individual tasks, cloud orchestration takes a more holistic approach, orchestrating multiple tasks and resources to achieve a higher level of automation and efficiency.

How Cloud Orchestration Enhances DevOps Practices

Increased Efficiency and Speed

One of the main benefits of cloud orchestration in a DevOps context is the ability to increase efficiency and speed in the software development and deployment process. By automating and streamlining various tasks, cloud orchestration eliminates manual processes, reduces the potential for human error and accelerates the overall development cycle.

Improved Collaboration and Communication

Cloud orchestration fosters better collaboration and communication between development and operations teams by providing a unified platform for managing cloud resources. This shared platform enables teams to work together more effectively, breaking down traditional silos and ensuring that all stakeholders have visibility into the development and deployment process.

Enhanced Infrastructure and Application Management

Cloud orchestration simplifies the management of complex cloud infrastructure by providing a single, unified platform for cloud optimization—improving the management of resources, applications and services in the cloud.

This centralized management approach enables organizations to more easily monitor, control and optimize their cloud environment, ensuring that resources are used effectively and that applications are running smoothly. With cloud orchestration, organizations can more easily scale their infrastructure to meet changing demands, ensuring that they have the resources they need when they need them.

Improved Monitoring and Troubleshooting

Cloud orchestration provides improved monitoring and troubleshooting capabilities, enabling organizations to more effectively identify and address issues in their cloud environment. With comprehensive monitoring tools and dashboards, teams can gain insight into the performance of their applications, identify bottlenecks and pinpoint potential issues before they become critical.

Challenges of Integrating Cloud Orchestration With DevOps

Despite the numerous benefits of cloud orchestration, integrating it into DevOps practices can present several challenges. Some of the common challenges include:
- Complexity: Cloud orchestration involves the integration of various cloud services, tools and resources, which can be complex and time-consuming. Organizations may struggle with complexity, particularly if they lack the necessary expertise or resources to effectively implement and manage the solution.
- Resistance to change: Implementing cloud orchestration requires a change in mindset and approach to software development and deployment. As your organization migrates more systems to the cloud, some team members may be resistant to adopting new processes and tools, making it difficult to fully embrace and realize the benefits of cloud orchestration.
- Security concerns: As with any cloud-based solution, security is a critical concern when integrating cloud orchestration into DevOps practices. Organizations must ensure that their solution is secure and that they have the necessary policies and procedures in place to protect their sensitive data and resources.
- Cost and resource constraints: Implementing and managing a Cloud Orchestration solution can be resource-intensive, requiring significant investment in infrastructure, tools, and personnel. Organizations must carefully consider the costs and resources required to implement cloud orchestration and determine whether the benefits outweigh the investment.
Best Practices to Integrate Cloud Orchestration Into DevOps

To successfully integrate cloud orchestration into DevOps practices and overcome the challenges mentioned above, organizations should consider the following best practices:
- Assess your organization’s readiness: Before implementation, evaluate your organization’s readiness for change. This includes assessing your existing infrastructure, processes and tools, as well as your team’s willingness and ability to adopt new practices and technologies.
- Develop a clear strategy: Develop a clear strategy for integrating cloud orchestration into your DevOps practices. This should include defining your goals and objectives, identifying the tools and resources you will need and establishing a timeline for implementation.
- Choose the right tools and technologies: Select the appropriate tools and technologies that best meet your organization’s needs and requirements. Consider factors such as ease of integration, scalability, security and cost when evaluating potential solutions.
- Train and educate your team: Ensure that your team has the necessary knowledge and skills to effectively implement and manage cloud orchestration. This may involve providing training and education on new tools, processes and best practices, as well as fostering a culture of continuous learning and improvement.
- Monitor and measure success: Continuously monitor and measure the success of your implementation. This includes tracking key performance indicators (KPIs), such as deployment speed, resource utilization and application performance, to ensure that your solution is delivering the desired results.
Conclusion

Cloud orchestration is an essential tool for organizations looking to streamline and optimize their IT infrastructure, particularly in the context of DevOps practices. By automating and coordinating complex cloud processes, organizations can improve efficiency, speed, collaboration and overall performance.

However, successfully integrating with DevOps can be challenging, requiring a clear strategy, the right tools and technologies and a commitment to continuous improvement. By following the best practices outlined in this guide, organizations can overcome these challenges and fully realize the benefits.
July 6, 2023
VMware Adds Cloud Automation for DevOps

Those who follow my blog will recall that I covered (and did some work for) CloudCoreo, a cloud security and compliance start-up. What the company was working on was intriguing to me because it pulled many things into the realm of DevOps through automation at a time when cloud security was a big issue.

It’s still a big issue, and the former CloudCoreo product has been enhanced and integrated into VMware’s growing DevOps infrastructure as VMware Secure State. I hopped on a call with Jason Needham, senior director of product management, multicloud security at VMware, to get an idea of what was new and how the product was integrated with VMware’s other offerings.

We’ll get the thing that will interest every risk manager out of the way first. Secure State can tell you about buckets and their current security settings. It can tell you how to fix them. Considering the number of high-profile leaks caused by insecure buckets, I figured I’d mention that even before I talked about how Secure State fits with other VMware offerings. You’re welcome.

Figure 1: Of the many violation chains available in the product, “authenticated user” buckets are one of the coolest, IMO.

Secure State is part of VMware’s Cloud offering (grouped with CloudHealth and WaveFront), bringing security and compliance to multicloud. The cool bit is the level of automation, which allows teams to include cloud infrastructure security and compliance with DevOps efforts. That is where the world is headed, and VMware Cloud sees a greater level of DevOps automation than most alternatives just because it was conceived with APIs aimed at automation in the first place. Adding checks for rights and security settings, even compliance, into the DevOps cycle is breaking down one last wall (now we’re basically waiting for someone to do something astounding for cloud storage).

Part of Secure State is near real-time reporting on status/state. This is big in environments that have real-time reporting for everything else, adding in the one missing piece. It is far better to be told, “There is a problem right now with instance X,” than to be fighting attackers. One of the examples Needham offered was of a project that was used via a small subset of tools: One day a report came in that it was being accessed via JVM instead of the normal methods. In this case, it turned out to be a new developer trying to get work done, but you can imagine such a warning being a heads up that you had an attack going on.

The other interesting bit is risk scoring, officially known as Smart Risk Scoring. The ability to get a prioritized risk list allows DevOps teams to focus on what is most important. When there is so much for security to get done, this is a huge benefit.

Disclaimer: I haven’t used this version of the product. That means I can’t say “This rocks!” but if Secure State delivers, it certainly will.

Anything that adds automation and visibility is a welcome addition to the DevOps stack, making life easier and helping you to rock it.

— Don Macvittie

June 26, 2019
The Cloud and DevOps: Like Peanut Butter and Jelly

Cloud is practically designed for DevOps. No matter which cloud provider you are using, each has set up systems designed to spin up/spin down on demand, has the ability to run pretty much what you need and offer APIs/command lines to achieve your DevOps goals on the infrastructure side.

That means that the infrastructure side of DevOps can be handled by careful choice of base image, some scripts to configure network and other supporting infrastructure, and some scripts to install what’s needed once the instance is running and protected.

Not All Roses …

The problem is one of breadth and complexity. Yes, cloud is the perfect place to spin up DevOps, at least on the infrastructure side and, once you have a Jenkins instance, on the coding side, too. But the complexity masked by “spin up the infrastructure side” can be daunting. Different sets of APIs for servers, storage and networking, and sometimes different APIs for security versus accounts … It can get snarled quickly.

So, What to Do?

What can you do to make life in cloud automation/DevOps easier? There are numerous options available to you to simplify the operational part of cloud DevOps and allow you to focus on discussing issues and resolving them.

First on the list is the growing amount of automation of cloud automation. Sound crazy? It’s not—just my way of expressing that cloud vendors provide you with APIs and tools such as Puppet are getting better at wrapping those APIs for you, so you can focus on problems, not what is supposed to be the solution.

This idea is extended by companies that are tying disparate APIs together into a unified whole in one segment or another. One example of this is CloudCoreo, whose tools can do security audits of cloud deployments. The company takes the time to wrap the various security-related APIs and let you pick what is important for your team to monitor.

There also is an entire market segment growing up of both consultants and VARs that will help an enterprise move to the cloud. Most of these companies focus on one vendor or another, but all share a desire to help make the shift to the cloud easier. By way of examples to get you started, consider Neoxia (in the EU) for GCE, Accenture (in North America) for AWS or Atmosera (in North America) for Azure. (Note: I have never used the cloud services of any of these companies; I’m merely offering you a sampling of what is available. Check your cloud providers’ partners page for more partners.)

Another option that will reduce, but not eliminate, cloud-based complexity is to use containers to set up the application. The container can then be run on whatever cloud platform suits your needs (or in your data center, if that’s the preference). Any instances spun up still must be protected and given access, but most of the networking, security and instance complexity can be handled at the container management level.

In fact, if you implement container management and choose for interoperability, a container management tool such as DC/OS can let you choose at deployment time where to put the container.

Seeing what enterprises are starting to do with containers and entire build/test environments, it is possible that very soon you will be able to just kick off a job, have it build containers that will run your DevOps processes, run tests, deploy to other containers and then go away once the relevant data from them has been saved. The containers used along the way, by taking advantage of a multitarget container management platform, could be anywhere.

To Sum It Up: Cloud is Good for DevOps

The issue at hand—as it has been for DevOps and cloud for a while—is the rate of change. Here we’ve discussed a cross-section of ways to make DevOps in the cloud easier and more complete. But no doubt we’ve missed some great ideas and products, because there is so much going on.

The point is, tools are coming available to make it easier. Don’t write a billion miles of scripts that are useful for only one provider if you can avoid it. Look into these options (and others that will crop up) to lighten your load of technical debt moving forward, and make getting DevOps roaring in the cloud easier.

And as always, keep rocking it. The change has been constant, and you’re still cranking. That says a ton.

— Don Macvittie

November 14, 2017
AWS re:Invent – New Releases Drive Cloud Security Innovation

The recent AWS re:Invent conference in Las Vegas saw the release of several new AWS services for security. Some of these announcements such as AWS Web Application Firewall and AWS Inspector seemed to take many in the security press and blogosphere by surprise.

Cloud-native security companies like Evident.io however, weren’t surprised by these announcements. In fact, AWS has been actively partnering with their security ecosystem to create opportunities for partners to innovate on top of these new base services.

Both incumbent and emerging partners need to remember that a platform is not a product, it is a constantly growing and evolving entity that will continue to adapt as the cloud ecosystem continues to change.

If you want eternal stability, consider investing in a pet rock. If you want to be part of continuously improved technology ecosystems, then strap in because AWS is the rocket ship of platforms in this space.

AWS, no matter what they innovate, will encroach on similar value positions of its ecosystem as a matter of existence. However, this is the best situation possible for customers of the platform.

Customers win out because they receive constant technology innovation and improvement as part of their platform experience, which is something that was never present in the datacenter ecosystem.

Let me paint some color to what these services mean for the ecosystem:

AWS Web Application Firewall (WAF)

AWS WAF enables customers to create filtering rules that whitelist or blacklist application calls coming inbound from the internet towards a customer’s deployed CloudFront CDN resources.

For example, a customer could write a WAF Rule that filters requests to their web application based on source IP address matching or pattern-matches against the request string.

If I was running an e-commerce store that only sold products to the US, I would ensure that my WAF rules contained blocking request patterns for IP Address ranges from China, Syria, Sudan, North Korea, and other embargoed countries (and huge sources of malicious traffic).

While this appears to be a direct attack on some cloud security providers, it really creates a new market path and opportunity for them to deliver their WAF intelligence to the customer.

Let’s be honest — there’s nothing differentiating about building a big x86 appliance and having it run the rules intelligence for your infrastructure.

AWS has removed that barrier of virtualizing the appliance and created a direct path for these companies to deploy their core value proposition — curated and powerful rulesets that protect customers from historical, existing, and future attacks.

Expect to see branded rulesets available through some kind of marketplace or other delivery mechanism here, as that is what customers need.

AWS Inspector

Inspector, in our eyes, was the most important announcement in recent AWS history. We’ve finally seen the true convergence of cloud-based security begin to emerge: Continuous API-centric security intelligence accessibility that is pervasively built into the platform’s diverse feature-set.

With the advent of Inspector, security providers can directly interface to the hosts and applications to provide deep, thorough security visibility for customers without deploying additional third-party agents.

Let’s face it, customers were already overburdened with agents before they ever got to their security stack, and the value delivered by security agents has been questionable at best in cloud environments.

Expect security platforms to integrate singular-views of workload-wide security intelligence in order to provide customers a complete picture of their security posture, risk profile, and attack surface.

Config Rules

Config Rules was, perhaps, the least exciting of AWS announcements in the security space. Unfortunately for Config-based service interactions, the limitations of the service are still apparent a year after initial launch.

Config Rules offers no exception, where interesting capabilities for customers to define custom rules that help them understand what changes impact security in their environment are hampered by limited service support, a cost model that is too unpredictable for small customers and of minimal security value beyond the “ping” that happens when rules fire.

These challenges are compounded by the barrier to entry of writing well-structured and contemplated security rules by a broad audience of non-security experts, which delivers an almost false sense of protection.

Contrasted with CloudTrail, which gives valuable audit information that makes sense at an operational level, Config Rules anticipates the customer will have strong security experience and operational knowledge to leverage the service.

But some customers in every user base are satisfied with what we call “good enough” security in the industry, which defines a scope of offerings that barely make the cut to be called security technology.

The platforms and vendors slinging “good enough” security tend to be at the international buffet, where you get a below-average pizza, a mediocre taco salad, and a poor hamburger.

Nothing you get leaves you with a feeling of being satisfied, because not enough effort was put into the final product to actually change the way you think about the experience.

But mature, focused products will always deliver a superior customer experience, and in security that should never be considered optional.

A vendor who divides their attention between cost management, security, optimization, etc. will never provide the same quality or attention to protecting your infrastructure as a focused innovator in the space can offer.

Users can expect a waiting period for service support for new AWS services, meaning that your security controls are dependent on Config’s roadmap.

But security savvy customers, are not keen on waiting for security to grow up around them – they need it now, they need it on 100% of their cloud infrastructure, and they need it to be actionable.

This is why many will continue to choose the leaders in each security layer over the basic security features tied into the platform itself.

Expect Config Rules to grow over time – but if Config is any indicator, it will be a long time before Config Rules provides real value for customers on the platform.

The real value here is that innovators in the security space will continue to fill the gaps left by services in the platform and innovate customer value atop the technology that does make the cut.

Wrap-Up

Well, that was a journey – and we only covered three services! AWS re:Invent 2015 was a whirlwind of sessions, 19k participants, and awesome discussions on every topic under the sun.

It’s hard to believe we have to wait another year to see this massive gathering happen again, but that leaves a lot of time for innovation, new customer success stories, and to sort through the giant piles of swag that everyone picked up in that madhouse of an expo hall.

Author: Tim Prendergast co-founded Evident.io to help others avoid the pain he endured when helping Adobe adopt the cloud at a massive level. After years of building, operating, and securing services in AWS, he set out to make security approachable and repeatable for companies of all sizes. Tim led technology teams at Adobe, Ingenuity, Ticketmaster, and McAfee.

October 16, 2015
Q&A with Mark Carrizosa of Soha Systems on secure transition to DevOps and cloud computing

We recently spoke with Mark Carrizosa, vice president of security at secure application delivery service provider Soha Systems about the trends he sees with enterprises moving to cloud services. Prior to recently joining Soha Systems, Carrizosa held the position of principal security architect at Walmart where he developed and implemented the company’s global e-commerce security architecture framework. Prior to Walmart, Carrizosa held security positions at companies including Wells Fargo, where he analyzed the company’s infrastructure and application compliance to improve the security of both customer-facing and internal systems. Before that, Carrizosa held positions at Freeport-McMoran and PetSmart. This interview has been edited for brevity.

devopsy.kinsta.cloud: With the rapid move to DevOps and cloud, are there opportunities to improve automation and for enterprises to do more with less? Or is DevOps moving so fast that there are additional challenges being created that outweigh some of the benefits?

Carrizosa: In my opinion, and in my experience, particularly over the last few years in dealing with predominately DevOps shops, the challenges that we faced were not necessarily “can we automate something,” rather it’s “should we automate something.” There are absolutely some things that should not be left entirely out of the automation stream, but should have controls setup as a requirement at a staging gate. For example, you can automate the dynamic scanning your application for vulnerabilities, but what you also need is somebody to actually look at those applications and manually verify and make sense of the reports. These are key components in deploying and delivering secure applications.

There are also ways to expedite processes by integrating certain security frameworks into your workflow, providing the right training, and also creating a shift in your culture. And DevOps, for the most part, is a good thing. It allows organizations to rapidly come to market.

It’s also common in DevOps to have contentions between security and IT. The security group says “No, you can’t do this, it’s going to hurt us.” While the engineers say “We need this to push this out.” How well organizations manage these relationships is a mixed bag. But there is a formula for doing it successfully, and it is all about ingraining security into the culture, into the operations, so that you come out with a secure product and not have to remediate it once it’s done.

devopsy.kinsta.cloud: When you’re constantly iterating and changing your infrastructure and deploying new apps and updates, how does that affect aspects of security that can’t be automated, such as threat modeling applications before they are built or changes are put in?

Carrizosa: Threat modeling, while a new term, it’s not a new concept. If you think about risk management, typically audits are done at a point in time. But very good information assurance programs not only audit a point in time, but they implement a continuous model of checks and balances. So should threat modeling.

Threat modeling needs to happen at inception to ensure that the concept is sound and the methodology is acceptable from a security perspective. But there should also be some levels of checks and balances to ensure that the baseline, or security posture, is maintained throughout the entire change management cycle from inception all the way to delivery.

These are some of the things that can be embedded within DevOps and Agile. Microsoft has a very good, secure lifecycle management methodology that incorporates various elements of security checks throughout the entire development lifecycle. It’s something like this that needs to be included within these operations to ensure that every step you take has some level of checks and balances, whether it be automated or manual, to ensure that the process of an application or an environment is up to what organizations are requiring.

devopsy.kinsta.cloud: There’s still considerable interest out there when it comes to how companies are meeting the challenges of moving to cloud services. Are there common threads you see out there when it comes to the challenges enterprises face when moving to cloud services?

Carrizosa: Yes, absolutely, and one of the key factors is that organizations are looking for ways to securely move to the cloud, or move to a more shared compute environment while still maintaining the control and the reduction of risk that they are used to internally. I spent the majority of my career dealing with these topics from an enterprise level. Most recently at Walmart E-commerce, but I’ve also done the same for PetSmart, Wells Fargo, and some leading industrial companies throughout the industry.

Some of the challenges that I faced have to do with public exposure. You have to deal with migrating from on-premises to cloud, and dealing with BYOD enterprise users. There are a number of potentially sensitive customer-facing applications or data sets that organizations are a little hesitant to move to, particularly at large organizations.

Those large organizations are used to doing things a certain way. Time and time again I’ve heard the phrase, “but we’ve always done it this way.” That in essence could be some of the downfall, or some of the hesitance with these organizations in moving to the cloud, because they are not absolutely sure that they will maintain the control and the effectiveness for environments that they can’t manage.

That’s what Soha is about. Soha allows these organizations to make that next step, to be able to take advantage of these cloud benefits, or even take advantage of some of the cost overhead and the security controls that they’re typically having to address at a high rate of cost and a great deal of effort.

devopsy.kinsta.cloud: Broadly, considering a lot of the credit card and other significant breaches that have occurred in the past decade, do you think the sense of control enterprises have about how well their security and governance efforts are doing is illusionary?

Carrizosa: Well, there’s that old adage of, “it’s never ‘if,’ it’s always ‘when.’ These recent breaches, for instance, are not necessarily based on the types of controls that organizations have, but a lot of times legacy controls or legacy approaches have always seemed to be good enough. And until there is some sort of catalyst to effect change, organizations aren’t necessarily going to stick their necks out. You have CIOs saying, “We do this, we do this, and we do this,” because that’s what they’ve always known. It’s time to now shift to a more open model. With that comes many risks, but in order to do so, there needs to be a fundamental change in the methodology of how organizations are tackling security.

August 11, 2015