Sticky Blogs

Avoiding Hardware Vendor Lock-in with “Software First” Intent-Based Networking

So how to avoid hardware vendor lock-in? Enter Intent-Based Networking. Apstra pioneered Intent-Based Networking to free IT from vendor lock-in. How? It does this by using this three pronged approach:

1. Abstracting Away Hardware (and Offering Hardware Vendor Choice) Through Intent

Intent-Based Networking starts at the system level. These requirements are defined by the end user and incorporate all the capabilities that the customer needs from their infrastructure.  These capabilities include underlay connectivity, overlay, security, compliance, policy, performance, traffic engineering, application performance, SLAs, etc. Requirement and services definition is done at the system level without any dependency or selection of a specific hardware platform or device operating system. Once the user’s intent is specified, the user has the flexibility to choose specific hardware devices and operating systems.  It is only at this point that these requirements are translated into specific vendor decisions, configurations, and telemetry gathering. This translation is done by Intent-Based Data Center Automation powered by Intent-Based-Networking technology. The Apstra Operating System (AOS) is such a solution — AOS knows how to control the device through configuration commands and how to extract telemetry from the device.

If a hardware vendor neglects to or inadvertently fails to maintain consistency with any of their prior APIs, Intent-Based Data Center Automation simply modifies the interface to that API to take advantage of the latest APIs. In doing so it takes on the role of the expert on the differences between vendors (even between the same vendor’s own products) ensuring that customers make best use of each vendor’s equipment and features, while avoiding any pitfalls.

This enables Intent-Based Data Center Automation to provide the widest range of hardware and software vendor choices that has ever existed in the industry. For instance, Apstra AOS supports established vendors (Cisco, Arista, Juniper), as well as open alternatives (Cumulus, OpenSwitch, SONiC).

This unique approach allows Apstra to support, develop, update, configure, and test hardware platforms and device operating systems faster than end users would need to deploy new versions of these platforms. This applies to the latest version of a device OS and new vendor platforms that an end user is deploying in their infrastructure.

Whether a business is building a new data center, refreshing an existing data center, or upgrading a few devices in the data center, the IT team is able to accelerate qualification of the hardware platforms and operating systems by leveraging the testing, qualifications, and support that Apstra has already done. IT benefits from Apstra’s testing of devices and Switch OS’s in their infrastructure and with their configuration before they consider going ahead and deploying it.  Apstra AOS also translates user requirements and services across multi-vendor implementations which ensures interoperability between different vendors.

2. One throat to choke without Lock-in

When a customer automates their infrastructure using Intent-Based Data Center Automation, the vendor providing the solution stands behind the entire system and services delivered by the infrastructure, including the hardware devices that make up this infrastructure. In Apstra’s case, we act as the “one throat to choke” without forcing hardware vendor lock-in. Customers get the benefit of choice without the risk of going it alone. This commitment includes the following:

1. If issues are observed in the infrastructure, the customer calls Apstra.  No questions asked. Apstra is on the side of the customer.
2. If Apstra determines that the issue is caused by the hardware vendor or device operating system, Apstra determines if there is a way to mitigate the issue using Apstra Intent-Based Data Center Automation.  There are many situations such as memory leaks in processes on the devices which can be mitigated using technologies like Apstra Intent-Based Analytics coupled with Apstra self-healing capabilities.
3. If Apstra determines that the issues are beyond the scope of what Apstra can mitigate, then Apstra commits to help the customer swap the hardware platform or operating system for one that Apstra knows works.
4. If the customer is not interested or able to swap out the hardware platform, then Apstra recommends involving the hardware vendor and will  join in on initial and ongoing calls at the request of the customer. Aprtra will leverage its infrastructure and partners to help debug the issue and get it to the fastest resolution.

Five millions tests a day

How is Apstra able to provide this level of support? One reason is that we operate the most powerful automated testbed in the industry. Apstra runs tens of thousands of continuous tests per commit, per branch, across hundreds of devices from multiple vendors including a range of switch operating systems, chipsets, and models, and thousands of virtual appliances from multiple vendors. This amounts to more than five million tests a day.

