Not all APIs are created equally.

Automation is starting to become the new catch phrase in the networking Industry. It seems like 2014 is the year that marketing groups from different vendors have been touting APIs on their products. Skeptical networking engineers however have claimed that an API does not mean that their jobs are getting easier. In fact it’s been making their jobs a little harder.

Before a networking engineer could strictly focus on pure networking. But now, network engineers are increasingly required to know more and more on how to code or at least know how to read code.

Just because you have an API doesn’t mean all the devices can and will play nice with each other. 

We can see this by looking at three different platforms. 

OpenStack         Contrail        Junos

Now let’s look at their API for data retrieval/configuration

REST                  REST           Netconf

Ok now you have two platforms that use one type of API and a third platform that uses a different API.

Let's look at the resulting Data Structure response

JSON                JSON XML

Again we have two platforms that have the same Data Structure and a third with a different Data Structure.

You might say, ok, at least two of these platforms have the same API and with the same data structure things should be good for both of them right? Actually as they say, the devil is in the details.

I can illustrate this just by looking at a simple IPv4 subnet. 

On Openstack the data abstracted looks like this

{ "networks": [ { "contrail:subnet_ipam":  [  { "subnet_cidr": "12.1.1.0/24",  } ] } ] }

On Contrail it looks like this

{"virtual-network":{ "network_ipam_refs":[ { "attr": { "ipam_subnets": [ { "subnet": { "ip_prefix": "12.1.1.0", "ip_prefix_len": 24 }, } ] }, } ], } }

You can see that one platform combines the subnet with the mask while the other one separates it. For a DevOps engineers and Network Engineers this is annoying. It’s like having to learn different Network Operating systems. The goal of an API should be to allow a simplified abstraction layer.

APIs need to be standardized. Openflow is a good attempt at this. Openflow requires the underlay to have a common protocol in order to allow a controller to programmatically configure them. The networking industry has done a great job at standardizing protocols but a sorry job at creating a common API standard. Maybe the IETF needs to jump in on this. A standardized API could ultimately make our jobs that much more easier.

Google wifi at Starbucks, it's free right?

    I noticed something today, Google is partnering and sponsoring "free" wifi for the Starbucks patron. Now this isn't new news as I found out that they announced this last year. Tells you how much I noticed this change. This makes sense as I found it hard to see how AT&T was monetizing wifi customers. This is a great strategic move for Google on the other hand as now they have a more captive audience to track. 7000 stores worth of audience to be exact.
     They'll know a customer's ip address. They can tell which websites customers are going to based on DNS lookups. This circumvents a browser's Do Not Track or disabling of cookies because their is no need to adhere to it. Unless you're a savvy patron who knows networking by manually changing the DNS address, most people will use Google's DNS address. Even then Google can still figure out where you're going by doing some Deep Packet Inspection sampling on traffic passing through their networking gear. By clicking on their terms of service, a patron is basically allowing them to do this, thus giving up more of their info to the Marketing Juggernaut.
     I haven't used their wifi service, but I'm assuming you'll need to register for a Google Account in order to use their service. Then they'll probably have some kind of jump point to sell you Google products, like music as you sip your expresso drink. They even made an app that has an auto-login capability. It's supposed to be "convenient" for you so you don't have to open a webpage and click "accept" on their terms of service every single time. However this also means that Google will know every time you walk into a Starbucks and how long you spend time goofing off working at a location. Even if you don't use the internet when you visit, they'll know. 
     I don't know how many people use the wifi at a Starbucks location, but I see quite a few people on laptops tapping away on their keyboards dreaming up of the next big startup. I wonder how they would feel if they knew it wouldn't take much for Google to see what they were working on. Well played Google. I'll have a Tall Vanilla Latte please, hold my privacy please.