Follow me:
Listen on:

Day Two Cloud 115: Software-Defined Interconnects With Console Connect (Sponsored)

Episode 115

Play episode

Today’s Day Two Cloud sponsored episode dives into software-defined interconnects. The big idea is that you go up to a Web browser, click a few times, and now you’ve got a circuit stood up between your data center and AWS, or between you and a business partner, and so on. We’ll get into the details about how it’s done with Console Connect, a PCCW Global company.

Our guests from Console Connect at PCCW Global Limited are Jay Turner, Vice President of Development and Operations; and Paul Gampe, Chief Technology Officer.

We discuss:

  • Console Connect’s connectivity platform
  • Getting under the hood of the orchestration engine
  • How Console Connect sets up the workflow underneath the automation magic
  • Running multiple services over a single circuit
  • More

Show Links:

Console Connect

Console Connect Resources

Console Connect Docs

@ConsoleConnect – Console Connect on Twitter

Console Connect on LinkedIn

@PCCWGlobal – PCCW Global on Twitter

PCCW Global on LinkedIn

@PaulGampe – Paul Gampe on Twitter

Paul Gampe on LinkedIn

@esmcsqr – Jay Turner on Twitter

Jay Turner on LinkedIn


[00:00:03.440] – Ethan
Welcome to Day Two Cloud. We have an absolute treat for you today. I do mean that we had so much fun recording the show. A sponsored show with Console Connect, where we’re gonna talk about software defined, interconnects. The big idea, you go up to a Web browser point, click, now you’ve got a circuit stood up between your data center and AWS or between you and a business partner, etc. And we’re going to get into the details of how all that is done with our guest today. Ned, what stood out to you about this show?

[00:00:30.490] – Ned
I mean, the key thing that you said is details, and we get into details. They don’t just talk about the product and what it does. I mean, that stuff is pretty cool, but we actually talk about the orchestration engine that’s sitting underneath the workflow engine, how they had to run actual commands on the Cisco gear. We get into the nitty gritty and the details. And for me, that was the most delightful part of the entire conversation.

[00:00:53.760] – Ethan
It was fun. It was really fun. Your voices today the people you’re going to be hearing, our guests. Paul Gampy, chief technology officer at Console Connect. Jay Turner, vice President of development and operations at Console Connect. And these guys are nerds. Jay, in fact, told us we were prepping for this, that he’s responsible for a lot of the automation and so on that happened. He knows a lot about what’s going on. And again, it really shows. Please enjoy this sponsored episode with Console Connect. Well, Paul, welcome to the show.

[00:01:21.820] – Ethan
And we want to hand the first question off to you. We need a 10,000 foot view of Console Connect. You guys are new to the Day Two Cloud audience. So what is this company and product all about?

[00:01:33.700] – Paul
Console Connect is a platform designed to orchestrate connectivity between data centers, clouds and anybody who’s a participant on the platform.

[00:01:44.160] – Ethan
So you said orchestrate connections between. Does that mean are you supplying the connectivity as well?

[00:01:51.400] – Paul
Yeah. Console Connect came about in 2014 and in 2017 we were acquired by PCCW Global. So it’s an amalgamation of 1.3 million lines of code and combined with one of the largest global networks in the world.

[00:02:09.820] – Ethan
So now I’m trying to decide, should I be excited about 1.3 million lines of code because of the capability or frightened to death? Scared Paul.

[00:02:16.380] – Paul
I wake up in the morning feeling both depends on how the day goes and what the defects in the backlog looks like, but it’s a substantial capability, I think, is take away. I’d like you to take.

[00:02:28.780] – Ned
Well, yeah, sort of begs the question, what is that 1.3 million lines of code doing? Like, why start Console Connect? There are certainly other companies out in the provider space, so I assume the code is your differentiating factor. What’s all that code doing?

[00:02:45.480] – Paul
So in 2014, when we started Console Connect in terms of the development community, Jay and myself and a few others who joined to begin developing the platform. I certainly joined the organization because I saw that we had through a long period of time work in open source and done a lot to empower the Enterprise through getting access to source code. That was sort of the last 20 years of my career prior to joining Console Connect and certainly through Jay and a few others. All of us come from a long period of contribution to the open source community.

[00:03:20.360] – Paul
And what we saw is these cloud providers. The Hyperscalers had to some extent taken open source and begun to commoditize it again. And so was that doing several things to disable or to disempower the Enterprise? And one of the things that really struck me as a the pendulum swings from decentralization back to centralization, and all these workloads start to move into the hyperscalers. Enterprise now becomes really critically dependent on the network again. When we were doing computer at the edge, it didn’t matter so much, but real, having the ability to control the path from source to destination is really critical when your workloads are in the hyperscalers.

[00:04:01.140] – Paul
So once they’re an open network just like there had been open source and so passionate about ensuring powering the Enterprise, Console Connect represented for me a chance to open up the network again and put the Enterprise back in charge.