Apstra is also able to automatically run these tests at our customers’ sites for new hardware platforms which may not be part of the Apstra testbed.  If those tests pass, Apstra commits to supporting those devices, also. If those tests fail, then our customers are empowered with this information so they can decide which  hardware platforms and operating systems to deploy in their infrastructure.

3. Uniquely Open and Extensible Architecture  

Intent-Based Data Center Automation is, by definition, part of a horizontally layered architecture, whereby layers are loosely coupled through APIs to avoid lock-in. The solution operates at the management plane. It supports data planes from various hardware vendors and does not replace the data plane. It supports various control plane protocols from various hardware vendors and device OS vendors and does not replace the control plane.

The network can operate without Intent-Based Data Center Automation. Customers can even turn off the solution completely and the devices, operating systems, and network will continue operating. Customers can then continue controlling them using any other method they wish. Whether manual, or using other automation solutions, or software developed using a DIY model. With genuine Intent-Based Networking, there is absolutely zero lock-in.

In Apstra’s case, we stand committed to never break the Apstra APIs or threaten to do so in order to prevent customers from using other solutions. Apstra’s AOS  is driven by open APIs; these open APIs drive the Apstra web UI; they are used to integrate with other systems such as ServiceNow, Slack, Infoblox, etc.. Apstra uses protocol buffers to stream out all telemetry. Apstra uses graph queries to manipulate the graph datastore representation that is at the core of our system. Zero lock-in.

The Apstra solution is fully extensible and customizable to meet customers’ specific needs. Contrary to other solutions, Apstra doesn’t expect customers to change their requirements to meet Apstra’s solution — rather, the Apstra solution can be uniquely customized to the user’s requirements. Zero lock-in.  

Software First!

Ultimately, Intent-Based Networking enables organizations to move away from their “hardware first” approach.  This hardware-first approach is the 30-year old established process that network infrastructure teams choose their hardware first and then design their infrastructure and operations around this choice.

Intent-Based Data Center Automation, powered by Intent-Based Networking enables organizations to take a “software first approach”. Namely, start with the business needs and the infrastructure services that are required by the infrastructure. Once these are defined, then infrastructure teams and procurement organizations are free to choose the hardware of their choosing based on the criteria they care about: cost, second-sourcing, feature capability, or reliability.  The beauty of leverage and choice!

Indeed, digital transformation requires businesses to have the ability to spin up applications in an agile manner, relying on unified infrastructure services and a fungible pool of resources. These requirements can only be met if the infrastructure is cloudified which in turn means depends on the following prerequisites:

1. A unified set of APIs and Group Based Policies
2. Infrastructure automation
3. Abstract infrastructure components from the system-level services

With a software first model, business priorities can be met by defined and delivering on these capabilities first.

Onwards!

This is an exciting time in the industry. Businesses need to digitally transform. In order to do that, they need to change their ways. It is clear that the right solution involves a hybrid, distributed data center — anchored in the private cloud with the option to deploy a multi-vendor solution and an ability to leverage multiple public clouds as needed. With cloud services penetrating the private cloud (e.g. Microsoft with Azure Stack, and AWS with Outpost) customers can no longer afford to take a “hardware first” approach, and lock themselves into one hardware vendor.

Customers can certainly no longer afford to be blindly dependent on their hardware vendors who will use all methods available to them to compel them to abandon a multi-vendor approach and lock themselves into the hardware vendor’s solution.

Apstra pioneered Intent-Based Networking with a mission to break hardware vendor lock-in forever and enable organizations to automate their infrastructures while embracing heterogeneity. Automation and support for multi-vendor and multi-cloud are key to slashing costs, and delivering on infrastructure reliability and agility that are required for businesses to deliver on their goals.

