The 2020 State of Network Automation

The Annual Report on Key Network Automation Trends

Research sponsored by

Contents

Key Findings ��4

Executive Summary ��5

Meet the Expert ��6

The 2020 State of Network Automation Varies by Segment ��7

Chapter 1: The 2020 State of Enterprise Network Automation �� 12

Chapter 2: The 2020 Communications Service Provider State of Network Automation �� 24

Chapter 3: The 2020 Cloud Provider State of Network Automation �� 38

Chapter 4: The Road to Greater Network Automation Maturity �� 52

Appendix: Demographics and Methodology �� 62 Key Findings

The network automation Network automation is 1 revolution is well-underway. 2 quickly changing how

About 75% of Communications Service Providers networks are deployed, changed, (CSPs), 71% of Enterprises, and 78% of Cloud and managed for everyone. Providers report they use some type of network While 47% of organizations started to automate less automation. than 3 years ago, 50% already automate in production networks.

Reducing repetitive work The more automated the 3 (toil) and scaling efficiency 4 network, the lower the risk are the top technology drivers. that production network changes

Out of the 11 technology drivers, reducing hard result in degraded service. and repetitive work is #1 with CSPs, Enterprises, Nearly 60% of mature automators say that network and Cloud Providers alike. Nearly 20% report that changes very rarely result in service issues, including the need to reduce toil is why they automate 14% who say that network changes never lead to the network. service degradations.

Job satisfaction rises with Businesses that implement 5 the level of network 6 network automation automation. outperform those who don’t.

Among the top group of network automators, 78% About 67% of leading network innovators exceed say they’re satisfied with the job compared to 60% organizational performance goals compared to 57% of non-automating respondents. of non-automating respondents.

4 Executive Summary

Welcome to the State of Network Automation Report There’s one chapter for each of the three types of (SoNAR). For the second year, SoNAR aims to provide network equipment users – Communications Service insights about the overall journey to automation, Providers, Cloud Providers, and Enterprises – that understanding how and when companies are embracing explains: this path, and what are the results of this decision. ҋ where they automate, For SoNAR 2020, the survey was expanded to include ҋ tools, vendors, and processes for network Enterprise, Cloud and Communications Service Provider automation before and during production, network operators around the world. By tapping into markets beyond the United States, we are able to better ҋ business outcomes, and understand Enterprises, Communications Service ҋ network architect commentary. Providers, as well as Cloud Providers. Finally, the last section presents the roadmap to In addition, the survey also included organizations that achieving greater network automation. It has: have not yet started their network automation journey. After all, to truly understand the 2020 State ҋ individual and team skills that move you and of Network Automation, it’s important to hear from your organization to the next level of network organizations that are yet to start their automation automation, journey, those at the beginning, those who are testing, ҋ departmental outcomes, and as well as those organizations that have embraced it. ҋ wrap up from a network architect and NOG The big picture of network automation includes: (Network Operator Group) organizer to help you ҋ automation maturity for telecommunications along your path toward greater network automation. and cable service providers (referred to as “Communications Service Providers (CSPs)” throughout this report), Cloud Providers and Enterprises,

ҋ automation tenure,

ҋ business and technology drivers, and

ҋ network automation challenges.

1 The Sample Acquired from Cloud Provider is below the expected, but still enough to present a trend and interesting Insights.

5 Meet the Expert

Donal O Duibhir

Donal wears many hats and believes we are all network engineers in one form or another. He’s been automating networks, systems, and processes for the last 20 years across a wide variety of use cases. He currently consults at He consults at Defensible, builds engineering and security tools at PanSift, and grows community with iNOG. Donal hails from a mix of engineering, security, and product roles across telco/ mobile, enterprise, vendors, and startups. He’s previously held multiple industry certifications (including an early CISSP back when it was cool!) and comes from a computer science background. These days he gets the most satisfaction when growing communities of practice, writing, and automating things.

@irldexter

linkedin.com/in/podomere/

6 The 2020 State of Network Automation Varies by Segment

Results show that the three segments CSPs, Cloud This contrasts sharply with both CSPs and Enterprises. Providers, and Enterprises – are all at different stages Only 10% of CSPs use automation in production in all of automation maturity. While about a quarter of each network places. Given the obvious limitations that segment is beginning to automate beyond the CLI come with scale and complexity of large CSP networks, with basic scripting – which itself, shows that network this is to be expected. Meanwhile, Enterprises lag both automation is a lasting trend. A full 24% of Cloud types of service providers in automation maturity, but Providers say they use automation in production in all resemble CSPs in how long they’ve been using network places, even though nearly 40% are fairly network automation. new to automation and have been using it for less than 3 years.

31% 29% 25% 26% 25% 23% 24% 24% 22% 21%

13% 12% 11% 10%

CSP (n=150) Cloud provider (n=46) Enterprise (n=449)

Beginning to automate In test, development, or In production - some In production - all Not Automating beyond CLI with basic lab environment only network places network places scripting

31% 27% 28% 25%

21% 21% 18% 17% 17% 15% 13% 12% 11% 11% 8% 8% 7% 4%

CSP (n=150) Cloud provider (n=46) Enterprise (n=449)

Less than one year 1-2 years 2-3 years 3-4 years 4-5 years More than 5 years

7 In 2019, the most common technology driver was improving metrics like time to change and incident improved security, but this year all segments say the response and mean-time-to-repair (MTTR) rank third top driver to automate is to reduce hard and repetitive and fourth. However, Enterprises are different. Equally work (toil). From there, segments rank technology important to reducing toil, Enterprises automate to drivers very differently. Both types of service providers improve incident response and their MTTR including say that scaling network operational efficiency is the to improve security outcomes. second most important technology driver and

Technology Drivers Telco and Cable/MSO Cloud Provider Enterprise

Weighted Rankings % Rank % Rank % Rank

Reducing hard and 20% 1 18% 1 17% 1 repetitive work Scaling efficiency of network footprint relative 13% 2 13% 2 11% 4 to headcount

Improving time to change 12% 3 12% 3 10% 5

Improving incident response 10% 4 12% 4 17% 1 and MTTR

Security 9% 5 8% 6 14% 3

Service experience levels 8% 6 6% 7 5% 11

Service uptime levels 8% 7 11% 5 9% 6

Keeping current on 7% 8 8% 8 6% 7 network tech

Compliance 6% 9 9% 9 6% 7

Improving MTBF 5% 10 0% 10 6% 7

Sustaining innovation 4% 11 4% 11 6% 7

8 When it comes to business drivers for network savings as the top business driver. Compared to 2019, automation, this time, Cloud Providers look more like when business agility gained the top spot, network Enterprises. The cloud crowd pairs up with the professionals overall have come to appreciate how enterprise segment where 26% and 27% respectively network automation can improve IT service reliability report IT service reliability as the top driver. This and service delivery efficiency. contrasts with CSPs who at 32% strongly report cost

Business Drivers Telco and Cable/MSO Cloud Provider Enterprise

Weighted Rankings % Rank % Rank % Rank

IT service reliability 24% 2 27% 1 26% 1

IT service delivert efficiency 24% 2 22% 2 23% 2

Cost savings 32% 1 17% 3 19% 3

Business agility 21% 4 15% 4 14% 4

9 As for challenges relating to automation, just like 2019, After you look at why these three types of network the biggest challenge for all segments is the lack of users automate network operations and their time to learn on the job. But from there, each segment challenges with it, the conclusion is inescapable. They ranks challenges differently. At 61%, Cloud Providers are very different. This is why we analyze and present report that fear of making a mistake in production is network operations related results separately for equally challenging, which happens to rank second for Enterprises, Communications Service Providers, and enterprise network professionals. Meanwhile, CSPs for Cloud Providers. grapple with different challenges with automation. 64% don’t have the knowledge necessary to access training and almost as many – at 64%, say older networking equipment makes it hard to automate.

Challenges Related to Automation

70% lack of time to learn on the job 61% 69%

64% Lack of knowledge necessary to access training 50% 61%

55% Fear of making a mistake in production 61% 62%

55% Overwhelming number of technology choices 57% 61%

63% Older networking equipment that’s hard to automate 59% 58%

55% Lack of training resources 59% 55%

51% Lack of lab of safe place to test/practice 48% 57%

50% Not enough motivating factors to warrant 37%

deployment of automation 52%

45% Lack of budget or financial barriers 46% 52%

43% Organizational culture doesn’t value automation 39% 48%

10 An automation dojo in your browser. Learning to automate is now free, open, easy, and fun.

Learn more Chapter 1

Chapter 1: The 2020 State of Enterprise Network Automation

In our research, nearly one-third of our 449 Enterprises Key: Short names for groups along the maturity don’t automate at all. Another 12% consider themselves scale to be full automators and just over 20% are partial Full automators = in production in all network places automators. All told, about another third are testers and Partial automators = in production in some network beginners. In this section, results cover industry and places automation maturity within each industry, where Testers = in a test, development or lab environment only Enterprises automate in their networks, their tools, Beginners = beginning to automate beyond CLI with processes, and of course, business outcomes according basic scripting to network automation maturity. Non-automators = Not automating

Specifically, after you understand respondents, you’ll learn by network automation maturity:

ҋ where they automate,

ҋ tools,

ҋ vendors,

ҋ processes for network automation before and during production, and

ҋ how well Enterprises meet 4 key business goals.

The automation maturity scale has 5 levels, ranging from not automating at all to being in production across all places in the network. The below key has the short names used throughout the report and how they are defined.

12 Enterprise respondents are dominated by explain the role of industry in network automation those in IT-related industries. maturity. There are more full automators in IT, financial services, education and manufacturing, and more The remaining respondents are spread among all the non-automators in energy, healthcare and government. economy’s industries and some have quite small Trends are consistent with the usual “innovation by numbers. Nonetheless, the following chart helps industry” trends.

Retail 20% 20% 20% 40%

Other Commercial (e�g�, High Tech, Scientiﬁc Research, Travel Hospitality, etc�) 36% 36% 4% 20% 4%

Other 67% 33%