[00:04:15.810] – Ethan
Well, you keep talking about the dependency that enterprises have on their WAN providers. This does depend somewhat on the market, but it’s it’s rough. It can be really rough. Lead time for circuits where you can get circuits, how much they’re going to charge you for last mile access? Whether you’re getting true diversity, all those sorts of things can be really painful. Now add to that a mix of not just physical premises wherever you’re going. But then now I’m connecting to SaaS. Now I’m connecting to cloud. Now I’m connecting to some neutral data center where I happen to have Colo and your WAN presence and what you actually need out of your provider is that much more complex and time sensitive often as well.

[00:04:58.140] – Ethan
So to me, when you describe what was going on with the time Console Connect got founded on what you can do with it. Those are the problems that you’re addressing. Hopefully, I just got excited for the right reasons, Paul.

[00:05:08.200] – Paul
Absolutely Ethan, spot on that’s. What were you can see the trend beginning right in 2014, 2015. More and more mission critical value of applications were being delivered to the Enterprise via SaaS application by a cloud. And so therefore this network criticality became really important in the future of the Enterprise, and so did the ability to connect quickly. I’m going to put type in my credit card now, amd 15 minutes later, I’m starting to put critical data into a SaaS application. How do I connect to it?

[00:05:41.060] – Paul
Is that going to be seamless as credit card entry experience. So that’s what that 1.3 million lines of code is doing is giving you the same elasticity around network as you’ve had with compute.

[00:05:53.920] – Ethan
Well, there’s another sort of obvious question to ask here, which is this a lot of folks that are connecting to these resources just saying, I use the Internet that’s good enough. Why do I need Console Connect? What’s the answer to that?

[00:06:03.660] – Paul
Well, the Internet is good enough. One of the beauty of Jay and I joining PCCW Global via acquisition is the underlying network under Console Connect is AS 3491. Like we’re in the top ten AS’s in the world, and we ship about 17% of all Routable addresses over the Internet. So this is a very different scale of network to when we were a startup out of Silicon Valley, and I would argue that we deliver very good Internet on AS 3491. But some applications are best served from an appropriate allocation of bandwidth for the task.

[00:06:44.500] – Paul
We’ve got a mission critical application that we’ve just recently moved into cloud, and I’ve got 400 staff in an office that may seem unusual, but we’re a very geographically distributed company, and we do have staff returning to office environments in some parts of the world. And when I’m moving a mission critical application into a public cloud, I need to have assurance that I’ve got reliable bandwidth allocated to that application for my staff who are in an office. That’s what Console Connect does for me as an internal user, and it’s what it does for our external users as well.

[00:07:19.620] – Jay
There’s one element of this that people don’t seem to realize until it smacks them in the face. There are regulatory and geographic restraints to some traffic depending on where you are sitting. And so there are needs. And there are customers who need to know exactly the path that their traffic is taking. And no matter how good your public Internet is, that’s never going to be the case. You’re never going to be able to tie that traffic to a particular path. These dedicated interconnections that do allow that point to point visibility into exactly the path that the traffic is taking and can even be controlled to the extent that you can modify and influence that traffic flow and then even produce reports in the case that those need to be reported up to various agencies. So a lot of need there for that.

[00:08:08.680] – Ethan
So then if I whip out the credit card and give some money to Console Connect for that circuit, is that network then all your own? I mean, I understand. Yes, I can get Internet through that potentially. But is that all your own network then, or you there’s some providers out there in this space that what they’re really doing is cobbling together a bunch of other people’s networks, and maybe they do an overlay on top kind of thing. But that doesn’t sound like what you’re doing.

[00:08:34.870] – Paul
Absolutely not. So PCCW Global AS 3491 has been a network built by over almost two decades. The underlying infrastructure that sits under the beautiful user experiences of Console Connect is 135 points of presence just in the transmission network, 46 terabytes of transmission capacity and 67 international cable system that’s just layer one layer, layer two is 127 points of presence, 18 terabits of edge capacity and 17% of the Internet routes. And then we took the 1.3 million lines of Console connect and integrated it with that network and said, how about it? This is what you can now automate.

[00:09:16.850] – Ned
Wow, so you’re not only orchestrating customers, you’re also orchestrating your own parent company to a certain degree. Would that be correct?

[00:09:25.710] – Paul
Yeah, actually, one of our biggest customers is our parent company.

[00:09:31.830] – Ned
How about that. So if I’m a potential customer and I’m curious, you’ve already mentioned sort of cloud and SaaS, but specifically, what kind of endpoints could I connect into a Console Connect network? If I’m a client.

[00:09:44.720] – Jay
It continues to grow day by day, which is the wonderful news. Obviously, our initial target was large hyperscalers. So all the public clouds that everyone’s familiar with AWS, Google, Azure, Alibaba, Ten Cent, Oracle, IBM, and then we get to some much more regional cloud, private and public cloud connectivity. So all those are available. But then there’s a second class or second category of endpoints which are SaaS providers.