Intent-Based Networking breaks the vicious cycle of vendor lock-in by committing to loosely coupled architecture and powerfully open APIs;  supporting the widest array of hardware vendor choices; providing a single throat to choke, thus providing choice without risk; And zero lock-in.

If you are committed to deliver on your goals, and get off your addiction to your current hardware vendor, please call us — we are delighted to help!

* This article was originally published here

* This article was originally published here

Hardware Vendor Lock-In: A Long and Messy Past

If you think about the beginnings of networking, hardware lock-in was the norm. The original IBM Token Ring, for example was a proprietary networking solution; and every new purchase order had to go to the same vendor if customers wanted to ensure connectivity.

Customers demanded interoperability between hardware vendors, and so came Ethernet which promised to be an open, interoperable standard. However, vendors recreated lock-in by implementing proprietary VLAN extensions such as private VLAN. 

Internet Protocol (IP) was another open standard. Yet hardware vendors convoluted the standard, and came out with proprietary routing protocols such as IGRP which were designed to lock customers into the hardware vendor’s equipment exclusively.

Today, with the emergence of merchant silicon, whitebox switches, and open source switch operating systems, it is more important than ever for businesses to defend themselves from lock in, and have the flexibility to be vendor-agnostic so they can leverage those options.

Yet by the same token, it has become more critical than ever for the hardware vendors to defend themselves from the competition by locking in their customers!  

So with white box switches, open source device operating systems, and commoditization on the rise, what is the new hardware vendor lock-in strategy? Hardware vendors are coming out with proprietary management APIs which lock their hardware to their management systems. These proprietary network management solutions are the ultimate form of lock-in — not the SNMP add-ons of the past, but sophisticated network monitoring, configuration and trouble-shooting solutions that only work with that one vendor’s equipment. Uber lock-in!

Why is Hardware Lock-in dangerous?

The dangers of hardware vendor lock-in are real, consequential, and affect every aspect of IT business operation. Hardware vendor lock-in is a primary inhibitor of organizations’ digital transformation initiatives and their ability to compete. It starts with the fact that IT is completely at that vendor’s mercy, which has profound consequences.

Extremely high costs

When an organization locks itself into their hardware vendor, two things happen:

1. IT loses control over the pricing of hardware:

How can IT have any leverage when there is only one vendor to talk to? IT may have negotiated an initial deal for the first batch of hardware, or for the first year. But when IT is locked-in, nothing prevents the hardware vendor from coming back with higher prices as soon as they are able.

Hardware vendors aggressively promote and position their own management software because they know once deployed they gain account control, become deeply entrenched, and make it difficult to replace them.  At that point, IT has all but guaranteed the highest prices and TCO (total cost of ownership).

In this report, Gartner comments that “By introducing competition in this thoughtful manner, Gartner has seen clients typically achieve sustained savings of between 10% and 30% and of as much as 300% on specific components like optical transceivers”. In another report, Gartner analysts Mark Fabbi and Debra Curtis find that “Sole-sourcing with any vendor will cost a minimum 20% premium, with potential savings generally reaching 30% to 50% or more of capital budgets when dealing with premium-priced vendors”.

2. IT loses control over operational expenses

Even more importantly, with vendor lock-in IT loses control over the ability to reduce operational expenses. This happens for many reasons:

1. Reducing operational expenses is achieved by using the automation tools that meet IT’s business needs. Those automation tools are generally built by specialized best-of-breed companies which are 100% focused on solving those problems. It is highly unlikely that the management software built by the hardware vendor, and designed to lock the customer into that hardware vendor will meet all the customer’s requirements for automation.
2. Hardware vendor positions extremely expensive and highly profitable “professional services” that build spaghetti code to remediate this divergence between IT requirements and the capabilities of their software solution. With every new version of the management software, the spaghetti code has to be upgraded, at excessive cumulative expense. The result is massive costs, coupled with an innate inability to deliver on the needs of the business.
3. The IT team becomes mired in hardware vendor minutia – from arcane commands to arcane workflows, or arcane vendor specific tools; this wastes resources and time, and keeps IT away from the tasks that are more aligned with the needs of the business.  It is no wonder that according to ZK Research, businesses are now dedicating 82% of their IT budgets solely to keeping the lights on, leaving very little budget for innovation.

