Frederick, Maryland. – – Spirent Communications plc (LSE: SPT) today announced a collaboration with Amazon Web Services (AWS) to provide automated 5G testing capabilities to communications service providers (CSPs) building 5G networks on AWS. Spirent’s market-first Landslide 5GC automation package is designed to help carriers quickly deploy 5G networks on AWS, significantly reducing operational costs, time, and resources compared to manual testing.

By combining AWS’s continuous integration and continuous delivery (CI / CD) pipeline with Spirent’s vendor-independent 5G testing capabilities, CSP objectively provides mobile network capabilities and services across a wide range of requirements, including compliance. , You will be able to verify quickly and continuously. Capacity and performance dimensions. The integrated solution is aimed at mobile carriers who want to accelerate the delivery of 5G services on AWS.

Doug Roberts, General Manager of Spirent’s Lifecycle Services Assurance Business, said: “The competition for new 5G technology continues, but it is so complex and new that we have established the critical 5G core testing and validation needed for the success of these complex networks and services. There is a real lack of expertise and resources to provide. To the market. ”

With the introduction of 5G network validation on AWS with Spirent’s Landslide 5GC automation package, operators can easily take advantage of fully integrated 5G test automation capabilities to accelerate both 5G network capabilities and service deployment and updates. Can be tested and verified. It provides a continuous delivery framework using AWS CodePipeline and its security and observer best practices and is available in all AWS Regions. This solution is completely isolated, highly extensible, and supports many parallel tests, while enabling some types of network tests that can be automatically triggered as part of the 5G network application pipeline. ..

“Manually establishing such complex test requirements is a very time-consuming process, usually months,” says Roberts. “Thanks to the new collaboration with AWS, service providers can leverage Spirent’s 5G expertise and proven testing techniques to easily integrate automated 5G testing and validation into AWS for months. You can test with confidence, significantly reduce time to market, and analysis shows that you can achieve significant cost savings compared to traditional manual testing methods. It is shown. ”

CSPs can trigger tests and complete validation without the need for additional manual testing or the development of their own test suite. You can reduce the risk of service failures by testing multi-vendor 5G core elements and accelerate test automation without having to build from scratch.

FREDERICK, Md.–(BUSINESS WIRE)–Spirent Communications plc (LSE:SPT) today announced a collaboration with Amazon Web Services (AWS) to bring automated 5G testing capabilities to communications service providers (CSPs) building 5G networks on AWS. Spirent’s market-first Landslide 5GC Automation Package is designed to help carriers to rapidly deploy 5G networks on AWS, significantly reducing operational costs, time, and resources compared to manual testing.

By combining AWS’s Continuous Integration and Continuous Delivery (CI/CD) pipeline with Spirent’s vendor-neutral 5G test capabilities, CSPs will be able to objectively, rapidly, and continuously validate mobile network functions and services across a wide range of requirements, including compliance, capacity, and performance dimensions. The combined solution is aimed at mobile carriers who want to accelerate delivery of 5G services on AWS.

“Service providers around the world are facing a number of distinct challenges as they look to deliver on the promise of 5G,” said Doug Roberts, general manager of Spirent’s Lifecycle Service Assurance business. “The race is on to deploy new 5G technology, but because it is highly complex and new, there is a genuine lack of expertise and resources available to establish and deliver the vital 5G core testing and validation necessary to successfully get these complex networks and services to market.”

With the introduction of 5G Network Validation on AWS, utilizing Spirent’s Landslide 5GC Automation Package, operators can easily leverage the fully integrated 5G test automation capabilities to rapidly test and validate both deployments and updates of 5G network functions and services. It provides a continuous delivery framework using AWS CodePipeline, together with its security and observability best practices, and is available in all AWS Regions. The solution is fully decoupled and highly scalable, supporting many parallel tests, while allowing several types of network tests which can be automatically triggered as part of the 5G Network application pipeline.

“Manually establishing such complex testing requirements is a very time-consuming process, typically running into many months,” says Roberts. “Thanks to our new collaboration with AWS, service providers can leverage Spirent’s 5G expertise and proven test methodologies to easily incorporate automated 5G testing and validation on AWS, reducing months to minutes. They will be able to test with confidence, dramatically accelerate time-to-market, and analysis shows significant cost savings can be achieved compared to traditional manual testing methods.”

CSPs can simply trigger the tests and complete validation with no additional need for manual testing or development of their own testing suites. It can reduce the risk of service failure by testing multi-vendor 5G core elements and accelerate test automation without the need to construct from scratch.