[00:10:17.860] – Jay
Regardless of where they happen to be located, that ability to connect to your provider, that entity that’s providing some sort of core critical application, another category or your own assets. We have a number of customers who use the Console Connect platform to extend their own network, be it data center to data center, branch office to main office, that sort of thing. And then the last category from a private interconnection standpoint are other enterprises, and it ebbs and flows. That one’s a funny one. It’s one of those cases where when two companies do need to tie their networks together, for whatever reason, it’s an incredibly valuable asset to be able to do that through the platform and to be able to see all of those all those participants in our network and be able to extend and try to interconnect to them so that’s the private interconnection bit.

[00:11:21.120] – Jay
We also now are offering a IP transit or general Internet access capability through the platform as well. So that’s a new endpoint that we have recently added past couple of months. And then the other new one that’s just been launched on the platform is that we have now added Internet exchanges and continue to add more and more as we move along. So that’s going to allow a user to over our network, find an Internet exchange, and wherever they want it to be, it doesn’t have to be local to them, and not only provision that interconnection to that Internet exchange, but also use us to help work through the setup and negotiation period with the Internet Exchange as well.

[00:12:06.200] – Jay
So it becomes almost an Internet exchange as a service, which is kind of a new concept. But if you’ve ever worked through the details of provisioning that sort of connectivity and working with the Internet Exchange and all the quarantine bits and all of that, it’s not the most straightforward process. And so being able to bring some sort of automation and flow to that has been immensely helpful to our customers.

[00:12:31.970] – Ethan
With the Internet Exchange you’re talking about like extending the layer two typical IXP sort of a service down to the customer, but automating it.

[00:12:41.160] – Jay
And the other element that gets used there is we have customers who they may be located in Silicon Valley, but for whatever reason, need to see the Internet Exchange traffic out of London. Or maybe they need to see the financial Internet Exchange traffic out of Singapore. And they want to see that in New York. Historically, the way to do that would have been go drop a load of gear into wherever you wanted to see that Internet Exchange and then back haul it. We say, hey, this is your network.

[00:13:10.700] – Jay
These are your ports. If you want to pull traffic back across the Atlantic, be our guest. Here’s a dedicated connection point to point. You can monitor all the metrics on it, and we’ll deliver this traffic wherever you would like it.

[00:13:23.700] – Ned
I want to back up to a point that you made earlier, which is connecting to branch offices and data centers within your organization. Does that assume that I already have some sort of WAN set up, or are you also providing some level of connectivity down to those branch offices? How would that work?

[00:13:42.060] – Jay
We can do it both ways. To be honest, we do have a number of customers who are colocated with us or co located in one of the data centers that we have on the platform and via Orchestration. But as a company, we also offer SDWAN connectivity, being one of the top ten providers in the world, we also have a number of partnerships with local loop providers, for example. So if you don’t want to go that SDWAN route, but you want a local loop from wherever that office address is to the closest data center, we can negotiate that as well.

[00:14:21.610] – Jay
We can offer you whatever how many of our options there are available and then broker that deal for you and as part of the partnership and the relationship. And then, of course, we continue to scale and build new capabilities as we move forward.

[00:14:39.410] – Ethan
I just heard you say, essentially, you’ll manage the connection for me, so I don’t have to deal with the last mile provider.

[00:14:45.140] – Jay
If you don’t want to.

[00:14:47.860] – Ethan
Yeah, if I don’t want to. If I have something, then you could glom on to that.

[00:14:51.490] – Jay

[00:14:52.620] – Ethan
Yeah. But if I want you to do it all for me, you can. So that answers the question then about that I had, which is how do I do private interconnect between companies. And it sounds like basically it must be the same kind of thing. I get some kind of a Console Connect handoff between the premises that need to be connected, and then you folks will stand up that private interconnect for me.

[00:15:14.700] – Jay
Yeah, we will. And between two separate entities, we do actually have a check and balance system, which is probably for the best. Company A can request an interconnection to company B. The information that gets shared in that is actually fairly minimal. Obviously, we want to protect both sides of that. And then those parties on the platform can actually communicate with one another just to build some level of trust to negotiate in the moment. Hey, let’s interconnect. We’re doing X amount of volume of traffic already. Let’s go at 100 Megs.

[00:15:57.870] – Jay
Let’s go to 125 meg and be able to have that conversation in real time in the moment and then the end company, can accept that interconnection or decline it. They can accept it a lower bandwidth if that’s the desire. And so we do have that check and balance to make sure that both sides feel comfortable that both sides are agreeing to the peering. But that’s exactly how it works.

[00:16:25.380] – Ethan
That feels very IXP like in that context.

[00:16:29.520] – Paul
And it came about from really the first couple of years from we spent a lot of time with the customer base and the users of platform trying to understand what problems we can solve for them. And there’s one particular network engineer at a SaaS provider who said in 2015 I had three companies ask me if they could directly connect to my SaaS application, and then by February 2016, I had 15 companies in the first two months. And he said, I’m a network engineer at a SaaS provider.