In fact Gartner finds that by breaking their lock-in from one single vendor, some organizations were able to reduce their opex costs by as much as 95%!

Outages and security risks

1. Substantially higher rate of outages

When IT is locked into one hardware vendor, the business is completely at the mercy of their bugs and quality problems (both hardware and software). When problems occur, customers have no recourse but to depend on their hardware vendor, and them alone, to solve these problems. Even if they are motivated to fix the issues, they are limited by development cycles, and it may take them a lot longer to solve a problem than what IT has written down in an SLA contract, or by what is acceptable by the business. Even if IT is able to hold them accountable for violating their SLA, it doesn’t help the business, and frankly IT has very little recourse since they’re locked in. Being locked into the management software and analytics that the hardware vendor has provided means not being able to take advantage of other tools on the market that may be more effective at preventing these outages in the first place.  

2. Security vulnerabilities Exposure

Security vulnerabilities are common and are routinely discovered on devices in the infrastructure. When a hardware vendor discovers a security vulnerability in a customer’s hardware and device OS that they are locked into, the customer must wait for the hardware vendor to provide a patch, which may take months; and then when this patch shows up, the customer will need to go through their qualification process for that security patch, which may take many more months. Skipping the qualification process is akin to rolling the dice on new potential unknown bugs (a very common occurrence with new device OS versions) that could potentially cause bigger problems, performance problems, or outages. Gartner analyst Andrew Lerner wrote a great blog about the pain involved in network upgrades, where he compares the process to going to the dentist!

In summary, when a customer is locked into a hardware vendor and faces a security vulnerability there is a risk of being exposed for months before it can be remediated.

Failing to deliver for the business and losing relevance as a result

1. Unable to meet the requirements of the business

When IT locks itself into hardware, a massive missed opportunity cost is incurred. As engineers are deployed to become experts on vendor-specific hardware and device OS versions, they are unable to focus on the initiatives that are most critical to the business: the cloudification of their infrastructure; improving their infrastructure to avoid outages and improve application availability; automation efforts in support of the business’s digital transformation initiative, to name a few.

Indeed, it is common that Fortune 500 enterprises delay their critical automation initiatives because of their investment in becoming world experts at the vendor’s latest hardware or latest device operating systems. This is often viewed as a “sunk cost” and results in dramatic consequences to the business, and also to the relevance of infrastructure teams. As businesses digitally transform and application teams grow impatient with their hardware-first infrastructure teams’ inability to deliver on their requirements, application teams turn elsewhere to make progress.

2. Shadow IT

What often happens is that application teams and DevOps teams start spinning up workloads in the cloud, hence bypassing the IT infrastructure teams completely! The phenomena, often referred to as “Shadow IT,” is quite pervasive. For example, according to a 2014 PwC report, it was estimated that “80% of enterprises have used cloud platforms and SaaS applications that have not been approved by IT; and for those enterprises, the percentage of applications that were running on shadow IT was a whopping 35%.”  

Needless to say, shadow IT significantly increases the security risks for an organization; it also results in costs ballooning out of control.

In a future blog, I’ll tell you how a software first approach featuring Intent-Based Networking can help you avoid vendor lock-in.

* This article was originally published here

* This article was originally published here

As we release AOS 3.0, it’s time for the industry to consider taking a hard look at legacy and it’s crippling effects. It’s also a fitting opportunity to propose a path forward that enables organizations to eliminate legacy forever.

Indeed, everyone hates legacy, when defined in the context of infrastructure management. So why does it happen and how to eliminate it? Legacy is created when growing complexity in your infrastructure prevents you from making the changes in your infrastructure that are required for your business with the required agility and without unreasonable risk. In order to compete, you are required to make risk-free, agile, and safe changes. Yet, even though you own your infrastructure (and not the other way around), legacy prevents you from doing so.