Spirent Communications plc. (LSE: SPT) is the leading global provider of automated test and assurance solutions for networks, cybersecurity, and positioning. The company provides innovative products, services and managed solutions that address the test, assurance, and automation challenges of a new generation of technologies, including 5G, SD-WAN, cloud, autonomous vehicles and beyond. From the lab to the real world, Spirent helps companies deliver on their promise to their customers of a new generation of connected devices and technologies.

BELLEVUE, WA, USA, March 9, 2021 /EINPresswire.com/ — Polyverse, the computer industry’s leading provider of zero trust cybersecurity solutions, today announced that it has partnered with Arganteal to provide secured, automated DevSecOps orchestration for the rapid deployment and configuration of networks, infrastructure and applications in legacy or virtual environments.

Arganteal synthesizes DevSecOps orchestration scripts, and can automate the tedious projects that routinely occupy expensive subject-matter experts. Arganteal works with any API, any platform, and any scripting language.

By harnessing the power of automation and overall system security with Polyverse’s technology, Arganteal and Polyverse are creating a resilient cybersecurity solution for governments and enterprises that mitigates known and unknown memory-based attacks.
Alex Gounares, Polyverse founder and CEO, said “We are excited to partner with Arganteal and its team. At Polyverse, we are committed to solving the cybersecurity crisis, and by partnering with Arganteal we can provide a flexible, automated deployment solution for enterprises with built in protection against zero-day attacks.”
Steve Kelley, Arganteal co-founder and CEO, said, “Polyverse technology is an amazing weapon against cybersecurity threats, and we look forward to working with the company to rapidly deploy its solution to a broad customer base”.

Polyverse
Polyverse develops leading-edge cybersecurity technology to build diversity across multiple system dimensions, stopping attacks before they start. Its technology is used by government and security-conscious organizations to mitigate against zero-day memory exploits. It is also embedded into devices, hardware and security solutions to provide the ultimate protection against hackers. Founded in 2015, Polyverse is led by founder and CEO Alex Gounares and brings together top talent from Microsoft, Amazon and Google, among others. CNBC recently named Polyverse as one of the world’s top 100 startups.

Arganteal
Arganteal Corp is a software and services company that works with large enterprises and government entities such as the US Air Force to streamline security and operations deployment processes. By starting with systems and scripts already being used in the DevSecOps organization, Arganteal melds the disparate pieces into an integrated and efficient deployment flow that can keep pace with the incoming workload from Agile software development and continuous deployment techniques.

We call it DevOps but much of the time there’s a lot more discussion about the needs and concerns of developers than there is about other groups.

There’s a focus on improved and less isolated developer workflows. There are many discussions around collaboration, continuous integration and delivery, issue tracking, source code control, code review, IDEs, and xPaaS – and all the tools that enable those things. Changes in developer practices may come up – such as developers taking ownership of code and pulling pager duty.

We also talk about culture a great deal in the context of developers and DevOps. About touchy-feely topics like empathy, trust, learning, cooperation, and responsibility. It can all be a bit kumbaya.

What about the Ops in DevOps? Or, really, about the other constituencies who should be part of the DevOps process, workflow, and even culture? Indeed, DevSecOps is gaining some traction as a term. DevOps purists may chafe at “DevSecOps” given that security and other important practices are supposed to already be an integral part of routine DevOps workflows. But the reality is that security often gets more lip service than thoughtful and systematic integration.

But what’s really going on here is that we need to get away from thinking about Ops-as-usual (or Security-as-usual) in the DevOps context at all. This is really what Adrian Cockcroft was getting at with the NoOps term; he didn’t coin it but his post about NoOps while he was at Netflix kicked off something of an online kerfuffle. Netflix is something of a special case because they are so all-in on Amazon Web Services, but Adrian was getting at something that’s more broadly applicable. Namely that, in evolved or mature DevOps, a lot of what Ops does is put core services in place and get out of the way.

Ironically, this runs somewhat counter to the initial image of breaking down the wall between Dev and Ops. Yes, DevOps does involve greater transparency, collaboration, and so forth to break down siloed behaviors but there’s perhaps an even stronger element of putting infrastructure, processes, and tools in place so that Devs doesn’t need to interact with Ops as much while being (even more) effective. One of the analogies I like to use is that I don’t want to streamline my interactions with a bank teller. For routine and even not so routine transactions, I just want to use an ATM or even my smartphone.