[00:16:58.630] – Paul
I’m dealing with trying to maintain the public infrastructure of my SaaS app, and I occasionally get these inside sales guys will come to me and say, I’ve got a customer who wants to directly connect. How do I do that? He says, I don’t have the team or the time to manage getting everybody on board. The general enterprise doesn’t have a lot of network competency. So he said, can you build it so that I can just tell them to go get a port on Console Connect? They click a request button and I accept it.

[00:17:26.420] – Paul
And we’re done. And that’s really core to that user journey that Jay just described was this ability. How do we facilitate network engineers on either side of the connectivity, getting to trust each other and interacting with each other to provision the service? It’s good if you get a chance to see it in action. It’s really cool.

[00:17:45.900] – Ned
That is pretty cool. Now, let’s say I only need that connection between this other company for a couple of months because we’re moving a lot of data for a project and then that project ends. Is that something I can do, or do I have to commit to a year of that connection. So what is the commitment when I want to create a connection with Console Connect?

[00:18:06.260] – Paul
Yeah. So we take it down to a day. So when you go to provision a service, irrespective of whether it’s connecting to another user on the platform, connecting to a cloud provider or connecting between data centers, you can choose a day, a week, a month or a year.

[00:18:20.570] – Ned
Okay. So I’m not locked in for a year. I can do it for the two months that my project runs and then shut it down when I’m done. In terms of what I’m paying, am I paying just a flat rate for the connection, or do I pay per Byte transferred? Is this a situation like, AWS, where I’m going to get hit for Internet connection fees coming and going or what’s the deal there?

[00:18:41.750] – Paul
Yeah. Great question Ned, and so it’s a flat fee. We wanted to give the enterprise the same sort of continuity and confidence that if I’m provisioning this service then I know what it’s going to charge. We’ve obviously got the ability to flex bandwidth up and down. Or you can change that term of the connection if you need to. But we’re not going to change the price on you. It’s a fixed fee.

[00:19:01.860] – Ned
Got you, okay. And if I need more bandwidth, that project, we realize, oh, crap. We have 100 Meg circuit, but we need a one gig connection because there’s just so much there, I can easily move that up. Is there an upper limit right now on the connection size that I could provision?

[00:19:18.080] – Paul
Yeah, Port limit. So we’re doing connectivity one and ten gig, and soon we’ll be introducing 100 gig ports.

[00:19:24.660] – Ned
Okay. So I guess my big project is going to have to wait for those 100 gig ports because obviously, Paul, I’ve got a data Lake next to a data swamp, and I just got a lot of stuff to move [inaudible 00:19:37].

[00:19:37.920] – Jay
Yeah. Another neat aspect of that flexibility is it can be programmatically controlled. So we were just speaking in terms of suddenly I have a huge need for bandwidth or whatnot? We have customers that kind of script their flex over the course of a day or over the course of the week. They know that on Friday that they’re going to, you know, download whatever or they know that 06:00 p.m. Regional wherever that they’re going to, send their daily receipts or whatever back to home office. And so they can they can just kind of programmatically control that over the course of the day and really maximize their spend. At the end of the day.

[00:20:25.220] – Jay
These customers are paying for these ports. These customers are paying for their cross connect, and they should kind of be in the driver’s seat for how they want to utilize that spend. That was really one of the foundational goals.

[00:20:37.290] – Ethan
What’s the onboarding process? I’m going to guess it’s really straightforward. Just from what you’re describing because it would be weird if you made me go through a lot of hoops in a 50 page contract.

[00:20:44.980] – Paul
We have a fantastic design team. We’ve been with the platform since we first started putting a user experience in place. The onboarding journey is really simple and transparent. It’s click through a couple of terms and conditions. If you’re going to get connectivity in a data center will automate the LoA for you, and once your port goes active, you’re notified by the platform and you can start provisioning multiple services from a single port.

[00:21:12.080] – Ethan
Straightforward enough. All right. Doesn’t sound bad at all. Well, okay, gentlemen, we have a good idea of what Console Connect is and does and why I want to use it. Now let’s look behind the curtains. I want to get a little nerdy with what you guys are doing, cause there’s a lot of magic there. And when we were prepping for this call, you told us there are no secrets you’d share with us, a lot of what was going on behind the scenes. So let’s dig into it. Now you have told us that Console Connect is orchestrating one of the largest IPv4 networks in the world.

[00:21:39.360] – Ethan
Okay, so let’s start at the beginning. If I’m a consumer, I’m standing up a new circuit. I’m clicking buttons in the GUI. What actually is happening to bring that circuit to life.

[00:21:48.630] – Jay
Yes. So this is where the real magic happens. To be honest. And I kind of have to take a bit of a step back and kind of give bit of a tour of how we got to this point, the initial network that we were intended to orchestrate, prior to the acquisition. I think we all sat around the table one day and we’re all very excited. We’re going to OpenFlow and the latest and greatest and code that’s five minutes old. We’re going to deploy it, and we very quickly hit the brakes on that because we realized that that was not a good idea for a myriad of reasons.