The challenge, of course, is to move away from your legacy to a modern infrastructure in a manner that doesn’t disrupt your business. You want to be able to say “it’s not you, it’s me” when you feel the time is right.

The key aspect that makes it difficult to actuate change is that you may not even know what your current state is. How do you achieve “not disrupting your business” when you cannot say with certainty what business applications you are running and what their requirements are?

Your business applications are essentially a collection of compute endpoints. These endpoints have specific reachability requirements. They may have distinct security requirements. Some of them may be members of a load balancing group. They may have different HA and QoS requirements. They may differ in how mission critical they are to your business. Typically all the aspects (reachability, security, load balancing, HA, QoS) are implemented using different, separate enforcement mechanisms.

Now, as you attempt to change, evolve your legacy infrastructure, or even move to a different one you first need to understand current enforcement mechanisms and their interactions. Then you need to understand and leverage new enforcement mechanisms in your evolved infrastructure (as they have likely changed) and how they map to the ones implemented in the legacy infrastructure, while at the same time ensuring your business application’s requirements are still met.

The foundational automation architecture principle that helps you with this situation is the separation between service/policy specification (representation of your business applications and their requirements) and the enforcement mechanisms (how to implement/enforce these requirements). It states that the specification of your business needs should be decoupled from the way to implement them, satisfy them, and enforce them. Once you have that separation, the portability of your workloads becomes feasible. Only once you have that separation, can you map service intent to enforcement mechanisms — but this separation is the prerequisite.

So the first question is, what should that service specification look like? The answer to that question, in principle, has been around for quite a while. Variants of the concept of endpoint/group based policy specification can be found in OpenStack, AWS, and Azure. What does it look like?

Business application intent is expressed as a composition of endpoints that are placed into groups with the purpose of expressing the need for some common behavior: reachability, security, load balancing requirements, to state a few examples. Endpoint definition can vary. It can be an application, a virtual machine, a container, an external (unmanaged) endpoint, a physical/logical port, etc. Policies are instantiated and related to groups or individual endpoints to define that behavior. Policies can relate to groups in a directional or non-directional manner. Policies are collections of rules, that abide by a “condition followed by an action” pattern. Groups can be composed of other groups, creating hierarchy.

Endpoints, groups, policies, and rules can be thought of as building blocks for expressing intent. Dynamism is achieved by adding/removing endpoints to/from groups and by inheriting the policies applied to groups. Changing of the behavior is achieved by modifying the policies/rules that apply to groups and endpoints.

So if this has been around for a while, what are we missing? When modeling, there are two places where things can go wrong. First is at the model definition time. To do it right, the model has to be expressive enough to cater to all use-cases, while not being overly complicated. It needs to be complete, yet minimal. Endpoint/group based policy specification is expressive enough. The second opportunity for error is at the model application time. There are many instances where this model is applied directly to enforcement mechanisms as opposed to service/policy declaration. What one gets, as a result, is the “right model, applied to the wrong domain”.

Then there is the task of mapping service intent to enforcement mechanisms mentioned earlier. If not architected correctly this can be a very challenging task. Intent-Based Networking systems at Level 2 of the IBN taxonomy have the necessary foundations to complete this task, namely the Single Source of Truth and real-time, event-based reaction to change.

At Apstra, we’ve build AOS to incorporate the foundations into the architecture of the solution. In the absence of these foundations, overcoming the challenge typically results in leaking of enforcement abstractions into service/policy abstractions. ( See micro-segmentation blog for example). This violates the separation of policy and enforcement principle and results in non-portable workloads, which was the primary motivation for the separation in the first place. Note that leaking abstractions are sometimes introduced on purpose as vendors building these APIs may have little or no interest in universal portability of the workloads. That spells “lock-in”, which spells inability to change, which spells legacy.

We discussed in earlier blogs that the inability to deal with Day 2 operations turns your greenfield into a brownfield overnight. Business requirements specified in an enforcement agnostic, portable manner eliminate this danger.

