Work/Life Balance for Network Engineers

Apstra Blog
Work/Life Balance for Network Engineers

I recently had the pleasure of talking with Greg Ferro and Ethan Banks about the work/life balance in the context of network engineering.  You can listen to this podcast here.

I think this topic is particularly relevant at this time of year when it is critical that data center networks are performing flawlessly, while those who are responsible for keeping them running are trying to carve out some quality time with friends and family for the holidays. Intent-based networking (IBN)  is the solution to this problem.

Intent-based networking was born from the notion that it’s possible to programmatically reason about what a business needs from its network.  Capturing high-level intent and translating it to a working network is what Apstra AOS™ is all about.  

Therefore, it’s natural for many people to question what the impact of IBN is on network engineers.  Many people immediately jump to the conclusion that such systems will put network engineers out of work.  What they miss — and this is something we are very passionate about at Apstra — is that IBN and solutions like AOS will actually help network engineers improve the balance between their daily work and their personal lives.

But what causes the imbalance in the lives of network engineers  in the first place?  The first thing we need to do is acknowledge the problem.

Everything is Broken

This week I had to figure out how to use Python to transmit an ethernet frame.  There were constraints and requirements, of course, at every level that complicated the task at hand.  I ended up spending all night working on the issue.  I went down many rabbit holes.  Poor or missing documentation, bad software engineering choices, wrong code examples, and random weirdness all contributed to me spending hours trying to get the task at hand done.  All of this was an effort to compensate for a lack of proper network tooling in the first place.

This is the life of a network engineer.  This is why so much of what we do is all in our head and so difficult to explain or share with others. Network engineers have a difficult job.  It’s certainly a high-stress job much of the time.

For many network engineers, achieving a healthy work/life balance is something of a Holy Grail.  At times it seems like there is always something getting in the way of completing even the simplest of tasks.  Does it have to be like this?

There’s a Better Way

What if there was a better approach to networking?  A saner way of designing, deploying, and operating networks?  A smarter, less stressful way with new and better tools to elevate and de-stress you? We’ve all heard the phrase “work smarter, not harder”, but that’s difficult to do when every resource you have is insufficient or misleading in some way.

We all know what we want the network to do, so let there be tools that help you just do it without all the insanity.  This is what Intent-Based Networking is all about.  It’s what AOS was built to do.

If you want a better work/life balance as a network engineer, then you can start today by learning more about Intent-Based Networking and AOS.  Watch this webinar, then contact us or request a demo.

 

Looking Forward to 2018

Apstra Blog
Looking Forward to 2018

As this year comes to an end, we want to thank our customers and partners for joining us on this amazing journey, share a retrospective of Apstra’s 2017, and make some predictions for 2018.

 

2017 – The industry embraces Intent-Based Networking and AOS runs large production networks

What a year 2017 has been! Apstra delivered version 2.0 of AOS™ and we now have hundreds of nodes in production.

The approach we pioneered — Intent-Based Networking — has become a top strategic initiative for the digitally transformed enterprise. It was embraced by customers, top analysts, and the largest networking company, Cisco, whose CEO said that “Intent-Based Networking will redefine networking for the next 30 years”.

2018 – Acceleration of digital transformation

Entering 2018, we are excited about the future, and especially excited that the vision we had back in 2014 when we started the company is indeed materializing. It feels great to be on the right side of history!

Because of the urgent need to digitize their business, enterprises are embarking on an accelerated schedule to upgrade their infrastructures. More than ever before, it is no longer an option to do nothing or to continue to have your hardware vendors hold you back.

The guiding principles that CIOs embrace for their new deployments need to set the foundation for log-scale improvements in how compute and network infrastructures are built and operated, that is, massive improvements in CapEx costs, in operational costs, and in capacity.

2018 – Simplicity of operation and hardware commoditization

We will see these guiding principles continue to materialize in 2018:

Dramatically simplify operations through turn-key automation of the entire lifecycle of network services, delivering on autonomous infrastructure operations freed from the inefficiencies of manual redundant configuration and troubleshooting tasks.

Free yourself from your hardware: there are plenty of hardware options on the market, from established vendors, to open source offerings. We predict open source options for commodity NetOS functions will become viable in 2018. We expect these options to have a dramatic effect on infrastructure costs. Moreover, customers will increasingly want the ability to deploy the highest capacity hardware that is the most cost effective for their needs — and switching between hardware vendors should not be disruptive to their operational model.

2018 – Accelerated decrease in the hardware depreciation cycle
Scale seamlessly to meet the needs of the business. Legacy infrastructures are no longer adequate, and organizations will move progressively to transition to modern architectures and operational models. In order to keep up with the demands of digital transformation, customers will accelerate the depreciation of their infrastructures. One customer mentioned to me that in order to keep up with the latest network capacities, they’re moving from 4-5 years depreciation cycles to 3-4 years. This is accomplished through proper scale out architectures, and through operational models that enable the ability to grow infrastructure or replace devices to newer devices of larger capacity seamlessly. We look forward to 2018!

At Apstra, we are very excited to be aligned with these trends. We will continue to deliver foundational software that helps our customers deliver log-scale improvements in OpEx, CapEx, and capacity. We look forward to delivering unprecedented simplicity of operations, and the ability to free yourself from your choice of hardware, through software that’s engineered for best-of-class scalability and reliability.

I would like to take this opportunity to thank our customers and partners — we are very grateful for your trust, confidence and partnership; and to our friends and fans — thank you for being part of our growing Apstra community! Happy holidays, and wishing you and your families the best in 2018!

 

Rapidly Build and Operate Physical and Overlay Networks

Apstra Blog
Rapidly Build and Operate Physical and Overlay Networks

Apstra has an upcoming webinar that helps answer a lot of questions around how we are able to dramatically decrease time to market for new data center deployments. As part of the webinar, I will be providing a scenario and showing how AOS™ 2.0 automates the design and operations of complex networks and server compute pools. Here is a sneak peak of what we will cover.

Suppose your CTO has recently told you that the Finance department has decided to create a new application to handle an upcoming new product launch. You have heard a bit about the app and know roughly what to expect, and you’ve built similar environments in the past. Other architects in your organization have promised the CTO it will take two months to create and test the new system before handing it over to Finance for the application to go live.

You’ve built a similar system using VMware ESX and your standard Arista and Cumulus hardware switches, so you know what it will take to complete. You have to create a new diagram, cabling cutsheets, device configs, and once the system comes online you need to get all of the necessary elements into your common monitoring platform so the NOC can take over the daily operations. You have the hardware and need to complete the cabling, which might take a day to patch correctly. All in all you are thinking this will take about two weeks to finish, which is a big improvement over the two month time window that the CTO expects.

But what if you could provide some basic logic, or what we call “Intent”, and have the system configuration completed in 15 minutes? Once you have the configs on the devices you can start patching the cables in and testing everything. Then comes the inevitable challenge of finding the one or two typos you made in the configs or cabling matrix, which always takes too much time. Finally you need to get all of the elements including routing, switching, physical connectivity, and performance monitors into the monitoring system.

Would you get recognized for incredible service if you could do this all in one day? Would the CTO ask you how you were able to beat their expectations by many weeks, and would this result in improved chances for a raise or promotion in the future? And would you be able to sleep at night knowing that the network was built perfectly with no mistakes that might have the NOC waking you up in the middle of the night when they found the one config error you had missed?

We feel that the answers to these questions would be an undoubtable “Yes”, and on this upcoming webinar we’ll show you how AOS can do exactly what we just described.

Please join us on at 11:00am PST 2:00pm EST on Tuesday, December 19 to see AOS in action and learn how to transform your business and life.

 

Apstra AOS 2.0 for Custom Telemetry Applications

Apstra Blog
Apstra AOS 2.0 for Custom Telemetry Applications