It’s up to Ops to build and operate the infrastructure supporting those streamlined transactions. Provide core services through a modern container platform. Enable effective automated developer workflows. Mitigate risk and automate security. But largely stay behind the scenes. Of course, you still want to have good communication flows between developers and operations teams; you just want to make those communications unnecessary much of the time.

(At the same time, it’s important for Dev and Ops teams to understand how they can mutually benefit by using appropriate container management and other toolchains. There’s still too much of a tendency by both groups to think of something as an “ops tool” or a “dev tool.” But that’s a topic for another day.)

Modern container platform

A DevOps approach can be applied just about anywhere. But optimizing the process and optimizing cloud-native applications is best done on a modern platform. Take it as read that most IT is going to be brownfield and DevOps may even be a good bridge between existing systems, applications, and development processes and new ones. But here I’m focusing on what’s optimized for new apps and new approaches.

You need scale-out architectures to meet highly elastic service requirements. Application designs with significant scale-up components simply aren’t able to accommodate shifting capacity needs.

Everything is software-defined because software functions, such as network function virtualization and software-defined storage, are much more flexible than when the same functions are embedded in hardware.

The focus is on applications composed of loosely-coupled services because large monolithic applications can be fragile and can’t be updated quickly.

A modern container platform enables lightweight iterative software development and deployment in part because modern applications are often short-lived and require frequent refreshes and replacements.

As I wrote about in The State of Platform-as-a-Service 2016, a PaaS like Red Hat’s OpenShift has evolved to be this modern container platform, embracing and integrating docker-format containers, kubernetes for orchestration and using Red Hat CloudForms (based on the ManageIQ upstream project) for open source hybrid cloud management.

Automated developer workflows

When thinking about the toolchain associated with DevOps, a good place to start is the automation of the continuous integration/continuous delivery (CICD) pipeline. The end goal is to make automation pervasive and consistent using a common language across both classic and cloud-native IT. For example, Ansible allows configurations to be expressed as “playbooks” in a data format that can be read by both humans and machines. This makes them easy to audit with other programs, and easy for nondevelopers to read and understand.

A typical automated workflow begins with operations provisioning a containerized development environment, whether a PaaS or more customized environment. This provides an example of how a mature DevOps process separates operations and developer concerns; by providing developers with a dynamic self-service environment, operations can focus on deploying and running stable, scalable infrastructure while developers focus on writing code.

Automation then ensures that the application can be repeatedly deployed. Many different types of tools are integrated into the DevOps workflow at this point. For example:

• Code repositories, like Git
• Container development tools to convert code in a repository into a portable containerized image that includes any required dependencies
• Vagrant for creating and configuring lightweight, reproducible, and portable development environments¥IDEs like Eclipse
• CICD software like Jenkins

Mature DevOps systems may even push the code directly to production once it has passed automated testing. But this isn’t about removing Ops from its role of ensuring stable and robust production systems. Rather, it’s about automating the processes to ensure that deployed code meets set criteria without ops needing to be directly involved with each deployment.

Mitigate risk and automate security

Ops is also ultimately chartered with protecting the business. This doesn’t mean eliminating all risk – which can’t be done. But it does mean mitigating risk which is accomplished in part by managing the software supply chain and by automating away sources of manual error.

That’s not to say that security is purely an ops concern – hence the aforementioned DevSecOps term. Creating a mindset in which everyone is responsible for security is key as is the practice of building security into development processes. Security must change from a defensive to an offensive posture that is both automated and constant.

Among the practices to be followed in such a proactive environment are:

• Components built from source code using a secure, stable, reproducible build environment
• Careful selection, configuration, and security tracking of packages
• Automated analysis and enforcement of security practices
• Active participation in upstream and community involvement
• Thoroughly validated vulnerability management process

I think this quote from Gartner captures the required dynamic well: “Our goal as information security architects must be to automatically incorporate security controls without manual configuration throughout this cycle in a way that is as transparent as possible to DevOps teams and doesn’t impede DevOps agility, but fulfills our legal and regulatory compliance requirements as well as manages risk.”

What Is HCI and Why Automate It?

Hyper-Converged Infrastructure (HCI) collapses traditional three-tier data-centre architecture — separate compute, storage, and networking layers — into a single, software-defined building block. By pooling commodity x86 servers running VMware vSphere and vSAN, organisations can scale out storage and compute together, reduce cabling complexity, and manage the entire stack through a single pane of glass.