This is one reason I’m excited about AOS 3.0, which we released today. It introduces for the first time, Group Based Policies, implemented using the architectural principles described above. With AOS 3.0, customers have the right starting point to eradicate legacy forever.  

You can read more about AOS 3.0 in the press release  and the data sheet. Please register for our upcoming webinar.

About the Author – Sasha Ratkovic:

Sasha Ratkovic is a thought leader in Intent-Based Analytics and a very early pioneer in Intent-Based Networking. He has deep expertise in domain abstraction and intent-driven automation. Sasha holds a Ph.D. in Electrical Engineering from UCLA.

* This article was originally published here

* This article was originally published here

Hardware Vendor Lock-In: A Long and Messy Past

If you think about the beginnings of networking, hardware lock-in was the norm. The original IBM Token Ring, for example was a proprietary networking solution; and every new purchase order had to go to the same vendor if customers wanted to ensure connectivity.

Customers demanded interoperability between hardware vendors, and so came Ethernet which promised to be an open, interoperable standard. However, vendors recreated lock-in by implementing proprietary VLAN extensions. Some vendors even went as far as going after other vendors who implemented private VLANs in court, to the detriment of customers and the industry as a whole!

Internet Protocol (IP) was another open standard. Yet hardware vendors convoluted the standard, and came out with proprietary routing protocols such as IGRP which were designed to lock customers into the hardware vendor’s equipment exclusively.

Today, with the emergence of merchant silicon, whitebox switches, and open source switch operating systems, it is more important than ever for businesses to defend themselves from lock in, and have the flexibility to be vendor-agnostic so they can leverage those options.

Yet by the same token, it has become more critical than ever for the hardware vendors to defend themselves from the competition by locking in their customers!  

So with white box switches, open source device operating systems, and commoditization on the rise, what is the new hardware vendor lock-in strategy? Hardware vendors are coming out with proprietary management APIs which lock their hardware to their management systems. These proprietary network management solutions are the ultimate form of lock-in — not the SNMP add-ons of the past, but sophisticated network monitoring, configuration and trouble-shooting solutions that only work with that one vendor’s equipment. Uber lock-in!

Why is Hardware Lock-in dangerous?

The dangers of hardware vendor lock-in are real, consequential, and affect every aspect of IT business operation. Hardware vendor lock-in is a primary inhibitor of organizations’ digital transformation initiatives and their ability to compete. It starts with the fact that IT is completely at that vendor’s mercy, which has profound consequences.

Extremely high costs

When an organization locks itself into their hardware vendor, two things happen:

1. IT loses control over the pricing of hardware:

How can IT have any leverage when there is only one vendor to talk to? IT may have negotiated an initial deal for the first batch of hardware, or for the first year. But when IT is locked-in, nothing prevents the hardware vendor from coming back with higher prices as soon as they are able.

Hardware vendors aggressively promote and position their own management software because they know once deployed they gain account control, become deeply entrenched, and make it difficult to replace them.  At that point, IT has all but guaranteed the highest prices and TCO (total cost of ownership).

In this report, Gartner comments that “By introducing competition in this thoughtful manner, Gartner has seen clients typically achieve sustained savings of between 10% and 30% and of as much as 300% on specific components like optical transceivers”. In another report, Gartner analysts Mark Fabbi and Debra Curtis find that “Sole-sourcing with any vendor will cost a minimum 20% premium, with potential savings generally reaching 30% to 50% or more of capital budgets when dealing with premium-priced vendors”.

2. IT loses control over operational expenses

Even more importantly, with vendor lock-in IT loses control over the ability to reduce operational expenses. This happens for many reasons:

1. Reducing operational expenses is achieved by using the automation tools that meet IT’s business needs. Those automation tools are generally built by specialized best-of-breed companies which are 100% focused on solving those problems. It is highly unlikely that the management software built by the hardware vendor, and designed to lock the customer into that hardware vendor will meet all the customer’s requirements for automation.
2. Hardware vendor positions extremely expensive and highly profitable “professional services” that build spaghetti code to remediate this divergence between IT requirements and the capabilities of their software solution. With every new version of the management software, the spaghetti code has to be upgraded, at excessive cumulative expense. The result is massive costs, coupled with an innate inability to deliver on the needs of the business.
3. The IT team becomes mired in hardware vendor minutia – from arcane commands to arcane workflows, or arcane vendor specific tools; this wastes resources and time, and keeps IT away from the tasks that are more aligned with the needs of the business.  It is no wonder that according to ZK Research, businesses are now dedicating 82% of their IT budgets solely to keeping the lights on, leaving very little budget for innovation.

In fact Gartner finds that by breaking their lock-in from one single vendor, some organizations were able to reduce their opex costs by as much as 95%!

Outages and security risks

1. Substantially higher rate of outages

When IT is locked into one hardware vendor, the business is completely at the mercy of their bugs and quality problems (both hardware and software). When problems occur, customers have no recourse but to depend on their hardware vendor, and them alone, to solve these problems. Even if they are motivated to fix the issues, they are limited by development cycles, and it may take them a lot longer to solve a problem than what IT has written down in an SLA contract, or by what is acceptable by the business. Even if IT is able to hold them accountable for violating their SLA, it doesn’t help the business, and frankly IT has very little recourse since they’re locked in. Being locked into the management software and analytics that the hardware vendor has provided means not being able to take advantage of other tools on the market that may be more effective at preventing these outages in the first place.  

2. Security vulnerabilities Exposure

Security vulnerabilities are common and are routinely discovered on devices in the infrastructure. When a hardware vendor discovers a security vulnerability in a customer’s hardware and device OS that they are locked into, the customer must wait for the hardware vendor to provide a patch, which may take months; and then when this patch shows up, the customer will need to go through their qualification process for that security patch, which may take many more months. Skipping the qualification process is akin to rolling the dice on new potential unknown bugs (a very common occurrence with new device OS versions) that could potentially cause bigger problems, performance problems, or outages. Gartner analyst Andrew Lerner wrote a great blog about the pain involved in network upgrades, where he compares the process to going to the dentist!

In summary, when a customer is locked into a hardware vendor and faces a security vulnerability there is a risk of being exposed for months before it can be remediated.

Failing to deliver for the business and losing relevance as a result

1. Unable to meet the requirements of the business

When IT locks itself into hardware, a massive missed opportunity cost is incurred. As engineers are deployed to become experts on vendor-specific hardware and device OS versions, they are unable to focus on the initiatives that are most critical to the business: the cloudification of their infrastructure; improving their infrastructure to avoid outages and improve application availability; automation efforts in support of the business’s digital transformation initiative, to name a few.

Indeed, it is common that Fortune 500 enterprises delay their critical automation initiatives because of their investment in becoming world experts at the vendor’s latest hardware or latest device operating systems. This is often viewed as a “sunk cost” and results in dramatic consequences to the business, and also to the relevance of infrastructure teams. As businesses digitally transform and application teams grow impatient with their hardware-first infrastructure teams’ inability to deliver on their requirements, application teams turn elsewhere to make progress.

2. Shadow IT

What often happens is that application teams and DevOps teams start spinning up workloads in the cloud, hence bypassing the IT infrastructure teams completely! The phenomena, often referred to as “Shadow IT,” is quite pervasive. For example, according to a 2014 PwC report, it was estimated that “80% of enterprises have used cloud platforms and SaaS applications that have not been approved by IT; and for those enterprises, the percentage of applications that were running on shadow IT was a whopping 35%.”  

Needless to say, shadow IT significantly increases the security risks for an organization; it also results in costs ballooning out of control.

In a future blog, I’ll tell you how a software first approach featuring Intent-Based Networking can help you avoid vendor lock-in.

* This article was originally published here

* This article was originally published here