At ONUG Fall 2017, Apstra was invited to present an AOS™ Proof of Concept.  With just 10 minutes to present, we were invited to show off the major new developments in our 2.0 release that enable custom telemetry functions and visualizations.  I could talk about this stuff for hours, but was time-challenged to select just a few of the customer use cases that would be most relevant to the leaders of the open networking revolution.

AOS has at its heart a highly scalable datastore that can ingest a tremendous amount of state information and maintain the contextual value of each element.  Couple this with a flexible GraphQL schema, and you can inspect both the desired state and the current operating conditions.  There is virtually no delay in this process, so asking simple or complex questions about the entire network becomes trivial.

This is an amazing development in the world of IT, but the question now becomes how do customers want to use these capabilities?  Do you know of a certain condition that exists in your environment that causes application issues?  How many commands does it take for you to identify this issue?  All of your expert knowledge about these events can be crafted into simple bits of code that can be run within AOS continuously.  Got a best practice that you want to run everywhere?  That takes only a few minutes to write, and then you are guaranteed that the network will always contain this search intent.  You can even build your own remediation methods or simply alert the NOC or operators that a rule has been violated.

Please take 10 minutes to watch the video and then consider this question:

If you had these powers, what would YOU do to improve the state of your business operations?

 

Mitigating Network Outages Caused by Human Error

Apstra Blog
Mitigating Network Outages Caused by Human Error

A recurring theme we hear from our customers is how they want to reduce the kind of errors that come with manually configuring their networks using the device CLI.  From one device to the next, every command entered represents a potential outage.  Indeed, upwards of 80% of network outages are caused by changes made at the device level via the CLI.  The Apstra Operating System (AOS™) can help reduce change-related outages by semantically validating changes before they are committed to the network.  

A Confession

Like many network engineers, I have been the cause of large scale outages.  Even outages that made the newspaper.  If there’s one thing I have learned over the years, it’s that networks are fragile.  Worse, the devices that we use to build networks are also fragile.  It’s no secret that the network operating systems (NOS) that drive these devices are usually riddled with bugs.  If you want to see a network engineer get sweaty, just tell him or her to upgrade the NOS in the network.  Finding a stable NOS that supports your needs can be a stressful, outage inducing event.  

Bugs aside, as network engineers we have to keep an awful lot of stuff in our head in order to successfully execute a change.  We have mental models of how the network is now, how the network will be, and any intermediate phases in between.  If our models are flawed in any way, or we just make a typo, we could cause an outage.

Personally, I’ve gotten to the point where there are only two possible outcomes when I press the enter key:  (1) The network works is as expected or (2) The network explodes.  Even though I know there are states in between, I have been well seasoned to expect the worst as my right pinky finger descends upon the enter key.  It’s almost as if it has an evil mind all it’s own, just waiting for the right time to strike.  

AOS to the rescue!

AOS is an intent-based distributed operating system. With AOS, your network is modeled from a reference design.  This design has rules against which changes in the network can be validated before they are committed.

The reference design requires specific features from the various NOS’s that run on network devices.  During development, AOS is tested against various NOS releases to validate that the network will remain stable and operate as expected across the engineering lifecycle.

Lastly, AOS supports Role-Based Access-Control (RBAC) for the various activities it supports. From network design to operations, you can control the way users interact with AOS.  Contrast this with the blanket “enable” or “configure” mode that most organizations default to on the device CLI, giving unlimited access to the engineers making changes to those devices.

Take the Next Step

There’s no question that the future of network implementation and operations will gravitate away from device-level CLI and the risk that comes with it.  Engineers will interface with the network at a higher, more intuitive level to achieve the outcomes that match their intent.  Apstra is leading the way on this journey.  

To start your own journey, reach out to us today and schedule a demo so you can see for yourself what intent-based networking can do to help network engineers make better, more informed decisions in their day-to-day operations.  

Click the related links to learn more about Apstra and AOS!