Despite its operational simplicity at runtime, initial deployment of an HCI stack can still be tedious and error-prone when performed manually. Applying DevOps principles — infrastructure-as-code, idempotent configuration management, and continuous validation — to the bring-up process eliminates configuration drift, accelerates time-to-production, and makes the environment fully reproducible.

The VMware SDDC Stack in Focus

The automation approach described in the original VMware blog post targets a full Software-Defined Data Centre (SDDC) stack composed of four main products:

• VMware vSphere (ESXi + vCenter Server) — the compute and hypervisor layer that hosts all workloads.
• VMware vSAN — software-defined storage distributed across vSphere hosts, eliminating the need for external SANs or NAS.
• VMware NSX — software-defined networking and security, providing micro-segmentation, logical switching, routing, and load balancing independent of physical hardware.
• VMware Integrated OpenStack (VIO) — an enterprise-supported OpenStack distribution that sits on top of vSphere and NSX, exposing a standard OpenStack API surface for tenant self-service.

Together these components form an HCI platform capable of running both traditional VM workloads and cloud-native tenant environments, all on the same converged hardware.

Applying DevOps Principles to HCI Bring-Up

A DevOps-style deployment pipeline for this stack typically involves several stages, each automated and version-controlled:

1. Infrastructure-as-Code for Configuration

All cluster parameters — host IP addresses, vSAN disk groups, NSX controller counts, VIO sizing — are captured in declarative configuration files (for example, YAML or JSON). This means every environment, from a lab proof-of-concept to a production cluster, is described in source control and can be peer-reviewed before deployment begins.

2. Scripted Deployment with VMware APIs

VMware exposes rich APIs across its product portfolio — the vSphere API (accessible via PowerCLI or the vSphere SDKs), the NSX REST API, and the VIO management API. Automation tooling can chain calls to these APIs to:

• Configure ESXi hosts, vCenter clusters, and HA/DRS settings.
• Claim vSAN capacity and cache disk groups and verify the vSAN health checks pass.
• Deploy NSX Manager, register it with vCenter, and provision controllers and transport zones.
• Bootstrap VIO, connect it to the vSphere and NSX backends, and validate the OpenStack services come up healthy.

3. Idempotency and Validation Gates

Each automation step should be idempotent — running it a second time should produce the same outcome without creating duplicate objects or failing with errors. After each major phase (vSphere cluster ready, vSAN healthy, NSX control plane up, VIO services active), automated validation tests confirm the expected state before the pipeline advances. Failures at any gate halt the pipeline and surface a clear error, rather than allowing a misconfigured component to propagate into later stages.

4. Version-Controlled and Repeatable

Because the entire bring-up procedure lives in a version-controlled repository, teams can:

• Reproduce the exact same environment in a new data centre or a disaster-recovery site.
• Roll back to a known-good configuration definition if a change introduces problems.
• Audit exactly what changed between deployments using standard diff and pull-request workflows.

Key Benefits for Operations Teams

• Reduced deployment time: Multi-day manual bring-up processes can be compressed into hours when fully scripted.
• Consistency: Every cluster built by the pipeline is configured identically, removing the variability introduced by different engineers following a run-book.
• Self-documenting infrastructure: The configuration files and pipeline code serve as living documentation of the environment’s intended state.
• Faster recovery: If a cluster must be rebuilt, the same pipeline re-creates it to spec without relying on tribal knowledge.
• Compliance-friendly: Change history is captured in Git; automated validation gates can enforce security baselines at deploy time.

Tooling Considerations

Common tooling choices for automating this type of VMware SDDC stack include:

• PowerCLI — VMware’s PowerShell module for vSphere automation, well suited for cluster configuration and vSAN management tasks.
• Ansible — agentless automation that can orchestrate multi-product workflows using VMware and NSX modules from Ansible Galaxy.
• Terraform — the VMware vSphere provider can manage vCenter objects declaratively; NSX-T also has a Terraform provider.
• Python with the vSphere Automation SDK — useful for custom tooling or integrating with existing CI/CD pipelines.
• CI/CD platforms (Jenkins, GitLab CI, etc.) — orchestrate pipeline stages, enforce gate checks, and provide audit trails.

Further Reading

For the full implementation walkthrough, scripts, and architecture diagrams, refer to the original VMware Virtual Blocks blog post:

HCI Automated Deployment & Configuration: vSphere, vSAN, NSX, VIO The DevOps Way — VMware Virtual Blocks Blog