[00:22:25.850] – Jay
That was in comparison to the PCCW global network. It was a minutely small network, but even at that scale, we knew that to be able to get in front of a customer and tell them that we had confidence in what we were doing and that we earn their trust. We needed to be able to say we’re orchestrating this network just like anyone else would. We’re orchestrating it the way that the vendor of the devices intended to. And that is the way that our support organization can look at that’s the way our NOC can look at it.

[00:23:00.460] – Jay
And that’s the way that can triage and debug any issues. So fast forward to when the acquisition occurred. The solid foundational goal there was north bound API. We wanted to be crystal clear and transparent, so the front end, the API, all the orchestration breach downs. We wanted that to be a crystal clear API and interface south bound down to the network layer. As I said, we wanted to make sure that we were operating in the same way that the network was already sitting there. So we didn’t want to come to a network with the size of PCCW Global’s and start pushing a new technology down there to co-reside beside traditional programming and traditional configuration.

[00:23:42.550] – Jay
So we push Cisco code straight to the Cisco boxes. The template that we’re pushing down is identical to what a customer engineer or a technical account would push to the device. In the case of a manual provisioning.

[00:23:56.480] – Ethan
So let’s pause here for just a second here. So there’s a couple of things worth defining to set context here. So we’ve got some device in the middle here a controller that’s called we’ve got a northbound interface with a clearly defined API. You said that’s what I could call that API as a consumer and tell the controller I want certain things to happen using that API.

[00:24:17.930] – Paul
That’s right.

[00:24:19.450] – Ethan
The southbound direction is what the controller is using to talk to the devices. You mentioned Cisco devices specifically. And what you’re saying basically, is you’re using the Cisco CLI, but you’re doing it in an automated way, as opposed to using one of the many great variety of APIs that Cisco and various other vendors provide you that are specific to each platform, and so on. You’re just sticking with the CLI. So you got your south bound interface is basically, you’re – I assume – SSH’ing into the device running commands at the device to execute whatever it is that the customer is needing.

[00:24:56.500] – Jay
Yeah, we are. And all of those various functions are wrapped as well. So should we need to change them. Should we decide with a turn of technology if we start going deploying net new gear that supports some a new fangled way of doing something we can very easily trade out what we’re doing on that specific device because everything is modular, and we can obviously take advantage of that new technology. But again, in a manner that the vendor look at and very easily go, oh, yeah. We see what you’re doing, and we can, as I said, communicate to our customers exactly what we’re doing.

[00:25:39.300] – Ethan
So two keywords there. You said modular, and you said wrapped. So basically, we’ve got an abstraction layer. So if you don’t want to use Cisco next year and you swap in, I don’t know, Juniper, Artista, or whatever you can do that, you can modify what you’re sending in the south bound direction without having to blow up the entire code base, you just update the module to speak whatever is needed to be spoken to those devices.

[00:26:02.530] – Jay
And in fact, this is not only a hypothetical. The acquisition, we were prior to the acquisition, we were not on Cisco gear. The team spent three weeks, sorry, three months porting, and in 90 days, we went from acquisition to writing, orchestrated automated code to the network. And that was the power of that abstraction layer and the power of understanding what we were doing. It made it very simple to set the two configurations side by side and go, oh, yeah. Okay. We need to change this primitive. We needed to change this directive, all the variables coming from over here. Now, it was very straightforward to do that port. I don’t necessarily want to do it again. But.

[00:26:55.500] – Ned
It’s a good thing that technology doesn’t ever change, and you definitely won’t have to go back.

[00:27:02.280] – Jay
I’m not going back. Not going back.

[00:27:05.440] – Ned
I’m curious about some of that. Maybe a little bit of the implementation details on that because you could put something together entirely yourself. You said 1.3 million lines of code. There’s a lot of code in there, or you can leverage some existing tools that are out there that are meant to reach out to network devices and help configure them. So did you roll your own in a programming language, or are you leveraging some of the open source tools that are out there?

[00:27:30.630] – Jay
All of the above, the development team, and that worked on those of us that put this together. Our first inclination is going to be to pull an open source tool off the shelf for a myriad of reasons. Mostly, that means we don’t have to maintain it. And we did that to a fair bit. We did have to write some code ourselves. We had to modify some code. We push that back upstream because we’re good citizens, but a lot of that one 3 million lines. There’s a lot more going on than just the network orchestration.

[00:28:11.630] – Jay
There’s a workflow engine and layer in there as well to control the various functions that we need to push down through that north bound interface. And then obviously, there’s a beautiful API. It’s actually two APIs. There’s one to the back end and one to the front end. And then there is our user interface and our portal as well. So there are a lot of pieces here that add up to that 1.3 million. I think if I were maintaining 1.3 million lines of network orchestration, we would probably be doing this podcast from a padded cell.