National Government (Defense, Education Science, Health Beneﬁts, Taxation Finance, Justice Public Safety 32% 23% 5% 32% 9%

Media and Entertainment 28% 39% 11% 17% 6%

Manufacturing 24% 32% 12% 21% 12%

Local Government 33% 8% 8% 33% 17%

Information Technology 25% 24% 15% 22% 14%

Healthcare 38% 31% 23% 8%

Financial Services (Banking, Market Data, Retail Services, Order Routing / Execution, etc�) 30% 27% 11% 19% 14%

Energy, Oil, Gas 41% 19% 15% 19% 7%

Education (K-12, Higher Education) 32% 29% 11% 16% 13%

Not automating Beginning to automate beyond CLI In test, development, or lab environment only In production - some network places In production - all network places

13 Chapter 1

Enterprises automate the data center Beginners also tackle their wireless network most often and the enterprise WAN automation more often than others. Partial automators second most. are slightly more likely to focus on the data center. Full automators, much like you’d expect – spread automation efforts everywhere

Data center 11% 7% 12% 7% 37%

Enterprise WAN 8% 5% 7% 4% 24%

Wireless 10% 4% 6% 3% 24%

Public cloud 5% 4% 6% 3% 18%

Branch and small site, inc SD-WAN 6% 3% 6% 2% 18%

Campus or large site 5% 3% 6% 3% 17%

Cloud native or app cluster networking 3% 3% 4% 4% 14%

SP provider WAN, core, and backbone 3% 3% 3% 3% 11%

SP cloud, telco cloud, NFV cloud 3% 2% 4% 3% 11%

SP subscriber edge and aggregation 2% 2% 3% 2% 9%

SP access 2% 2% 2% 2% 8%

SP mobile infrastructure 2% 2% 3% 1% 8%

Beginning to automate beyond CLI Edge compute cloud 2% 2% 2% 1% 7% In test, development, or lab environment only In production - some network places SP metro 2% 1% 1% 4% In production - all network places

SP packet optical 1%1%1% 2%

14 Enterprises rely most on configuration APIs with devices. But partial automators and testers management tools to automate network also use container-based deployment for network deployments, changes, and management. automation more than full automators. Partial automators also use on-device automation more often, Enterprises resemble their communications provider as well. It may well be cheaper, easier, and lower risk for colleagues in the tools they use. Slightly more than half partial automators to use ephemeral or pre-built – 53% - use configuration management tools compared containers to perform infrequent tasks against vendor to the second most common at 42%, APIs at the virtual APIs. This could be seen as a lightweight and frictionless or physical device level. Full automators – who have path to more long-lived automation practices. been automating longer – mostly use config tools and

Conﬁguration management tools 18% 10% 15% 10%

APIs at the virtual or physical device level 14% 6% 12% 9%

On-device automation 12% 5% 11% 5%

Container-based deployment model for 7% 7% 13% 6% our network automation

Customer-monitoring tools and 9% 6% 8% 5% telemetry collection

Software-deﬁnes or intent-driven networking 8% 6% 11% 4% products that include a centralized controller Beginning to automate beyond CLI Infrastructure as code templating and modeling tools 6% 6% 9% 7% In test, development, or lab environment only APIs at the SDN controlloer or In production - some network places 6% 4% 7% 3% management plane level In production - all network places

15 Chapter 1

Enterprises that use network automation primarily use 4 leading vendors.

Cisco 19% 20% 10% 17% 9% 75%

Juniper 18% 14% 8% 12% 7% 59%

VMware 12% 13% 7% 9% 4% 45%

Palo Alto 10% 7% 4% 7% 2% 30%

Dell 7% 7% 5% 6% 3% 28%

HPE 10% 7% 2% 5% 3% 27%

Fortinet 9% 6% 3% 5% 3% 26%

Huawei 3% 5% 2% 3% 2% 15%

Extreme 5% 4% 1% 3% 1% 14%

Arista 2% 4% 1% 3% 2% 12%

Avaya 4% 2% 2% 2% 2% 12%

Others 2%1%2%1% 6%

Not automating Beginning to automate beyond CLI In test, development, or lab environment only In production - some network places In production - all network places

16 Other, 2% Don’t automate How Enterprises manage automation testing - make before and during production varies by changes directly in production and automation maturity stage. test afterward, 12%

Most Enterprises test changes in a test or staging lab Don’t use a lab, using emulation or simulation tools. However, unlike Test changes in but test changes with emulation both communications and cloud service providers, a test/staging lab or virtual lab tools, 12% Enterprises are more likely to skip the lab. After all, 17% with emulation or simulation test changes with emulation tools and another 12% tools, 70% simply make changes directly in production and then test it.

As to how they automate testing, nearly 40% use common. Partial automators seem to use a broader reviewing tools that are part of change management. range of tools than full automators including automated Full and partial automators obviously use reviewing hooks and testing on code commits, source code tools, but automated pipeline tools are second most management tools and frameworks.

Reviewing tools as part 12% 6% 11% 8% of change management

Tools for test simulation 8% 5% 8% 5%

Pipelining tools for 5% 6% 9% 7% continuous integration

Automated hooks and testing 7% 5% 8% 6% on code commits

Frameworks or tools for testing 4% 4% 6% 5%

Source code management tools 2% 3% 6% 3% Beginning to automate beyond CLI for infrastructure as code In test, development, or lab environment only Beginning to automate beyond CLI Event-driven frameworks 1%1% 2% 2% In test, development, or lab environment only

17 Chapter 1

For full, partial and testers among enterprise network To Resolution) and MTBF (Mean Time Between Failures) automators, the most important service reliability is least important. This contrasts with beginners and metrics are application and user experience metrics like non-automators who still say MTTR is the most latency and throughput. Next comes MTTR (Mean Time important service reliability metric.

In production - all network places 27% 34% 37%

In production - some network places 29% 32% 37%

In test, development, or lab 29% 34% 37% environment only

Beginning to automate beyond CLI 28% 37% 35% In production - all network places 27% 34% 37%

Not automating 30% 37% 33% In production - some network places 29% 32% 37% Other Mean time between failures In test, development, or lab 29% 34% 37% environment only Mean time to resolution Application and user experience metrics like latency and throughput Beginning to automate beyond CLI 28% 37% 35%

Not automating 30% 37% 33%

Other Mean time between failures Consistent with service provider networks,Mea then tim emore to reso luati on week with 7% making changes more than once a day. In production - allnetwork places 11% 7% 24% 17% 30% 4% 7% network is automated, the more often changesApplication areand user experieAsnce formetr ipartialcs like laten cautomators,y and throughput 35% make changes at least multiple times per week and half of those are more made to Ithen pro primaryduction - s networkome netwo rservice.k places 27%4% of full19% 22% 19% 16% 5% 14% automators make changes at least multiple times a than once a day.

In test, development, or lab environment only 2% 33% 19% 18% 23% 2%

Beginning to automat ebeyond CLI 4% 22% 25% 22% 19% 1% 8%

In production - allnetwork places 11% 7% 24% 17% 30% 4% 7%

Don’t know Once every 3 months or longer

In production - some network places 4O%nce per m19on%th 22% Once per week 19% 16% 5% 14% Multiple times per week Once per day More than once per day In test, development, or lab environment only 2% 33% 19% 18% 23% 2%

Beginning to automat ebeyond CLI 4% 22% 25% 22% 19% 1% 8%

Don’t know Once every 3 months or longer Once per month Once per week Multiple times per week Once per day More than once per day

18 The more an enterprise network is automated, the less until it takes full effect in production. While not as lead time for changes is required. 15% of full strong of a trend as in the service provider segments, automators and 18% of partial automators say it takes a both beginner and testers skew toward longer time day or less from the time a change request is serviced intervals for changes taking effect in production.

In production - all network places 6% 7% 11% 22% 39% 9% 6%

In production - some network places 3% 4% 13% 32% 29% 15% 3%

In test, development, or lab environment only 11% 26% 30% 25% 5% 3%

In production - all network places 6% 7% 11% 22% 39% 9% 6% Beginning to automate beyond CLI 4% 7% 22% 25% 30% 10% 3%

In production - some network places 3% 4% 13% 32% 29% 15% 3% Don’t know More than 3 months Between 1-3 months Between 1-4 weeks In test, development, or lab environment only 11% 26% 30% 25% 5% 3% Between 1-7 days Less than 1 day Less than 1 hour

Beginning to automate beyond CLI 4% 7% 22% 25% 30% 10% 3%

The speed of restoring service after serviceDon’t incidents know or likely dueM toore vastlythan 3 m odifferingnths enterprise requirements as Between 1-3 months Between 1-4 weeks well as smaller network scale. Nonetheless, full defects does not vary as much by networkBe twautomationeen 1-7 days Less than 1 day maturity for Enterprises. While research showsLess than a1 hourhuge automators still restore service in less than an hour far In production - all network places 6% 9% 11% 13% 37% 24% impact that higher automation levels bring to service more often than beginners and other less mature enterprise network automators. restorationIn p ronod ucommunicationsction - some network pandlace scloud2%2% 4provider% 18% 19% 42% 12% networks, it’s not as impactful for Enterprises. This is

In test, development, or lab environment only 5% 21% 7% 18% 32% 16%

In production - all network places 6% 9% 11% 13% 37% 24% Beginning to automate beyond CLI 4% 2% 11% 9% 17% 42% 16%

In production - some network places 2%2% 4% 18% 19% 42% 12% Don’t know More than 3 months Between 1-3 months Between 1-4 weeks In test, development, or lab environment only B5e%tween 1 -7 d21a%ys 7% 18% Less than 1 day 32% 16% Less than 1 hour

Beginning to automate beyond CLI 4% 2% 11% 9% 17% 42% 16%

Don’t know More than 3 months Between 1-3 months Between 1-4 weeks Between 1 -7 days Less than 1 day Less than 1 hour

19 Chapter 1

The more automated the enterprise network, the more most of them say it’s more than once of a day - frequently teams detect trouble. 28% of full automators compared to 14% of testers and 18% of beginners. say they get trouble reports at least once per day –

In production - all network places 6% 15% 19% 19% 15% 9% 19%

In production - some network places 4% 9% 24% 26% 31% 3% 3%

In production - all network places 6% 15% 19% 19% 15% 9% 19% In test, development, or lab environment only 5% 12% 37% 14% 18% 5% 9%

In production - some network places 4% 9% 24% 26% 31% 3% 3% Beginning to automate beyond CLI 6% 18% 18% 22% 17% 6% 12%

In test, development, or lab environment only 5% 12% 37% 14% 18% 5% 9% Don’t know Once every 3 months 1x/month 1x/week Beginning to automate beyond CLI 6% 18% 18% 22% 17% 6% 12% Multiple x/week 1x/day More than 1x/day

Don’t know Once every 3 months 1x/month 1x/week Multiple x/week 1x/day More than 1x/day Lastly, an automated enterprise network is a more to remediation. More than half of full automators reliable enterprise network. The more automated it is- experience service problems for less than 10% of the more likely changes become less prone to human changes and 9% of full automators never make changes error. The end result is that changes to production are that result in service problems. 100% 4% 5% 4% 9% ce

less likely to end up in degradedi service - that then lead v r e s

80% 31% 32% 33% n i t l

u 48% 100% s e 604%% 5% 4% r 9%

on s 16% t i 14% a

ti 20% v r h a t e

80% 32% 31% eg r 33% 14% n 40% 16% 6% d ge s i 13% t n

l 6% a u 11% 48% h 6% s 5% 11% c

e 2% 60% r f 20% 6% 6% on s 16% t 10%

o 4%

14% 2% a ti 20% 2%

e 2% h a 9% r

t 7%

a 2% 17%

h 13% eg r 40% 9% 14% S 6% 16% 6% d ge s 13%%

n 6% a Beginning to In test, developme11nt%, In production - some In production - all h 6% 5% 11% c 2% automate beyond CLI or lab environment network places network places f 20% 10% 6% 6%

o 4% only 2% 2% e 9% 2% r 7% a Non2e% 1-10% 11-20% 21-30% 31-40% 41-50% 51-60%17% 61-70% 71-100%

h 13% 9% S % 6% Beginning to In test, development, In production - some In production - all automate beyond CLI or lab environment network places network places only None 1-10% 11-20% 21-30% 31-40% 41-50% 51-60% 61-70% 71-100%

20 Network automation contributes to an services where technology is not central to the offering. enterprise’s overall success. Still, when asked about whether they were above, met, or below goal for 4 key business goals for the last year, Just as with communications and cloud service full automators are consistently at or above goal. All providers, the more an organization uses network told, 98% of them are at or above goal for for more automation, the higher the business benefit. The gap customers and relative market share. Meanwhile, 94% between automators and non-automators, though, isn’t say they’re at or above goal for time to market for new as strong among Enterprises as we see among service products and organizational performance. providers. But Enterprises represent a broader of business requirements than they do. For example, unlike Over the past year, the status of goal for... service providers, some Enterprises offer goods and

More Customers Relative Market Share for Primary Products

In production in all 67% In production in all 48% 31% 50% network places 2% network places 2% In production across 57% In production across 49% some network places 31% some network places 39% 12% 13% In a test, development, 57% In a test, development, 44% or lab environment only 32% or lab environment only 42% 11% 11% Beginning to automate 49% Beginning to automate 49% beyond CLI with basic 38% beyond CLI with basic 40% 10% 15% scripting scripting 50% 48% Not automating 36% Not automating 40% 14% 12% 0% 20% 40% 60% 80% 100% 0% 20% 40% 60% 80% 100%

Below goal Met goal Above goal Below goal Met goal Above goal

Time to Market for New Products Organizational Performance

42% In production in all 60% In production in all 52% 35% network places 6% network places 6% In production across 51% In production across 58% 28% some network places some network places 32% 21% 11% In a test, development, 42% In a test, development, 51% 47% or lab environment only or lab environment only 32% 21% 18% Beginning to automate 44% Beginning to automate 47% 35% beyond CLI with basic beyond CLI with basic 38% 11% 15% scripting scripting 34% 48% Not automating 51% Not automating 39% 15% 12% 0% 20% 40% 60% 80% 100% 0% 20% 40% 60% 80% 100%

Below goal Met goal Above goal Below goal Met goal Above goal

21 Chapter 1

Summing up: Enterprises may lag service Donal’s Takeaways for Enterprises providers in network automation, but Enterprises come in all shapes and sizes. They often they see the same network operations, provide or integrate a mix of functions previously seen reliability and business benefits. in our other service provider segments but use a wider Enterprises automate in 3 or 4 key areas, and range of vendors. The access edge provides an penetration of network automation into the general on-ramp to local or remote services sourced from enterprise market has a long way to go. But that said, private or shared data centers (but increasingly from Enterprises who do automate see the same benefits as public clouds). The network plays a productivity service providers. Although they tend to use less supporting role, and more often than not, does not expensive tools to automate like pre-built containers generate or contribute directly to an organization’s and may not have complex testing labs, the trend is revenue streams. Services are consumed primarily by the same. The more automated the network is, the internal users via managed endpoints (though not better the operations and reliability help the business. always). When network scale is considered, the enterprise segment automates at a slower pace. It is unclear why and what specific or aggregate factors contribute to this lack of automation. It may be due to a slower cadence of new services, slower organic growth, or perhaps due to a primarily internal service consumption model. Another hurdle may be that of a more heterogenous footprint of services. It might be interesting in future to explore which enterprises host their own revenue generating platforms and on who’s underlay or overlay network stack.

22 Within the enterprise segment, the largest percentage misunderstood 802.11 protocol has helped unchain us of those who automate in all network places reside in from our desks and enabled new forms of the Retail sub-sector. This may be due to chain stores’ collaboration. WLAN’s have also brought with them scale and homogeny. When found together, these their own set of complex challenges as the medium characteristics are ripe for automation though the and protocol is only robust up to a point. It suffers overarching figures point to data center automation from rapid and intermittent congestion collapse which rather than branch provisioning and management. is extremely hard to predict and observe. It is this Automation is readily applied to standardized and complex service edge where AI-driven automation is modular service offerings, so it’s unsurprising that making in-roads, not just with configuration and most enterprise automation takes place in the data change management, but with troubleshooting, service center highlighting the old, “pets vs. cattle” analogy. assurance, and even remediation activities. This service edge is crucial for enterprises as their shared Following closely behind enterprise data center productivity rests upon it and we’re set to see AI automation is that of the WAN(Wide Area Network) transform more than just the edge! To see user and then the wireless edge. WANs are traditionally experience metrics being the most important service expensive and prime candidates for cost reduction metric to all levels of automators in enterprises is also initiatives such as SD-WAN(Software Defined WAN) heartening (and echoes that of the most mature for more intelligent and reliable service delivery automators who reside in the cloud provider space). irrespective of the underlying circuit type. One of the most interesting innovations and paradigm shifts though is happening on the wireless edge. WLAN(Wireless LAN) is hugely complex and the often

23 Chapter 2

Chapter 2: The 2020 Communications Service Provider State of Network Automation

In this chapter, you’ll learn about network automation Respondents are mostly from this year’s sample of 150 Communications Service telecommunications providers and Providers around the world. represent all continents.

Specifically, you’ll learn about the follow aspects of Nearly 89% of participating CSPs are automation, segmented by network automation telecommunications providers and the remaining are maturity level: cable or multiple system operators. About 57% are ҋ where they automate, outside North America.

ҋ tools, Cable / MSO (Multiple System Operators), ҋ vendors, 11�4%

ҋ processes for network automation before and during production, and

ҋ how well CSPs meet 4 key business goals.

The automation maturity scale has 5 levels, ranging Telcos, including from not automating at all to automation being in wireline, mobile, integrated, etc., production across all places in the network. The below 88�6% key has the short names used throughout the report and how they are defined.

Key: Short names for groups along the maturity scale Full automators = in production in all network places Partial automators = in production in some network Asia-Pac, places 17% Testers = in a test, development or lab environment North America, only 43%

Beginners = beginning to automate beyond CLI with EMEA, basic scripting 33% Non-automators = Not automating

LATAM, 7%

24 Automation is used throughout CSP But it’s deployed most often in the communications (CSP) networks. service provider WAN, core and backbone network domains, followed by access networks and then data center.

SP provider WAN, core, and backbone 6% 1% 12% 7% 27%

SP access 4% 5% 9% 5% 24%

SP cloud, telco cloud, NFV cloud 3% 1% 11% 7% 21%

SP subscriber edge and aggregation 5% 2% 9% 1% 16%

SP mobile infrastructure 3% 3% 5% 1% 11%

SP metro 3% 1% 5% 2% 11%

SP packet optical 3% 1% 5% 1% 16%

Edge compute cloud 1% 4% 1% 5%

Data center 7% 5% 9% 2% 23%

Cloud native or app cluster networking 1% 5% 4% 11%

Public cloud 3% 1% 2% 1% 7%

Enterprise WAN 8% 1% 5% 3% 17%

Branch small site, inc SD-WAN 3% 2% 8% 3% 17%

Wireless 6% 3% 6% 1% 16%

Campus or large site 1% 3% 3%

Beginning to automate beyond CLI In test, development, or lab environment only In production - some network places In production - all network places

Pay attention to beginners and testers. Beginners show where automation starts – which is in the enterprise WAN (8%) and data center (8%).

25 Network automation is poised to substantially impact communications service provider network operations. Partial automators are fast gaining experience in many locations in the network. Most notably, at 9%, they’re innovating at the SP subscriber edge and aggregation.

26 Not surprising, most CSPs use multiple There are some differences though, according to tools for network automation. automation maturity. Admittedly, full automators use the range of tools. But the top 2 tools used that edge Overall, CSPs use about 3 different ways together to out other options – at 9% each- are configuration automate network deployments, changes, and management tools and and on-device automation with management. More than half of CSPs automate using on-box scripting or apps. This compares to partial APIs at the virtual or physical device level and automators who are consistent with the overall trend. configuration management tools. Ranking third, just But it’s interesting to note that partial automators who over 40% of CSPs use on-device automation with – at 27% - are strongly most inclined to use APIs at the on-box scripting or apps. virtual or physical device level. The second most common tool for partial automators, at 23%, comes configuration management tools.

APIs at virtual or physical device level 15% 5% 27% 8%

Conﬁguration management tools 12% 8% 23% 9%

On-device automation with on-box scripting or apps 13% 5% 16% 9%

Custom monitoring tools and telemetry collection 12% 3% 13% 5%

Software-deﬁned or intent-driven networking products 4% 2% 14% 8%

Container-base deployment model 4% 3% 12% 6%

APIs at SDN controller or mgmt plane level 4% 4% 10% 7%

Infrastructure as code templating and modeling tools 6% 3% 7% 5%

Beginning to automate beyond CLI In test, development, or lab environment only In production - some network places In production - all network places

The average number of tools communications service providers use to automate network deployments, changes, and management.

27 Chapter 2

CSPs also use multiple network vendors.

Juniper 21% 17% 8% 28% 9% 82%

Cisco 22% 16% 9% 26% 7% 80%

Others 18% 14% 7% 19% 7% 65%

VMware 10% 7% 4% 16% 5% 41%

Nokia 11% 7% 3% 14% 7% 41%

Fortinet 7% 7% 4% 13% 3% 35%

Huawei 12% 7% 3% 9% 3% 34%

Dell 5% 7% 1% 11% 5% 28%

HPE 3% 4% 1% 9% 3% 19%

Palo Alto 3% 3% 9% 3% 19%

Ericsson 3% 3% 1% 10% 2% 19%

Not automating In test, development, or lab environment only In production - all network places Beginning to automate beyond CLI In production - some network places

Juniper is the mostDon’t aut ocommonmate testing� vendor We make changes directly in production, test afterward for partial and full automators.12%

Don’t use a lab, but test changes with emulation tools 12%

Test changes in a test/staging lab or virtual lab with emulation or simulation tools 76%

28 Juniper 21% 17% 8% 28% 9% 82%

Cisco 22% 16% 9% 26% 7% 80%

Others 18% 14% 7% 19% 7% 65%

VMware 10% 7% 4% 16% 5% 41%

Nokia 11% 7% 3% 14% 7% 41%

Fortinet 7% 7% 4% 13% 3% 35%

Huawei 12% 7% 3% 9% 3% 34%

Dell 5% 7% 1% 11% 5% 28%

HPE 3% 4% 1% 9% 3% 19%

Palo Alto 3% 3% 9% 3% 19%

Ericsson 3% 3% 1% 10% 2% 19%

Not automating In test, development, or lab environment only In production - all network places Beginning to automate beyond CLI In production - some network places

Don’t automate testing� How CSPs manage automation before We make changes directly in production, test afterward and during production also varies by level 12% of maturity. Don’t use a lab, As for pre-production set-up, the vast majority of but test changes with emulation tools Communications Service Providers test changes in a 12% test, staging, or virtual lab using simulation or emulation tools. Of the remaining 25% who don’t automate Test changes in a test/staging lab or virtual lab with testing, the chart below shows that they are mostly emulation or simulation tools 76% partial or full automators.

In production - all network places 21% 26% 53%

In production - some network places 24% 18% 59%

In test, development, or lab environment only 2% 4% 93%

Beginning to automate beyond CLI 7% 93%

Don’t automate testing - make changes directly in production and test afterward� Don’t use a lab, but test changes with emulation tools Test changes in a test/staging lab or virtual lab with emulation or simulation tools

Reviewing tools as part of change management 4% 3% 16% 4%

Tools for test simulation 6% 5% 5% 8%

Pipelining tools for continuous integration 4% 3% 12% 7% The average number of tools CSPs Frameworks or tools for testing use to 8automate% 3%network testing.9% 5%

Source code management tools for 4% 2% 4% 8% infrastructure as code

Automated hooks and testing on code commits 3% 2% 8% 5%

Event-driven frameworks 1% 1% 3%

Beginning to automate beyond CLI with basic scripting 29 In production across some network places In a test, development, or lab environment only In production in all network places Chapter 2

In production - all network places 21% 26% 53%

In production - some network places 24% 18% 59%

In test, development, or lab environment only 2% 4% 93%

Beginning to automate beyond CLI 7% 93%

To automate network testing, more than a quarter of Partial automators, in addition to reviews, also rely on: communications service providers use reviewing tools ҋ Pipelining tools for continuous integration, Rasev ipartewing of too changels as part managementof change manag ement 4% 3% ҋ Frameworks or16 tools,% 4% ҋ Automated hooks and testing on code commits. However, full automatorsTools for t emostst sim ucommonlylation use tools6% for 5% 5% 8%

test simulation and source code management tools. Partial automators likely point to how network testing Pipelining tools for continuous integration 4% 3% 12% 7% will be commonly done as network automation becomes a more and more established practice. Frameworks or tools for testing 8% 3% 9% 5%

Source code management tools for 4% 2% 4% 8% infrastructure as code The most important service reliability metric varies likely set the new standards – say application and user Automated hooks and testing on code commits 3% 2% 8% 5% some by according to the automation maturity level. experience metrics are most important. For all, MTBF

Full automators findEve ntMTTR-drive n(Mean frame wTimeorks To1 %Resolution1% 3% ) (Mean Time Between Failures) is the least important. most important. Partial automators – who again will Beginning to automate beyond CLI with basic scripting In production across some network places In a test, development, or lab environment only In production - all network places In prod21uc%tion in all network places 34% 41%

In production - some network places 30% 37% 33%

In test, development, or lab environment only 31% 34% 35%

Beginning to automate beyond CLI 29% 31% 40%

Not automating 25% 37% 37%

Mean time between failures Mean time to resolution Application and user experience metrics Other like latency and throughput

30 In production - all network places 13% 40% 7% 13% 27%

In production - some network places 2% 15% 9% 52% 2% 17%

In test, development, or lab 29% 18% 12% 24% 6% 12% environment only

Beginning to automate beyond CLI 21% 18% 18% 24% 3% 12%

Don’t know Once per month More than once per day Once per week Once per day Once every 3 months or longer Multiple times per week In production - all network places 21% 34% 41%

In production - some network places 30% 37% 33%

In test, development, or lab environment only 31% 34% 35%

Beginning to automate beyond CLI 29% 31% 40% As the chart below shows, the more a CSP network is 52% make changes at least multiple times per week. automated, the more often changes are made to the This compares to 12% of beginners and testers who Not automating 25% 37% 37% primary network service. 27% of full automators and make changes more than once a day about another 30% 17% of partial automators make changes Mmoreean ti mthane betw een failureswho make themM multipleean time to re stimesolution per week. Application and user experience metrics Other once a day, while another 20% of full automatorslike latenc yand and t hroughput

In production - all network places 13% 40% 7% 13% 27%

In production - some network places 2% 15% 9% 52% 2% 17%

In test, development, or lab 29% 18% 12% 24% 6% 12% environment only

Beginning to automate beyond CLI 21% 18% 18% 24% 3% 12%

Don’t know Once per month More than once per day Once per week Once per day Once every 3 months or longer Multiple times per week

And the more a network is automated, the less lead having it take effect in production. Compare this to time for changes is required. 14% of full automators say beginners who require much more time lead time for it takes a day or less from servicing a change request to changes.

In production - all network places 7% 7% 47% 27% 7% 7%

In production - some network places 2% 9% 11% 35% 35% 2% 7%

In test, development, or lab 6% 24% 6% 24% 29% 12% environment only

Beginning to automate beyond CLI 3% 6% 29% 29% 26% 3% 3%

Don’t know More than 3 months Between 1-7 days Less than 1 day Between 1-3 months Less than 1 hour Between 1-4 weeks

In production - all network places 20% 53% 27%

In production - some network places 2% 7% 17% 59% 13% 31

In test, development, or 6% 12% 6% 12% 65% lab environment only

Beginning to automate beyond CLI 9% 6% 12% 9% 38% 24%

Don’t know More than 3 months Between 1-7 days Less than 1 day Between 1-3 months Less than 1 hour Between 1-4 weeks In production - all network places 7% 7% 47% 27% 7% 7%

In production - some network places 2% 9% 11% 35% 35% 2% 7% Chapter 2

In test, development, or lab 6% 24% 6% 24% 29% 12% environment only

Beginning to automate beyond CLI 3% 6% 29% 29% 26% 3% 3%

It’s the same trend for the time to restoreD onservice’t know after includesMore than 27%3 mont hofs full automators and 13% of partial there’s a service incident or defect that impactsBetween users1-7 day.s automatorsLess than 1 day restore service in less than an hour. Between 1-3 months Less than 1 hour The more automated a network is, the fasterBetw eeservicen 1-4 wee isks Compare this to 65% of testers and 62% of beginners restored. 80% of full automators and 73% of partial who say it takes less than a day. automators restore service in less than a day – and this

In production - all network places 20% 53% 27%

In production - some network places 2% 7% 17% 59% 13%

In test, development, or 6% 12% 6% 12% 65% lab environment only

Beginning to automate beyond CLI 9% 6% 12% 9% 38% 24%

Don’t know More than 3 months Between 1-7 days Less than 1 day Between 1-3 months Less than 1 hour Between 1-4 weeks

The same also holds true with the frequency of of partial automators say they get trouble reports at detecting or receiving reports of service degradations or least once per day compared to 18% of testers and 24% issues. The more automated a network is, the more of beginners. frequently teams detect trouble. 34% of full and 33%

In production - all network places 13% 7% 20% 27% 7% 27%

In production - some network places 9% 7% 17% 13% 22% 13% 20%

In test, development, or lab environment only 12% 29% 6% 24% 12% 6% 12%

Beginning to automate beyond CLI 15% 3% 15% 15% 29% 6% 18%

Don’t know Every 3 months 1x/month 1x/week Multiple x/week 1x/day More than 1x/day

100% 6% 13% 20% ce i v r

e 80% s

47% n i

t 47% l 39% u

s 33% e r

60% on s t a ti h a t

eg r d ge s

n 24% a 40% 15% h c 28% 27% f 3% o

e 6% r 12% a

h 20% 6% S 3% 7% 6% 11% 9% 7% 12% 4% 6% 7% % 4% Beginning to In test, development, In production - some In production - all automate beyond CLI or lab environment network places network places only

None 1-10% 11-20% 21-30% 31-40% 41-50% 51-60% 61-100% Don’t know In production - all network places 13% 7% 20% 27% 7% 27%

In production - some network places 9% 7% 17% 13% 22% 13% 20%

In test, development, or lab environment only 12% 29% 6% 24% 12% 6% 12%

Beginning to automate beyond CLI 15% 3% 15% 15% 29% 6% 18%

Don’t know Every 3 months 1x/month 1x/week Multiple x/week 1x/day More than 1x/day

Lastly, an automated network is a more dynamic and automators and 13% of partial automators never have more reliable communications service provider network. service problems as a result of changes. Avoiding hot The more automated a CSP network is, the fewer fixes, rollbacks, forward fixes and patching saves time changes to production end up in degraded service – for the whole team. that then lead to remediation. About 20% of full

100% 6% 13% 20% ce i v r

e 80% s

47% n i

t 47% l 39% u

s 33% e r

60% on s t a ti h a t

eg r d ge s

n 24% a 40% 15% h c 28% 27% f 3% o

e 6% r 12% a

h 20% 6% S 3% 7% 6% 11% 9% 7% 12% 4% 6% 7% % 4% Beginning to In test, development, In production - some In production - all automate beyond CLI or lab environment network places network places only

None 1-10% 11-20% 21-30% 31-40% 41-50% 51-60% 61-100% Don’t know

33 Chapter 2

The more a Communications Service network are consistently above goal. 67% are above Provider uses network automation, the goal for new customers and relative market share. 47% higher the business benefit. of them who say they’re above goal for time to market for new products and 73% above goal for organizational When asked about whether they were above, at, or performance. below goal for 4 key business goals for the last year, CSPs that automate in production in all places in the Over the past year, status of the goal for...

More Customers Relative Market Share for Primary Products

67% 67% In production in all 20% In production in all 27% network places 13% network places 7% In production across 57% In production across 54% 31% 39% some network places 12% some network places 7% In a test, development, 44% In a test, development, 38% or lab environment only 50% or lab environment only 44% 6% 19% Beginning to automate 58% Beginning to automate 33% 30% beyond CLI beyond CLI 55% 12% 7%

49% 51% Not automating 29% Not automating 37% 23% 11% 0% 20% 40% 60% 80% 100% 0% 20% 40% 60% 80% 100%

Below goal Met goal Above goal Below goal Met goal Above goal

Time to Market for New Products Organizational Performance

73% In production in all 47% In production in all 40% 20% network places 13% network places 7% In production across 41% In production across 68% 25% 43% some network places some network places 16% 7% In a test, development, 31% In a test, development, 50% 25% 31% or lab environment only 44% or lab environment only 19%

Beginning to automate 30% Beginning to automate 47% 45% 44% beyond CLI 16% beyond CLI 9% 31% 61% Not automating 42% Not automating 31% 28% 8% 0% 20% 40% 60% 80% 100% 0% 20% 40% 60% 80% 100%

Below goal Met goal Above goal Below goal Met goal Above goal

34 Summing up: Communications Service Donal’s Takeaways on Communications Providers that use network automation Service Providers have improved network operations, Automation is about increasing speed and reliability reliability for better business outcomes. while facilitating action at scale. It is a force multiplier CSPs are increasingly embracing network automation. where traditional drivers such as cost reduction and However, there are three main conclusions. First, as improved quality can coexist happily. When we consider underlying technologies themselves mature, processes the underlying promises of technology, the drive for and practices that automators use are shifting. While efficiency and efficacy stand out. However, there is an automators at all stages might use the same network innate fear of losing control and cognitive dissonance vendors, they don’t use the same exact same tools tied with the rise of network automation as we observe before and during production – suggesting what “software eating the world”. This feeling stems in part partial automators do today will be the new standard. from a ubiquitous sense of future shock and is Second, the more automated the network, the more underpinned by a personal fear of obsolescence. It also network operations and reliability improve. Third, carries with it the recognition of a skills gap, one that those improvements in NetOps (Network Operations) must be overcome before attempting the next and reliability translate to business advantage. challenge. But what is preventing many of us from getting started? Well, understandably, some of the primary human challenges related to the adoption of automation involve finding the time to learn and train, and a deep apprehension related to making mistakes in production. Ironically these are challenges that a mature automation practice solves, so it should be no surprise that those who embrace automation report higher job satisfaction and exceed their performance goals.

In the last five years of running Network Operator Group events and presentations, I’ve observed a shift towards ubiquitous automation, irrespective of vertical or horizontal. The focus is not just on the traditional places in network that require automation by necessity of scale or volume, but also with many of their adjacent and dependent workflows. This includes automating multiple aspects of service delivery and assurance, general business process optimization, and sometimes even automating vendor TAC(Technical Assistance Centre) engagement.

35 Chapter 2

As the volume, scope, and scale of digital assets (Business To Business) and communications provider increase, each asset and platform comes with its own cloud space) do not programmatically consume inescapable overheads and externalities. Measuring, services. Many customers may utilize self-serve web monitoring, and managing these are table stakes, yet portals or make voice calls to human agents who then as scale and complexity grow, so too does the need for initiate upstream interactions with internally better overall observability and controllability. The automated services. The service request trigger is more digital state and associated dependencies we manual and often comes with asynchronous delivery deploy, the greater the need for better telemetry and expectations. This would seem to lead to CSP’s intelligence to allow us to make evidence-based network automation efforts being driven by their scale, decisions, and take (or automate) decisive actions. as an operational necessity, rather than the customer consumption model and lead time expectations of CSPs primarily sell network services with some individual or business customers. additional OTT(Over-The-Top) services. Delivery of these network services are predicated on the Yet one of the lowest risk, most effective, and highest deployment or delivery of physical entities such as a return paths for a more mature automation practice SIM (Subscriber Identity Module) or CPE (Customer revolves around automating quality assurance and Premises Equipment). These physical constraints mean testing activities, especially when working at scale. that unless a subscriber is already within their This is to be expected as it also creates fertile ground managed footprint (and has satisfied the correct and cumulatively beneficial conditions for further endpoint requirements), they are subject to some automation. Automation types involving read-only naturally asynchronous steps or processes to complete workflows for activities like assurance and monitoring service activation. When compared to the service increase overall observability, while helping to build model for cloud providers, with service boundaries confidence as they result in “safe” measurable focused on API(Application Programming Interface) outcomes (ones that support continuous first, we begin to think differently about how a service improvement). The greater the potential for a surface or consumption model affects the need for destructive operation (and the less capable and automation. Automation may begin ‘lumpy’ in many confident an operator is at completing a timely CSP scenarios but closed-loop end-to-end service roll-back), the more likely they will continue with automation is often driven by the expectations of manual, time-consuming, and low-value tasks. There’s consumers. Are CSP service consumers humans or a gradual and natural evolution of stair-stepping up machine agents, and what speed, type, or interface is through automation confidence levels as personal used for service fulfillment? skills and risk tolerance evolve. The exception to this stair-stepping is when your whole service stack is Internally, albeit Telcos and cable MSO’s may make expected to be consumed programmatically, extensive use of API’s and automated configuration synchronously, and predominantly by machine agents management for their own footprints, their external from the beginning. service consumers (with some exceptions in the B2B

Chapter 3

Chapter 3: The 2020 Cloud Provider State of Network Automation

This chapter showcases the state of network The automation maturity scale has 5 levels, ranging automation for Cloud Providers. Specifically, after you from not automating at all to being in production understand respondents, you’ll learn by network across all places in the network. The key below has the automation maturity: short names used throughout the report and how they are defined. ҋ where they automate,

ҋ tools, Key: Short names for groups along the maturity scale ҋ vendors, Full automators = in production in all network places Partial automators = in production in some network ҋ processes for network automation before and places during production, and Testers = in a test, development or lab environment only ҋ how well Cloud Providers’ meet 4 key business Beginners = beginning to automate beyond CLI with goals. basic scripting Non-automators = Not automating

38 Cloud Providers lead the way with Since Cloud Providers lead in network automation network automation. adoption, they show that experience helps conquer fear of making a mistake in production. Full automators are Our sample includes 46 Cloud Providers and 65% are less afraid than less mature automators. from North America. It’s important to know that it’s fairly small sample of a varied group. A cloud provider in our research could be a low-code platform, a hosted cloud infrastructure or a public cloud provider. But what they all have in common is the imperative to operate efficiently, so they adopt automation more than their networking colleagues.

Since Cloud Providers have more mature automators than Communications Service Providers or Enterprises, it means that remaining respondents are spread among testers, beginners, and non-automators. It’s limiting because the sample of testers ended up being particularly small. While we include this group in results, we don’t make any conclusions about Cloud Providers who are testers.

In production - all network places 45% 18% 27% 9%

In production - some network places 33% 25% 25% 17%

In test, development, or lab only 50% 50%

Beginning to automate beyond CLI 36% 18% 9% 36%

Not a challenge Challenge my organization faces

Challenge I face as individual Both individual and organizational challenge

Data center 13% 2% 24% 20% 59%

Public cloud 2% 2% 13% 17%

SP provider WAN, core, and backbone 4% 4% 4% 13%

Cloud native or app cluster networking 4% 4% 4% 13% 39 Campus or large site 4% 9% 13%

Enterprise WAN 7% 4% 11%

Branch & small site, inc SD-WAN 2% 4% 4% 11%

Wireless 4% 7% 11%

SP subscriber edge and aggregation 7% 2% 2% 11%

SP mobile infrastructure 2% 9% 14%

SP cloud, telco cloud, NFV cloud 4% 4% 9%

SP access 4% 2% 7%

Edge compute cloud 2% 2% 2% 7%

SP packet optical 2% 2% 7%

SP metro 2% 2%

Beginning to automate beyond CLI In test, development, or lab environment only

In production - some network places In production - all network places Chapter 3 In production - all network places 45% 18% 27% 9%

In production - some network places 33% 25% 25% 17%

In test, development, or lab only 50% 50% Cloud Providers mostly automate second at 9%, is automation of the public cloud. From Beginning to automate beyond CLI 36% 18% 9% 36% data centers. there, Cloud Providers are automating a little bit of Not a challengeeverywhere. ThereChallenge is onemy organization place they faces stand out – when Challenge I face as individual Both individual and organizational challenge Overwhelmingly, Cloud Providers first tackle date compared to their communications service provider center automation. It is top among all groups along the colleagues – with their level of automation of the edge network automation maturity continuum, so keep this compute cloud. in mind as you review all results. Next, at a distant

Data center 13% 2% 24% 20% 59%

Public cloud 2% 2% 13% 17%

SP provider WAN, core, and backbone 4% 4% 4% 13%

Cloud native or app cluster networking 4% 4% 4% 13%

Campus or large site 4% 9% 13%

Enterprise WAN 7% 4% 11%

Branch & small site, inc SD-WAN 2% 4% 4% 11%

Wireless 4% 7% 11%

SP subscriber edge and aggregation 7% 2% 2% 11%

SP mobile infrastructure 2% 9% 14%

SP cloud, telco cloud, NFV cloud 4% 4% 9%

SP access 4% 2% 7%

Edge compute cloud 2% 2% 2% 7%

SP packet optical 2% 2% 7%

SP metro 2% 2%

Beginning to automate beyond CLI In test, development, or lab environment only

In production - some network places In production - all network places

40 Cloud Providers mainly use 3 different collection at 53%. What stands out is that full tools to automate network deployments, automators use everything. They’re just as likely to use changes, and management. Infrastructure as Code(IaC) templating, modeling tools and on-device automation. This isn’t true of partial Configuration management tools tops the list at 67%, automators who primarily use the top three: next it’s APIs at the virtual or physical device level at configuration tools, APIs on the device level, and 58% and customer-monitoring tools and telemetry customer monitoring and telemetry.

Conﬁguration management tools 17% 3% 25% 22%

APIs at the virtual or physical device level 14% 3% 22% 19%

Customer-monitoring tools and telemetry collection 19% 17% 17%

Infrastructure as code templating and modeling tools 6% 3% 11% 19%

Software-deﬁnes or intent-driven networking products that include a centralized controller 11% 6% 8% 11%

On-device automation 3% 14% 19%

Container-based deployment model for our network 3%3% 14% 11% automation

APIs at the SDN controlloer or management plane level 6% 6% 6%

Other 3% 6%

Beginning to automate beyond CLI

In test, development, or lab environment only

In production - some network places In production - all network places

The average number of tools a cloud provider uses to automate network testing, making them the segment that uses the most tools to get the job done.

41 Chapter 3

Most Cloud Providers tend to use a smaller set of network vendors.

Juniper 18% 13% 2% 22% 13% 69%

Cisco 11% 16% 4% 20% 13% 64%

VMware 11% 11% 2% 11% 9% 44%

Others 4% 4% 2% 11% 20% 42%

Arista 2% 7% 2% 13% 4% 29%

HPE 2% 9% 2% 7% 2% 22%

Palo Alto 7% 2% 7% 4% 20%

Fortinet 4% 7% 7% 2% 20%

Not automating Huawei 4% 2% 4% 7% 18% Beginning to automate beyond CLI

Dell 2% 9% 7% 18% In test, development, or lab environment only

In production - some network places Cumulus 2% 2% 2% 7% 2% 16% In production - all network places

Nearly 70% of cloud providers rely on

Other Don’t automate Juniper, making3% it thetesting - topmake vendor production and test afterward 14%

Don’t use a Test changes in lab, but test a test/staging changes with lab or virtual emulation tools lab with 8% emulation or simulation tools 75%

42 Juniper 18% 13% 2% 22% 13% 69%

Cisco 11% 16% 4% 20% 13% 64%

VMware 11% 11% 2% 11% 9% 44%

Others 4% 4% 2% 11% 20% 42%

Arista 2% 7% 2% 13% 4% 29%

HPE 2% 9% 2% 7% 2% 22%

Palo Alto 7% 2% 7% 4% 20%

Fortinet 4% 7% 7% 2% 20%

Not automating Huawei 4% 2% 4% 7% 18% Beginning to automate beyond CLI

Dell 2% 9% 7% 18% In test, development, or lab environment only

In production - some network places Cumulus 2% 2% 2% 7% 2% 16% In production - all network places

How Cloud Providers manage In the pre-production setup to test automation for automation before and during production making changes, just like communication service varies by automation maturity stage. providers, 75% of Cloud Providers test changes in a test/staging lab or virtual lab with emulation or simulation tools.

Other Don’t automate 3% testing - make production and test afterward 14%

Don’t use a Test changes in lab, but test a test/staging changes with lab or virtual emulation tools lab with 8% emulation or simulation tools 75%

But unlike those Communications Service Providers, datacenter nature. As a utility compute provider their they tend to not automate testing, particularly the less fixed underlay networks rarely change whereas their mature automators. Instead, they make changes virtual overlay networks can withstand churn and be directly in production and test them afterwards. This rolled forward or backward in the case of a breaking may be due to their primarily stub based network and change without losing management capabilities.

In production - all network places 7% 13% 78%

In production - some network places 14% 10% 75%

In test, development, or lab environment only 9% 16% 75%

Beginning to automate beyond CLI 14% 26% 59%

Other

Reviewing tools as part of change management 8% 8% 19%

Tools for test simulation 8% 3% 8% 11%

Automated hooks and testing on code commits 3% 3% 11% 14%

Pipelining tools for continuous integration 3% 6% 17%

Source code management tools for infrastructure as code 3% 8% 11%

Frameworks or tools for testing 6% 14%

Event-driven frameworks 11%

Beginning to automate beyond CLI with basic scripting

In production across some network places

In a test, development, or lab environment only In production in all network places In production - all network places 7% 13% 78%

In production - some network places 14% 10% 75%

In test, development, or lab environment only 9% 16% 75%

Chapter 3 Beginning to automate beyond CLI 14% 26% 59%

Other

Don’t automate testing - make changes directly in production and test afterward. Don’t use a lab, but test changes with emulation tools Test changes in a test/staging lab or virtual lab with emulation or simulation tools To automate testing, Cloud Providers are like both they’re far more likely to use automated hooks and Enterprises and Communications Service Providers testing on code commits. In addition, more mature and use reviewing tools as part of change management automators are nearly as likely to use automated most. But Cloud Providers differ from them that pipeline tools for continuous integration.

Reviewing tools as part of change management 8% 8% 19%

Tools for test simulation 8% 3% 8% 11%

Automated hooks and testing on code commits 3% 3% 11% 14%

Pipelining tools for continuous integration 3% 6% 17%

Source code management tools for infrastructure as code 3% 8% 11%

Frameworks or tools for testing 6% 14%

Event-driven frameworks 11%

Beginning to automate beyond CLI with basic scripting

In production across some network places

In a test, development, or lab environment only In production in all network places

When it comes to the service reliability metrics, the For non-automators, MTBF (Mean Time Between most important ones are application and user Failures) is most important and for all Cloud Providers, experience metrics like latency and throughput. This is MTTR (Mean Time To Resolution) is least important. true for beginners, partial, and full automators alike.

In production - all network places 28% 30% 42%

In production - some network places 29% 27% 44%

In test, development, or lab environment only 31% 55% 14%

Beginning to automate beyond CLI 26% 35% 39%

Not automating 30% 41% 29%

Mean time to resolution Mean time between failures Application and user experience metrics like latency and throughput

In production - all network places 9% 55% 9% 9% 18%

In production - some network places 8% 17% 58% 8% 8%

In test, development, or lab environment only 50% 50%

Beginning to automate beyond CLI 36% 36% 18% 9%

Once every 3 months or longer Once per month Multiple times per week Once per week Once per day More than once per day In production - all network places 28% 30% 42%

In production - some network places 29% 27% 44%

In test, development, or lab environment only 31% 55% 14%

Just as we sawBeginning with Communications to automate beyond CLI Service 26% delivery model35% and consumption39% by machine agents Providers, the more a network is automated, the more (via APIs) mandates tightly-coupled automation Not automating 30% 41% 29% often changes are made to the primary network throughout their stacks. Once a certain level of service. 18% of full automators make multiple changes automation coverage, scale, and maturity is achieved, Mean time to resolution per day and another 8% make them daily. PartialMean time between failuresit would suggest that feature velocity and aspects of automators and beginners make changes lessApplication often, and user experiencelifecycle metrics management like latency and accelerate throughput . though. The nature of many Cloud Providers service

In production - all network places 9% 55% 9% 9% 18%

In production - some network places 8% 17% 58% 8% 8%

In test, development, or lab environment only 50% 50%

Beginning to automate beyond CLI 36% 36% 18% 9%

Once every 3 months or longer Once per month Multiple times per week Once per week Once per day More than once per day

Cloud provider networks that are more automated Another 55% get it done within a week. Compare this require less lead time for changes. 18% of full to beginners who skew toward longer time intervals – automators say it takes less than a day from servicing with not one reporting the ability to service change a change request to having it take effect in production. requests on the same day.

In production - all network places 9% 18% 55% 18%

In production - some network places 17% 25% 25% 25% 8%

In test, development, or lab environment only 50% 50%

Beginning to automate beyond CLI 9% 36% 55%

Between 1-3 months Between 1-4 weeks Between 1-7 days

Less than 1 day Less than 1 hour

In production - all network places 9% 18% 36% 36%

45 In production - some network places 8% 8% 8% 50% 25%

In test, development, or lab environment only 100%

Beginning to automate beyond CLI 9% 18% 27% 27% 18%

Don’t know More than 3 months Between 1-3 months Between 1-4 weeks Between 1 -7 days Less than 1 day Less than 1 hour Chapter 3

In production - all network places 9% 18% 55% 18%

In production - some network places 17% 25% 25% 25% 8%

For CloudIn test, Providers,development, uptimeor lab environment is everything; only no service 50% is, the faster service is restored.50% 72% of full equals no revenue and unhappy customers, so it’s automators and 75% of partial automators say it takes Beginning to automate beyond CLI 9% 36% 55% crucial to restore service as fast as possible. So how less than a day. Compare this to beginners; only 45% does network automation impact time to Betweenrestore 1-3 months of themBetween say 1-4 itweeks takes lessBetween than 1-7 a days day, while another 27% service after an incident or a defect that impactsLess than 1 day say Lessit takes than 1 hourbetween 1-7 days. users? The more automated a cloud provider network

In production - all network places 9% 18% 36% 36%

In production - some network places 8% 8% 8% 50% 25%

In test, development, or lab environment only 100%

Beginning to automate beyond CLI 9% 18% 27% 27% 18%

Don’t know More than 3 months Between 1-3 months Between 1-4 weeks Between 1 -7 days Less than 1 day Less than 1 hour

Regarding the frequency of detecting or receiving potential for more frequent and observable breaches reports of service degradations or issues, 18% of full of a broader set of SLOs (Service Level Objectives). In automators say they get trouble reports at least once other words, the more you automate, the more you per day compared to 9% of beginners. With greater measure, and the more likely you are to detect trouble automation coverage and monitoring, comes the in the first place.

In production - all network places 27% 9% 36% 9% 9% 9%

In production - some network places 8% 8% 25% 50% 8%

In test, development, or lab environment only 50% 50%

Beginning to automate beyond CLI 9% 18% 27% 36% 9%

Don't know Once every 3 months or longer 1x/month 1x/week

Multiple x/week 1x/day More than 1x/day

46 100% 9% 8% 27% 80% 27% 50% 50% 60% 9% 45% 40% 27% 17% 50% 20% 8% service degradations 18% 18% 8% 9% 9% Share of changes that result in % 8%

Beginning to In test, development, In production - some In production - all automate beyond CLI or lab environment network places network places only

None 1-10% 11-20% 21-30% 31-40% 41-50% 50% or more Lastly, an automated network is a more dynamic and This compares to beginners where a higher percentage In production - all network places 27% 9% 36% 9% 9% 9% more reliable cloud provider network. The more of their changes in production lead to service automated it is, the fewer changes to production end degradation. And only 9% have no problems as a result In production - some network places 8% 8% 25% 50% 8% up in degraded service – that then lead to of changes. In test, development, or lab environment remediation efforts. Aboutonly 27% of full automators50% 50% and 8% of partial automators never have service Beginning to automate beyond CLI problems as a result of changes9%. This means18% no need 27% 36% 9%

for hot fixes, rollbacks, forwardDon't fixes know and patchingOnce every as3 months or longer 1x/month 1x/week a result of production changesMultiple to the x/week network.1x/day Next More than 1x/day about 45% of full automators and 50% of partial automators say less than 10% of changes create problems that need remediations.

100% 9% 8% 27% 80% 27% 50% 50% 60% 9% 45% 40% 27% 17% 50% 20% 8% service degradations 18% 18% 8% 9% 9% Share of changes that result in % 8%

Beginning to In test, development, In production - some In production - all automate beyond CLI or lab environment network places network places only

None 1-10% 11-20% 21-30% 31-40% 41-50% 50% or more

47 Chapter 3

Cloud Providers that use network ҋ 60% are above goals for time to market for new automation crush their business goals. products, and ҋ 91% are above goal for organizational performance. The more network automation is used, the higher the business benefit. When asked about whether they Let’s quickly compare to non-automating Cloud were above, at, or below for 4 key business goals in Providers. They are more likely to be at or below goal. the last year, full automators met or exceed For example:

expectations. ҋ 20% are below goal for more customers, for relative

For example, among full automators: market share for primary products, and for time to market for new products, and ҋ 90% are above goal for more customers, ҋ 11% are below goal for organizational performance. ҋ 70% are above goal for relative market share for

primary products, Over the past year, the status of the goal for...

More Customers Relative Market Share for Primary Products

70% In production in all 90% In production in all 20% 10% network places network places 10% In production across 58% In production across 42% some network places 25% some network places 58% 17%

In a test, development, 50% In a test, development, 50% or lab environment only 50% or lab environment only 50%

Beginning to automate 36% Beginning to automate 18% beyond CLI with basic 27% beyond CLI with basic 73% 36% 9% scripting scripting 30% 30% Not automating 50% Not automating 50% 20% 20% 0% 20% 40% 60% 80% 100% 0% 20% 40% 60% 80% 100%

Below goal Met goal Above goal Below goal Met goal Above goal

Time to Market for New Products Organizational Performance

In production in all 60% In production in all 91% network places 40% network places 9%

45% In production across In production across 58% 45% some network places some network places 42% 9% In a test, development, In a test, development, 100% 100% or lab environment only or lab environment only

27% Beginning to automate 27% Beginning to automate 36% beyond CLI with basic 64% beyond CLI with basic 20% 9% scripting scripting 40% 33% Not automating 40% Not automating 56% 20% 11% 0% 20% 40% 60% 80% 100% 0% 20% 40% 60% 80% 100%

Below goal Met goal Above goal Below goal Met goal Above goal

48 Summing up: Communications Service Donal’s Takeaways on Cloud Providers Providers that use network automation Managing change is a cornerstone of building and have improved network operations, operating technology. Rather than let the fear of reliability for better business outcomes. change ossify an organization or its culture, optimizing Cloud Providers are quickly automating their networks, for reliable, resilient, and rapid changes result in particularly in the data center and public cloud, more increased efficiency and agility. Mature automation than Communications Service Providers and practices lend themselves to not just better and faster Enterprises. There are a few noteworthy conclusions. outcomes but also decreased risk. First, they use a broader set of tools to automate When network operators highlight the fear of making testing, too. Second,application and user experience a mistake in production as one of the predominant metrics like latency and throughput is by far the most challenges related to automation adoption – concepts important service reliability metric. Last, like of risk, impact, and culture come to the fore. For Communications Service Providers, the more learning and development to occur, there needs to be automated the network, the more network operations psychological safety in teams [Ref: Project Aristotle]. and reliability improve, which translates to great And to fail well, one must quickly identify problems business advantage over Cloud Providers that use and errors, limit their potential blast radius, and then lesser degrees of automation. remediate or rapidly roll-back. This entails a high degree of observability and controllability. Often, with older equipment it’s hard to automate, instrument, and operate at scale, so there’s an implicit disincentive to automate or move fast and break (but preferably fix) things. If mistakes in production cannot be rectified easily, then feature velocity, innovation, and agility stagnate – culture begins to ossify, and non-virtuous cycles take hold. As digital services proliferate, the focus on and desire for ease of integration and introspectability heighten.

49 Chapter 3

Cloud providers rank reliability as their top business Once a device or service provides a robust API with driver for automation (with efficiency a close second). good coverage, it becomes a somewhat frictionless As per the previous CSP segment, cloud provider way to explore automation and to test integration networks are tightly coupled to revenue generation. possibilities with existing platforms or stacks. The use Cloud provider’s downstream customers also build of containers for rapid commissioning, prototyping, their own revenue-generating products and services and safer experimentation means that early adopters on top of these clouds. These customers also consume lean towards API first products and services. They are cloud services programmatically, which inevitably seen to enable faster and more controllable leads to them independently instrumenting the cloud automation outcomes. Skills and concepts relating to provider’s service performance. When your customers containers and APIs (especially RESTful ones) are are SaaS (Software as a Service) businesses who are themselves transferable to other platforms and laser-focused on their own user experience metrics scenarios. This creates immediate and cumulative and can easily instrument them, a symbiotic and value with well-defined learning paths. One of the amplified form of monitoring occurs. Tighter and faster paradigm shifts that’s less obvious when approaching feedback loops develop around service expectations, automation, is not to apply network engineering measurements, and resultant optimizations. learnings to software principles, but to apply software engineering principles to network engineering. This Additionally, and dependent upon a cloud customer’s shift means embracing automation not as a toolchain scale and architecture, provisioning and switching but as a pattern language and process ontology that costs are lower than that for the aforementioned focuses on how actors and agents achieve goals by communications service providers who require the moving through different states. There are indeed deployment of physical devices. When all friction has some quick wins, safe paths, and low hanging fruit, but been removed from service provisioning through to a more abstract and holistic view leads to the most service consumption using APIs, there’s an profound gains. understanding that automation is required to fulfill service requests end-to-end (be they synchronous Note: Humans are still required to design, implement, calls or asynchronous background jobs). and evolve these automation workflows, but there is help at hand with new breeds of AI (Artificial Intelligence) assistants that can augment or trigger automation workflows using the patterns they spot in the compounding complexity.

Chapter 4

Chapter 4: The Road to Greater Network Automation Maturity

Regardless if you’re an Enterprise, Cloud Provider, or a More mature network automators build Communications Service Provider, the path to achieving new skills for new responsibilities. full network automation is a function of building the right individual and team skills, fostering a culture of All network teams have the same network architecture automation, and growing a high-performing team. and security-related responsibilities. More mature automators are also more likely to have network In this final section, we explore each one by automation architectures, frameworks and tools automation maturity. integration, as well as network automation software engineering. And this means since they have reduced needs, they don’t do network monitoring, provisioning and on-call incident response at the same rates.

52 Beginning to In test, automate development, In production beyond CLI or lab - some In production Not with basic environment network - all network Most important responsibilities automating scripting only places places Overall

Network architecture 16.0% 17.3% 19.3% 18.1% 16.4% 17.3%

Network monitoring 15.3% 13.4% 11.1% 9.1% 9.7% 12.2%

Information or network security 11.8% 12.9% 12.7% 9.1% 9.5% 11.2%

Network automation architecture, frameworks, and 7.1% 8.9% 8.9% 14.5% 15.3% 10.5% tool integration

Network provisioning 12.7% 10.5% 8.9% 9.8% 7.8% 10.4%

Documentation 8.0% 9.8% 9.1% 6.7% 9.6% 8.5%

Network automation software 3.2% 7.0% 8.6% 11.3% 13.2% 7.9% engineering

On-call/incident response 9.5% 6.0% 5.8% 5.9% 4.7% 6.7%

Project or product management 6.9% 3.5% 3.0% 4.9% 4.5% 4.8%

People management 4.2% 4.1% 3.9% 4.7% 4.9% 4.4%

Requirements analysis 3.1% 4.4% 4.7% 2.9% 1.9% 3.4%

Testing 1.0% 1.6% 3.4% 2.8% 2.2% 2.0%

Other 1.2% 0.7% 0.4% 0.2% 0.5% 0.7%

53 Chapter 4

More mature automators tend to have larger IT teams, span the range of career seniority levels, and know the importance of developer skills.

100% 6% 2% 7% 3% 8% 14% 2% 5% 5% 8% 12% 8% 80% 12% 6% 15% 21% 15% e

z 28% i

s 60% 16% 28% 19% 24% 20% ea m 40%

t 20%

20%

T 47% I 20% 35% 25% 28% 20% 0% 7% 4% 3% 5% 6% Not automating Beginning to automate In test, development, or In production - some In production - all beyond CLI lab environment only network places network places

Don’t know Less than 10 10 to 19 20-99 100-499 500-999 1,000+

100% 17% 25% 21% 26% 24%

it y 80% r o i 34% n 60% 35% 25% 29%

e 36% s

40% 37% 31% ar ee r 27% 31% 42% C 20%

16% 0% 13% 13% 12% 7% Not automating Beginning to automate In test, development, or In production - some In production - all beyond CLI lab environment only network places network places

Junior (less than 5 yrs) Mid-career (5-10 yrs) Senior (11-20 yrs) Very senior (20 yrs+)

Larger IT teams automate more, likely due to needs for higher service reliability, lower human- error tolerance, and time to learn on the job.

…but career seniority is not highly related to automation maturity.

54 Beginning to In test, automate beyond development, In production Top 3 trends that inspire CLI with basic or lab - some network In production - all you to improve Not automating scripting environment only places network places

Network Reliability 29% 27% 21% 28% 27% Engineering (NRE/SRE)

DevOps 21% 22% 27% 25% 22%

DevNetOps 21% 20% 22% 20% 20%

NetOps 2.0 16% 20% 16% 13% 16%

Developer 9% 9% 12% 14% 14%

Other 4% 2% 1% 1% 1%

In 2019, respondents drew inspiration to improve from DevOps, but this year Network Reliability Engineering (NRE/SRE) takes the top spot. And mature automators now get their inspiration from developers.

55 Chapter 4

More mature automators tend to have larger IT teams, span the range of career seniority levels, and know the importance of developer skills.

87% 81% 75% 73% 75%

re e 69% 70% g

a 65% 64% 64% 62% 61% y 60% 53% ong l

r 87% 47% 81% 75% 75%

ree/s t 73% re e g 69% 70% g a

a 65% 64% 64%

% 62% 61% y 60% 53% ong l

r 47% ree/s t

g Have service level obectives Have service levels that are meaured and Have good visibility into errors, a reported with transparency to stakeholders outages, and issues %

Not automating Beginning to automate beyond CLI In test, development, or lab environment only In production - some network places In production - all network places Have service level obectives Have service levels that are meaured and Have good visibility into errors, reported with transparency to stakeholders outages, and issues

Not automating Beginning to automate beyond CLI In test, development, or lab environment only In production - some network places In production - all network places

More mature automators invest72% in automated network 71operational% skills, processes 68% 68% 64% 64% and technology – and less on turnkey automation. 61% 55% 53% 53% 52% 50% 49% 51% 48% 46% 44% 42% 40% 42% 40% 36% 36% 36% 36% 72% 71% 68% 68% 64% 64% 61% 55% 53% 53% 15% 51% 12% 52% 50% 48% 49% 9% 9% 46% 7% 44% 42% 40% 42% 40% 36% 36% 36% 36% Hire new talent to Invest in training staﬀ Dedicate part of Rely on vendor Rely on custom and Rely on turnkey supplement team with with new network team to automating professional service contextual automation automation by using more automation and automation skills network operations to implement for operation15al% needs vendor products that software engineering automated NetOps 12% 9% 9% require no skills processes 7% customization Hire new talent to Invest in training staﬀ Dedicate part of Rely on vendor Rely on custom and Rely on turnkey Not automating Beginning to automate beyond CLI In production - some network places supplement team with with new network team to automating professional service contextual automation automation by using more automaItion tens ta, nddevelopmaeuntto, mora ltiabo nen svkiriollnsment onelytwork Ionp perroadtiucotinosn - all netwtoo rikm pplalecesment for operational needs vendor products that software engineering automated NetOps require no skills processes customization

Not automating Beginning to automate beyond CLI In production - some network places

In test, development, or lab environment only In production - all network places

56 More mature automators invest in a culture of continuous improvement.

In production - all network places 90%

In production - some network places 74%

In test, development, or lab environment only 62%

Beginning to automate beyond CLI 67%

Not automating 58%

% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%

% agree/strongly agree

We have culture of continuous improvement where opportunities for improvement are valued and acted on

84% 78% 77% 76% 73% 71% 73% 68% 67% 68% 65% re e Full automators – as opposed to the both non-

g 61% 60% 60% 60% 59% 60% a

57% y

46% 47% ong l

r automators and less mature ones – consistently ree/s t g

a report that they have defined service level

% goals, a way to measure and report them as well I have the tools and resources My ob makes good use of my I regularly reach a high level I am satisﬁed with the work I do asto d ogood my ob well visibilityskills a ndinto abilities networkof prod uproblems.ctivity

Not automating Beginning to automate beyond CLI In test, development, or lab environment only In production - some network places In production - all network places

57 In production - all network places 90%

In production - some network places 74%

In test, development, or lab environment only 62%

Beginning to automate beyond CLI 67%

Not automating 58% Chapter 4 % 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%

% agree/strongly agree

We have culture of continuous improvement where opportunities for improvement are valued and acted on

More mature network automators build more job satisfaction and a more enriching workplace.

84% 78% 77% 76% 73% 71% 73% 68% 67% 68% 65% re e

g 61% 60% 60% 60% 59% 60% a

57% y

46% 47% ong l r ree/s t g a

I have the tools and resources My ob makes good use of my I regularly reach a high level I am satisﬁed with the work I do to do my ob well skills and abilities of productivity

Not automating Beginning to automate beyond CLI In test, development, or lab environment only In production - some network places In production - all network places

Full automators agree or strongly agree much more than non-automators that they have what they need to do the job well and get to use their skills for higher productivity and job satisfaction.

58 Most importantly, more mature network automators build teams that exceed goals for security and network quality, operational efficiency, and customer satisfaction.

For all 4 of last year’s team goals, full automators exceed expectations for customer or stakeholders – were much more likely than non-automators to their users. Thus, more mature automators provide a perform at or above goals for operational efficiency, higher level of application and user experience, so IT as well as security and network product or service is true partner with the business to contribute to its quality. Such higher performance enabled network overall success. teams reach the ultimate goal of the IT team: meet or

Security Product or Service uality Network Product or Service uality

70% 77% In production in all 28% In production in all 22% network places 3% network places 1% In production - 59% In production - 66% 35% 28% some network places 6% some network places 6% In a test, development, 47% In a test, development, 58% 41% 29% or lab environment only 12% or lab environment only 13%

53% 60% Beginning to automate 35% Beginning to automate 29% beyond CLI 12% beyond CLI 11% 47% 57% Not automating 40% Not automating 34% 13% 9% 0% 20% 40% 60% 80% 100% 0% 20% 40% 60% 80% 100%

Below goal Met goal Above goal Below goal Met goal Above goal

Operational Eﬃciency Customer or Stakeholder Satisfaction

63% In production in all In production in all 68% 33% 28% network places 4% network places 4% In production across 54% In production across 64% 32% 29% some network places 13% some network places 7% In a test, development, 49% In a test, development, 61% 34% or lab environment only or lab environment only 27% 17% 12% 47% 58% Beginning to automate 34% Beginning to automate 36% beyond CLI 19% beyond CLI 7% 45% 53% Not automating 37% Not automating 32% 18% 15% 0% 20% 40% 60% 80% 100% 0% 20% 40% 60% 80% 100%

Below goal Met goal Above goal Below goal Met goal Above goal

59 Chapter 4

Donal on Reaching for Greater Network move faster (and more reliably). Services evolve more Automation quickly due to increased feature velocity and any resultant bugs, incidents, or problems are squashed Automation has a long historical arc and its trajectory evermore rapidly along the way. will continue to stretch far into the future. The most interesting aspect in this report for me is the challenge Removing the blockers and challenges to automation of how to move from the innate human fear of making is non-trivial, but some are easier than others. Culture mistakes, to a culture of psychological safety that itself is an amorphous entity, a distributed network supports continuous improvement. The real business operating system with shared states and feedback benefits of automation are undeniable but unlocking loops fed by everyone. By providing the time and an individual or team so they can accelerate their targeted training for individuals and teams to up-skill learning and have a greater impact through automation on automation, especially in low-risk and frictionless is key. environments, organizations can reap the rewards.

Overall, the more a network is automated, the more An initial goal of greater observability, both pre and changes that are made to the primary network service. post network changes, can increase your situational This speaks to a newfound velocity and agility that awareness and provide a safe stepping stone on the correlates with an organization’s automation maturity next hop of your automation journey. In this marathon, level. Once a tipping point is reached, there’s an there are very few shortcuts. intrinsic organizational confidence and capability to

Appendix

Appendix: Demographics and Methodology

A mix of segments and organizations

CSP (n=150), 23% Cloud provider Enterprise (n=46), (n=449), 70% 7%

CSP Cloud provider Enterprise (n=150) (n=46) (n=449)

10,000+ 5,000 to 9,999 2,500 to 4,999 1,500 to 2,499 500 to 1,499 250 to 499 Less than 250

A mix of levels, skills used on the job, and regions

Asia- Paciﬁc, Team 18% Manager, 23% Executive Technology, 31% North Other, America, EMEA, 6% 54% 25% Individual Contributor, 40%

LATAM, 3% 97% 98% 95%

70% 73% 60%

31% 30% 31% 25% 26% 22% 15% 15% 14%

CSP (n=150) Cloud provider (n=46) Enterprise (n=449)

Network-related tasks Security-related tasks Apps and SW Developer tasks Sys Admin-related Non-IT related

Methodology: The sample of 645 respondents was Juniper customers and prospects using its social collected via a web survey from February 24 to March media, email and community channels. 24. 2020. Respondents were recruited using internal

62 THE AUTOMATION JOURNEY

The challenge lies not only in knowing where to go, but how to get there.

Automation has become imperative to modern network operations. You need it within the products you use to build your network to make it more autonomous. It’s also critical to enabling reliability in your network operations processes. But not everyone knows how to get started with automation, how to set long- and short-term goals for achieving it, and how to measure success. Getting there certainly raises technical challenges that organizations must address. Equally important, however, are changes in processes, skill sets, and culture. All three areas—people, process and technology—must evolve in parallel to accomplish the ultimate automation goal, a more reliable network infrastructure, and such secondary goals as speed, efficiency, and agility. Download and participate in future SoNAR research on Juniper Networks juniper.net/sonar

Share it on social #SoNAR #SoNAR2020 #AutomationReport

Corporate and Sales Headquarters APAC and EMEA Headquarters Juniper Networks, Inc. Juniper Networks International B.V. 1133 Innovation Way Boeing Avenue 240 Sunnyvale, CA 94089 USA 1119 PZ Schiphol-Rijk Phone: 888.JUNIPER (888.586.4737) Amsterdam, The Netherlands or +1.408.745.2000 Phone: +31.0.207.125.700 Fax: +1.408.745.2100 Fax: +31.0.207.125.701 www.juniper.net

Copyright 2020 Juniper Networks, Inc. All rights reserved. Juniper Networks, the Juniper Networks logo, Juniper, and Junos are registered trademarks of Juniper Networks, Inc. in the United States and other countries. All other trademarks, service marks, registered marks, or registered service marks are the property of their respective owners. Juniper Networks assumes no responsibility for any inaccuracies in this document. Juniper Networks reserves the right to change, modify, transfer, or otherwise revise this publication without notice.

7400113-003-EN OCT 2020