I was a panelist at the ONUG conference in New York, where we discussed the impact of automation and machine learning on IT jobs. It was a great conversation, which I enjoyed thoroughly. The debate of greenfield versus brownfield came up a few times in the conversation, and I remember jumping in at one point and clarifying that from a customer perspective, there was no “brownfield” versus “greenfield.”
Customers almost never “upgrade” brownfield environments; That would be akin to upgrading components or adding a new engine to a 10-year old car that doesn’t meet any of the performance, emissions, or safety standards that are readily available when one purchases a new car. And customers rarely deploy pure greenfield environments. Their upgrade processes are constrained by the need to support legacy technologies in support of their business that require them to keep the lights on, and prevents them from performing forklift upgrades of their entire environment. And even if they were able to do so, such an approach can carry unreasonable cost and risks of disrupting the business if the upgrade doesn’t go smoothly.
Instead, what I’ve seen customers do far more often is deploy what we like to call “green patches”. That is, they upgrade their infrastructure one incremental step at a time. This incremental new step could be a new rack or, often a new POD. This new green patch is based on the latest thinking in terms of architecture, and incorporates the guiding principles needed to meet the ever evolving requirements of the business.
This is more true today than ever before. Because of the urgent need to embrace the digital transformation of their business, enterprises are embarking on an accelerated schedule to upgrade their infrastructure. The guiding principles that CIOs leverage their new green patches need to set the foundation for log scale improvements in how compute and network infrastructures are built and operated, that is, reduction of capital and operational costs, while increasing capacity and reducing risk in their platforms. These guiding principles are as follows:
Simplicity of operations through turn-key automation of the entire lifecycle of their 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. Customers should have the ability to deploy the highest capacity that’s the most cost effective for their needs, and they need to do that seamlessly without disrupting their operational model.
Ability to scale to meet the needs of the business. This is accomplished through proper scale out architectures, and through operational models that enable the ability to grow infrastructure or replace devices to newer technology of larger capacity seamlessly.
Our customers choose Apstra for their data center green patches because we uniquely deliver on those three guiding principles, enabling them to achieve log scale efficiencies in the costs of building and operating their new incremental infrastructure deployment, especially when compared to how they built and operate their brownfield environments. Our customers choose Apstra because they understand the
exorbitant opportunity costs of doing nothing; high rate of outages and lack of agility, both of which amount to a basic inability to compete.
They believe that Apstra is the right choice because they appreciate the deep technological innovations that we have incorporated in AOS, which made these guiding principles a reality: our distributed operating system approach which provides a foundation for scale, extensibility, and reliability; our turn-key
intent-based approach provides unprecedented simplicity through powerful automation of the entire lifecycle of their data center network services; our disaggregated approach allows them to treat hardware as commodity; the systematic leveraging of open APIs and standards, which gives them control over their destiny; and last but not least, our
intent-based analytics, and continuous validation provides them full confidence that their infrastructure is indeed operating as intended.
Don’t waste your time arguing the two sides of the greenfield versus brownfield conundrum. And don’t fall behind from your inability to build the infrastructure that’s required for your business. Upgrade your infrastructure using a green patch approach instead, setting yourself on the right path for log scale efficiency improvements required by your digital transformation initiative. We would love to help. Please feel free to
contact us or
schedule a demo.
I’ve been around networking since the early 1990’s. My first router was a Cisco AGS running IOS 8.2(3) and had interface cables (appliques?) that sliced the back of your hands when installing them. I would use mainframe telnet emulation software to get to the CLI prompt and type away using show and config commands.
Fast forward 25 years… my hands have healed and telnet morphed to ssh but it’s still all the same process. This, despite the fact that “compute” (whatever happened to calling them “servers”?) was automated over a decade ago and switches effectively became servers with a bunch of ports. But compute automation tools — think Ansible, Puppet, and Salt — were not built for this type of work because networks are distributed systems intertwined in ways that servers will never be. And these tools were meant to handle provisioning which only happens initially and rarely after that. But you still need to operate networks, which inevitably requires yet another tool! Why? Well it can all be traced back to siloed organizational structures.
I remember one large bank I worked for had a Configuration Management Group (CMG). All they did was create/push configs based on diagrams an Engineering group gave them. I was in that Engineering group then and I loved it! I would create a before and after diagram and hand it over to them to figure out “the nitty gritty.” I felt sorta like a CIO, only vastly underpaid.
The engineering, of course, was based on an Architecture team’s 30,000 foot view of how the network should be. And after configuration was updated, the operations team had the privilege of taking over for the rest of their (network) lives.
Documenting all these stages and finger pointing between silos was a total nightmare. It went like this:
Ops: “We lost connectivity to Boston DC but I didn’t even know we had a Boston DC.”
Eng: “Check the Visio, it’s somewhere on shared drive, I think.”
Ops: “I don’t have permissions to see it…oh wait, now I do but this diagram is dated two years ago and there’s no Boston.”
Eng: “Damn, well I’m not in office right now, I’ll try to update it later but you could try Arch team.”
Arch: “Why are you calling me, I’m an Architect!”
But let’s say there was a tool that could automate each silo’s tasks. Design, Build, Deploy, and Validate/Operate all derived from your high level business intent?
That, my friends, is what Apstra does. And we aren’t only working with one switch vendor because unlike those vendors, we don’t want to sell you switches. Choose Cisco, Arista, Juniper, Cumulus, or TBD…and we’ve got you covered. We are a software solution and aren’t replacing the Network OS, because they are good at what they do! But we are automating and optimizing the NOS in this vendor-agnostic, top down way and it’s very, very cool.
Soooooo, I know everyone is busy, busy, busy – I still love this graphic:
It’s because of this and how amazing I think Apstra’s intent-based OS is that I created this demo and broke down each network lifecycle stage into 5-7 minute chunks. A mere 26 minutes total. Even a CIO could find this much time.
And as you’ll see, there’s nothing here that same CIO couldn’t do his/herself because we are Intent-based which means we take business logic from you, then take care of everything else. We want to remove the mundane and repeatable, so you can focus on what humans do best, which is creating new ways to help your businesses.
Have a look and drop a line to firstname.lastname@example.org. I would love to go deeper here on your needs and all the other amazing things Apstra does but I didn’t have time to discuss here because I’m very, very busy.
And it certainly did deliver some drama as CFPB Director Cordray departed, kicking off a fight for control of that agency.
We asked Deana Rich, CEO of Rich Consulting, to go beyond the spectacle and talk about any impact the new administration has had on regulatory issues and what payment facilitators should watch for in 2018.
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.