If you asked me two years ago if I was going to write this blog – I would have told you no way. I’m a technology architect – I design things. As many that know me well will tell you, I say it often, I am “not a coder”. “But wait, didn’t you go to college for programming?” – not really, I took some college courses (Borland Turbo C), and in high school I did some Visual Basic, and I have done some scripting. The reality is that if you write some code – I can read and understand what you are doing, but asking me to write something from scratch, is about as useful as asking a trombone player to paint like Picasso – my brain isn’t wired like that.

Micro-services and Cloud Require Coding Skills

Ok, i’ll admit that – the new world does require more skills than I have. So this year, I took some GO courses, I also did more Python. Would you like me to admit that I enjoyed it? I really tried, and for awhile it was going well, but it just doesn’t feel like me – nevertheless – it helped a fair bit.

Move Up Stack – Don’t Change Mentality

The good news for anyone who is used to cables, switches, routers and servers – is that this new world isn’t any different than the old one. It just shifts everything you know – up in the stack. It was when I started to think this way, everything was in focus. Being a long time communications nerd, and someone who started off in TDM telecom – for me, communications is pretty standard. Everything has to communicate to function and work and just as I made the migration from TDM to IP, it’s time to migrate from monolithic to micro-service. Albeit, I won’t lie, I was in my 20’s when I started VoIP, and I was the only one at my company who was even willing to go near it. People looked at me like I had two heads when I told them what it did. “How do you get ring voltage without a trunk?”. I digress. The bottom line is that the physical, datalink and even the network layers are now being abstracted from applications. Run it anywhere you want, don’t worry about what is underneath. Yeah, that sounds like a plan – just trust the environment underneath. The reality is that you shouldn’t, and your applications should be protected from the chaos that now exists – underneath. This does however mean you have to write your applications and deploy them in an intelligent way, remember, you are the pointy end of the communications stick now, no firewall to save you. With great power comes great responsibility, a responsibility that used to sit in the hands of network engineers.

Security In The Hands Of Developers

My friends look at me like I have gone crazy around the campfire (no literally) – they laugh out loud when I make that statement. The good news is that tools exist to help, I have always said that security is a layered approach, never rely on a single thing to keep you safe. Applications are complex beasts – and there is hardly an application that uses 100% its own code, much of it comes from open source or third party sources – so how do you know if you can trust it? What if that application is updated, what if someone else finds a bug in some code you used – but – you don’t know. These are big things to think about – but the big manufactures like Cisco, are working on tools for that (Disclaimer – I work for Cisco). Scrubbing your applications to make sure you are not using out of date tools. Many of the tools will monitor your code, APIs, and micro-services for intrusion or bad actors, some do it through traditional “firewall” type methods, some by interrogating traffic, but there is an increasing need to analyze transaction level traffic to both ensure performance and security. AppDynamics has been doing much of this for some time, both security and performance. See more of that here from Tech Field day. That said, we have new tools we are working on.

You Need A Baseline To Detect Problems and Threats

Unless you know every single call your APIs make – how do you know what is real and what is not? What if someone messing with your services? What if some developer has written sloppy code or using an API in an unexpected way. You need a baseline. There is actually a standard for this called the OpenAPI Spec. You can specify how your API works – but what if your inter-service API is a mess, or built over time. Trying to build out a spec could be difficult – or what if it isn’t your API. The good news is tools exist to help.

Everything Becomes Clear with APIClarity

Cisco developed an application called APIClarity – apiclarity.io that will sit inside your micro-service infrastructure and watch your API calls from inside the service mesh (like wireshark on a monitor port) and not only watch what is happening, it will ensure your services are operating as expected based on your specification. The good news is, it is free – no, seriously go get it from github and try it out. If you don’t have an API Spec now, then APIClarity will help you generate one, by monitoring traffic and building that specification. This works by putting the service-mesh equivalent of “PCAP” into your service-mesh to deliver all API calls to the APIClarity engine, which then builds your API Specification from scratch. Once you have built that specification, you can save it, and when something unexpected happens – it will let you know. The beauty is actually in the tools simplicity, and at the end of the day everything is pretty easy to understand if you just – upstack your thinking.

DEMO Time

It wouldn’t be good without a demo right? How about a step by step build, no fancy code writing, no serious scripting – this is something you as a network engineer CAN do on your own.