[00:28:51.830] – Ethan
Now, Jay, you mentioned beautiful API, and I heard the eye rolls in the audience, who are like. I bet it is. I’m sure it’s beautiful, Jay, but I spent time in the API documentation prepping for this show, which is all public. You can just, I forget the URL. We have it in the show notes. If you go to Packet Pushers dot net and day two cloud, you’ll find the show notes here and you look at the Console Connect API documentation. It is clear. It appears that a lot of it was written by a human who wanted another human to understand what it does.

[00:29:21.930] – Ethan
All the fields are, there’s a lot of fields man depending on what’s going on. The JSON blob you get back is like, depending on what all you’re trying to do. Okay. These key value pairs are describing things I didn’t know, even needed to be things at the moment. And then you look at it like, oh, yeah. I can see how I need that. It truly is a beautiful API, my compliments to you guys on that.

[00:29:43.370] – Jay
Well, thank you so much. And I will certainly take that back to the team as well. I would like to take credit for even 1oz of it. I can’t. The folks that put this together are truly amazing.

[00:29:59.010] – Ethan
Let’s dig into the API a little bit more Jay, can you or Paul, can you give us some examples of how your user community in Console Connect are using the API? I think a lot of folks are just going to use the regular UI you provide over the Web, right. But if folks are using the API, what kind of interesting things might they be doing?

[00:30:16.460] – Paul
Yeah. A good way to summarize it, perhaps what Jay described is actually a four tier architecture. So we’ve got a stateless Web client, if you’re interacting by the web interface, that’s a stateless react application talking to a node.js API. So that API documentation that you’re talking about. There is this public facing via an API gateway, node micro services framework. And then at the core of what we do is a workflow engine, because often what we’re trying to do is not just orchestrate our own network, but also orchestrate onward connectivity into partner networks or into public cloud providers who have a workflow engine that maintains the state of that orchestration.

[00:30:56.600] – Paul
And then the bulk of the code that we were just describing was actually more like an internal API that presents a network intent API to our workflow engine. So okay, now want to orchestrate our network. And a lot of that code is what’s pushing the configuration down to the Cisco network. So it’s really those four components. And the part that you see when you’re looking at the public documentation is the node API layer where you can do complex things like, okay, I want to provision a service to AWS, and I want to provision a service through to GCP, and it’s going to, or I want to provision connectivity through Azure. And here’s where you’re going to give me your keys in the JSON blob.

[00:31:40.780] – Ethan
It gets right down to the nitty gritty of VLAN tags and port speeds, and so on. It really gets in there as deep as you as a network engineer that might be listening to us would think it might. It really does.

[00:31:53.000] – Paul
Yeah. And I think of it as a testament through the software developers doing networking. We have a couple of partners who’ve fully integrated their Web portal with our API, so their end customers don’t even know they’re using our network, which is have we delivered an API endpoint that allows you to do everything you can see by the web interface is an example of it where it’s not even our web interface.

[00:32:17.830] – Ned
Right, right. I want to dig into this workflow engine a little bit more, but before I do that, I also read through the API docs, and I just want to let you know you’ve got the Ned official stamp of approval for excellent docs.

[00:32:28.010] – Jay
So that sounds like a sticker we need to put on the website.

[00:32:33.310] – Ned
It really should. Ned approved.

[00:32:36.020] – Paul
Hashtag Ned approved.

[00:32:36.880] – Ned
Maybe that needs to be a sticker. But I do want to talk about the workflow engine, because when I think about all the things that a simple creation of a connection needs to go through and to happen, this sequence of events, that’s a pretty complicated thing. One thing we’ve talked about before is just if you look at the public clouds like the major three, the way that they approach networking and especially stuff like Direct Connect or ExpressRoute, each one does it vastly differently than the other one.

[00:33:07.460] – Ned
So you have to deal with that nonsense. And then you have to deal with all the carrier stuff. What is going on in that workflow engine to actually line the pieces up so everything doesn’t just completely fall apart.

[00:33:18.240] – Jay
You’re dead on with the complexity that’s involved here. The fascinating thing is, as our workflow became more and more powerful. It was a real kind of struggle for me, honestly, being in the role of working on the network orchestration layer itself because I kept feeling well, no, we’ll do that. Leave that to the network folks. We’ll do that stuff. We’ll do that stuff. And as we start working through it, I really started to understand the value of that workflow and the ability to very easily shift blocks around and change the order in which certain actions would happen.

[00:34:00.320] – Jay
But the the true outcome of that, or at least from my perspective, one of the best outcomes of that is it forced the network orchestration to get broken down to very atomic, discrete actions. So I don’t have to have my network know how to provision an AWS direct connect. I just have to have my network orchestration know how to provision VLANs, how to provision trunk ports, how to provision distribution links, how to provision point to point circuits. And I can just cobble those bits together until I get to the structure that I need.

[00:34:39.050] – Jay
And that structure can be defined by this workflow. And if next week AWS decides to change that structure and what that needs to look like, we just go into the workflow engine and swap blocks around and everything magically continues to work. My folks didn’t have to touch one line of code. It’s truly amazing. The natural extension of that, then, is our iterative process to approaching some of these partners or to approaching a new connectivity realm. We can just start with the basic building blocks and just keep moving that point along as we walk through the process.

