D2DO312: Networking at Scale: AWS Transit Gateway War Stories

Kyler Middleton (0:07)

Welcome to Day 2 Dev Ops where the dev, oops, is in the details. I am Kyler Middleton, and I'm joined by my jovial co-host, Ned Belavance.

Ned Belavance (0:16)

So jovial, today we're discussing the challenges of working with AWS networking at scale.

And by scale, I mean 95,000 hosts with the Transit Gateway. That's a lot of transiting.

Kyler Middleton (0:29)

Sure is. Our guest today is Devender Singh, and he's the one behind managing that chaos, along with a ton of other projects in AWS and Azure.

Without any further ado, let's talk networking.

Ned Belavance (0:41)

Welcome to Day 2 DevOps. We're very excited that you're here, that you're here to tell some stories, some battles that you've had in your professional career. Before we get into that, why don't you tell the folks a little bit about yourself and why you ended up in this wonderful world of technology.

Devender Singh (1:00)

So thank you, Ned, for inviting me to your podcast today. My name is Devender Singh and I work as a principal cloud architect with ZapSec Technologies. I have overall 12-plus years of experience, comprising of AWS full-stack development and DevOps in my earlier days. I specialize in mergers and acquisitions related cloud mergers, large-scale data center migration, network optimizations on the cloud and security and observability, and whole nine yards of the cloud development, deployment, and operations. On top of that, I am AWS certified professional architect, network security speciality, and have little bit of certifications on the Azure side also. I'm a hyper-agric cloud architect.

I am well-versed in terms of automation technologies like data form, Kubernetes, and Python as well.

Kyler Middleton (2:01)

That's amazing. That's so many certifications. Are you going for the gold jacket one day? Got all the certs gold jacket from AWS?

Devender Singh (2:10)

A couple of my friends have it and they mentioned that getting one is the easier task.

I'm not saying it's very easy, right? Maintaining one is the most difficult task because it's like, it's going to consume half of your life if you keep that golden jacket thing.

Kyler Middleton (2:28)

They don't take the jacket back, right?

Devender Singh (2:31)

At least to maintain that status. I have all the 15 Those are in active state.

Kyler Middleton (2:35)

Oh, to reach the mountain. And then once you reach the mountain, who cares? You've got there. That's amazing.

Yeah.

Ned Belavance (2:42)

I can't even imagine.

I wish I had that kind of time and fortitude to dedicate to the certification process. But I'm more like a dog that sees a squirrel. Look at that shiny thing. And I'm off chasing it. So that's my life.

So what I really wanted to talk to you about was some of the things you've encountered in the M&A space, mergers and acquisitions, and also data center migration, solidation, because I did some consulting for a few years, and I was active in some of those projects, and they were always a nightmare. So I'm curious, what types of mergers and acquisitions have you been through? What's a bigger one that you've had to deal with?

Devender Singh (3:27)

So I'll talk about one of the mergers and acquisition based scenario that I worked on. It was for a very large scale hybrid cloud based enterprise customer, or I would call it as a BFSI customer.

The customer had a very large ecosystem of their own, like for example, 900 AWS accounts, and for example, they had close to 50 or maybe 80 Azure subscriptions, any state like that. And it was built by using well-architected framework and all the best practices of automation from day one, no click ops, never, because there was no manual role ever created, who have write access into the environment. Everything has read access and only pipelines can deploy the code there. So you can imagine it to be the epitome of how you would want to build the landing zone, or you want to rather maintain it after building it. But they had close to five other entities that they acquired over the years, and those entities were not following all the guidelines, or not following all the best practices that they had in their ecosystem, and it was a kind of a technical debt. So the ask was to basically migrate those acquired entities into the bigger umbrella, and make sure that the overall organizational best practices and the best practices of the landing zone that this bigger organization has been adhering to from the past couple of years, they also start acquiring that. And it is easier said than done, right? Because once you basically try to push or try to put one shadow, once you try to shut down one side of the organization and migrate to the other side, it's not just account migration. It's always thinking in terms of, how is my SAP policies that are going to be impacted because of this migration? How is my existing users and their experience, and the existing administrators of these accounts being migrated going to be impacted?