[00:35:16.680] – Jay
And so at any point, we can say. Okay, well, at this point, we’re going to go to a manual process, we’re going to stub out and let humans deal with it. And then two weeks later, in our next push, we may have orchestrated two more of those human activities. And so we just moved that human bounce point down two more steps until we finally get the entire workflow fully automated and orchestrated. It’s been incredibly powerful. And in the event that stuff does go weird because stuff does go weird.

[00:35:46.072] – Ned
Always, always.

[00:35:46.450] – Jay
It, it’s been amazing how we’ve been able to glob that information out of the workflow, present it in a workspace, and we can go in. We can investigate it. We can very quickly. It’s helped with debug and triage so many different ways we can trade out variables. Oh, wait a minute. We see what happened there. Oh, in test we picked up the wrong port uuid for that Google Port. We flipped the one and the two. Okay, well, let’s change that in our testing. Let’s just flip that around in the workflow engine and we’ll just rerun the action again.

[00:36:25.010] – Jay
Okay. Yeah, we’re good. Moving on. The amount of time that we’ve saved by having that workflow there and being able to orchestrate it, modify it and interact with it has just been astounding.

[00:36:39.100] – Ned
Right, and I think a key point you put in there was not everything is going to be automated, and. When you’re working with the big clouds, they probably have everything automated because they kind of have to. But when you’re working with other customers, some of the SaaS customers I’m sure you’re working with, they don’t have everything automated. So if there’s a manual step, you can add that into the workflow, and it’s not a big deal, right?

[00:37:00.980] – Jay
Yeah. Correct. And to be fair, even with the big guys, not everything is automated. AWS is a perfect example. By policy AWS doesn’t want us as an APN partner to provision a virtual interface for a customer. That’s something that the customer needs to do because that’s a revenue impacting or it’s a chargeable action. So there are manual steps even during an automated Direct Connect. Again, the workflow makes it very easy to just stick in a human action. And we say, Mr. User, you now need to go to your AWS console, and you need to accept this direct connect, and you need to take these next two steps and then come back to us and we’ll finish everything else.

[00:37:50.820] – Jay
Come back to us. Click a button, we’ll finish it.

[00:37:53.900] – Ned
Okay. Now, one of the things that I’ve been challenged with whenever I’m trying to orchestrate a big infrastructure build or something like that, and then make updates to it is managing the state of everything, knowing what state all the different components are currently in, and then feeding that into the engine to go. Okay, what changes are necessary to get to the desired state at the end. So how are you maintaining all of that state because it seems like it’s a lot of information.

[00:38:20.760] – Paul
Yeah. And actually, great question Ned. The reason we ended up with this focus around the workflow is because originally it came from a security posture, so we wanted to have a separation of concerns between physical state and logical state, and that’s what led to this component we call service layer, which is our network intent automation infrastructure. It’s got all of the state information about the physical network. But for the workflow engine that Jay has been describing contains all the logical state, so we can take those two attributes and the different security domains as well.

[00:38:56.630] – Paul
Different software architecture, different stacks that we operate, but we can bring them together in that workflow engine, pulling telemetry from the physical state of the network, pulling the logical state of your current configuration in your cloud provider, and then carry on with the workflow that’s just described.

[00:39:12.320] – Ned
Okay. Kind of like pulling on demand, as opposed to trying to it hold all in a database and refresh that on a regular interval.

[00:39:19.180] – Paul
Yeah, we do use some caching technology for performance, but we predominantly as a design principle, treat the configuration of the live network as the master so that we never get into a state in adherence.

[00:39:32.840] – Ned

[00:39:33.680] – Paul
And it’s been great. It’s allowed us to be. I think we were the first ISO 27001 certified software defined interconnection platform in the world. As a result, we’re able to operate an information security management system and deliver that level of security, plus your assurance from users.

[00:39:50.810] – Ethan
So I’ve got kind of a QoS question. I think one of my favorite topics. I don’t know if we even brought up in the show, but I know from talking to you guys that I don’t have to have multiple physical ports, like one per service. I can have one physical port connected to Console Connect and then run a bunch of services over that and you’ll virtualize them for me. Okay. So how do I do that and not have the services I’m running on the same physical line, clobber each other.

[00:40:18.640] – Jay
It was a challenge, and it was a challenge, not just from the perspective of okay, here are the primitives to do that, but from a perspective of proving that they were actually doing what we wanted them to do. And we’re protected. One of the benefits of being on the network this large is that you in the test environment, you can very easily create a DDoS attack on yourself. That’s fun to do, by the way. Great fun. So we’ve got environments that we can replicate this. We’ve got data that we can replay to replicate these scenarios.

[00:41:01.440] – Jay
And so we’ve been able to use that with the primitives for QoS, CoS, VLAN segregation in order to ensure that the traffic was truly protected and acting as the customer wishes. And that last bit is important because some customers say, okay, here’s my gold level traffic here’s VoIP or my video conference traffic. The rest of it is important, but you know, whatever. As long as you get these bits through, I’m fine. Other customers segment it all the way down.

[00:41:36.810] – Ethan
That sounds like multi level queuing to me where you’re actually doing traffic identification and prioritizing and then dequeuing during congested moments according to a policy.

[00:41:46.110] – Jay
Correct, correct.

[00:41:46.960] – Ethan
So traffic shaping to some degree then too?

[00:41:49.440] – Jay
There’s policing and shaping occurring depending on ingress or Egress and depending on where we are within the network. At the end of the day, it is an MPLS network, so there are a gob of benefits from that that allow us to shift traffic around traffic engineer it in cases that we need to. We’ve got a lot of tools in that tool box that we can leverage and do leverage on a daily basis. The other thing is, yes, you’re getting enough transit feed across the common Port, but it’s a rate limited IP transit feed, and it’s a hard rate limit and that’s what the customer has asked for.

[00:42:33.570] – Ethan
As in, I have a ten gig Port, but if I’m only paying for this particular service to have two gigs, your rate limiting that hard, leaving the other the other amount of bandwidth is free for other services.

[00:42:45.590] – Jay
Correct. Exactly.

[00:42:47.090] – Paul
And I think a key point there, Ethan, is the fact that we’ve got this Internet on demand capability. So if you think of other software defined interconnection platforms, there an adjacency, you’ve got to order another cross connect to another service because you still need Internet access. We saw that as a real barrier to adoption for the enterprise, trying to look at these types of initiatives. So from a single port on Console Connect, you can get your general Internet, you can get your AWS, you can get your GCP all separated by VLAN, all shaped as Jay just described. So with one cross connect and you can get all of your connectivity.

[00:43:23.800] – Ethan
Internet on demand. Okay. Yeah, I like it. You guys are knocking down the adoption barriers. Definitely. And this has been, Ned, I don’t know what you thought about all this, but this was a fascinating conversation to me in the sense that I don’t know how much WAS work you’ve done in the past, Ned, having to order circuits and manage them. It’s historically been so painful, so to be able to do point and click is a whole different world.

[00:43:47.470] – Ned
Yeah, enough that I hate it.

[00:43:51.410] – Ethan
Well, Paul and Jay thanks for joining us today. Jay, would you share with folks how they can connect with you guys and follow you? Find out more information about Console Connect.

[00:44:02.460] – Jay
Certainly a first off, thanks to Ethan and Ned. Thanks to you both for having us on here and letting us talk about our project and our little baby. Creating an account and being a part of the Console Connect ecosystem is free, free as in beer. So come visit us at www Console Connect dot com and there’s a button there where you can create an account and join us. Take a look. We’ve got we’ve got a pricing tool there you can go and price circuits. You can price ports, everything’s public. Off of that link.

[00:44:40.940] – Jay
We’ve got FAQs. We’ve got documentation links as well. All of that’s off that Console Connect dot com site, Paul and I are both on the platform. You are welcome to look us up and send us a message. There is some social networking aspects there where you can chat with us on the platform. That’s the best way. Just give us a poke and let us know what you think. And certainly if someone looking for some connectivity, we’d be happy to sell it to you.

[00:45:11.470] – Ethan
Very good, well thanks to both of you real humans and hop on over to Console Connect dot com. Create that account again for free and talk to the people you just heard talking on this podcast, Jay and Paul. And if you’re not remembering names and links and all that because I don’t know you’re in the car. Commuting to the office because maybe that’s a thing for you again, all the information, all the links will be in the show notes at Packet Pushers dot net. Just find the Day Two Cloud link and find them there.

[00:45:38.710] – Ethan
Or day Two Cloud dot io. Our thanks to Console Connect for sponsoring Day Two Cloud today. Ned and I are both independent content creators. That’s right. We work for ourselves, making stuff for you and our sponsors mean that we can keep on doing that. Now hey, maybe you’re listening and you’re a tech vendor with a way cool cloud product that you want to share with our audience of cloudy geeks. Well, why not become a Day Two Cloud sponsor yourself? You’ll reach thousands of hands-on professionals in our audience who are building clouds for their companies.

[00:46:07.180] – Ethan
Find out more at Packet Pushers dot net slash sponsorship. And if you have ideas for future episodes, we would love to hear them tweet at day Two Cloud show or fill out the form on Ned’s fancy website. Ned in the cloud fot com and as always, virtual high fives to you for listening. You are a most excellent human. And until then, just remember, Cloud is what happens while IT is making other plans.

More from this show

Day Two Cloud 174: Building Kubernetes Clusters

On today's Day Two Cloud podcast we walk through how to build a Kubernetes cluster to support a container-based application. We cover issues such as what constitutes a minimum viable cluster, rolling your own vs. Kubernetes-as-a-service, managing multiple...

Episode 115