As some of you may have heard, after five months of interviews and immigration paperwork, I have accepted a new role with Juniper Networks as a Sr Data Center* Technical Marketing Engineer. This role will see me move to the San Francisco Bay Area in the next week or so, and be based directly out of the Sunnyvale office for at least the next two years.

The Role

This new role is actually quite exciting to me (and a little bit scary) because it takes all of the knowledge and skills I have gained over the last 15 years as a consultant and then makes use them in a different way. Instead of building solutions to individual customer requirements, I will be working with the Solutions Team to help promote solutions that are universal and can scale with user need. I will be working on creating white papers, design guides and helping position Juniper Data Center their solutions.

Having spent the last 15 years working as a consultant I have spent time building a range of network solutions for customers of all size, vertical and across a myriad of conflicting requirements. I hope to be able to bring a different perspective to the team, particularly one that has not grown up with “the Silicon Valley mindset”. If I can help represent the needs of those without multi-million dollar budgets, then I think I will have achieved something

Why the change?

A couple of people (not the least of which – my wife!) have asked me why I’m looking to change positions. There is no simple answer to this, but I do know the following:

• I absolutely have loved my job working with ICT Networks for the past 2 years. I would have had a hard time learning as much as I have in that time-frame, with the freedom to experiment that I had, any where else in Australia. I know for a fact, I couldn’t recommend a better networking or managed services firm in the APAC region. So there weren’t any push factors on that front.
• I’ve been reasonably outspoken that Juniper needs to be provided more “Solutions Based” documentation and sales strategies instead of just focusing in individual bits of tin.
• When I was in Bangkok in August 2013 for the Juniper APAC SE Tech Summit, I sat in a presentation from (my, now, new boss) Jason Sauviac presenting on the new Juniper focus on Solutions and their plan for putting together material and strategies focused on providing detailed output to customers. As soon as I heard this presentation, I knew it was something I wanted to be a part of!
• Also in Bangkok, I heard about the soon to be announced QFX5100 product family and how Juniper was positioning this product and the changes they had made. I have said for a long time “Anyone can throw together a merchant silicon switch, but its what you do on top of that that makes the difference”. Fanboy tendancies aside… I liked Juniper’s response with the QFX5100.
• At the beginning of 2013, Kid President encouraged us to discover our “Space Jam” and I have spent quite a bit of 2013 trying to work out what matters to me, and I realised there were some things I wanted to accomplish in life that would require me getting out of my comfort zone.
• The Bay Area. This one shouldn’t require much explanation, but the chance to spend a couple of years working in the Bay Area and getting to know the people and the going’s on is something that was very hard to ignore.

The Adventure on the other side of the Planet

The last point above brings up possibly the biggest change for me. I will be moving from Sydney Australia to the center of the tech universe. For a country that speaks the same language as me, its amazing how hard it is to communicate with “the locals”. Having never lived anywhere other than Sydney, just moving to a new country is going to be an adventure of its own.

My wife is still working in Australia until at least September, so I will spend the first 9 months or so living solo with a couple of trips from each of us back and forth. In the mean time, I plan to take this first year as a bit of an adventure where I can take on new challenges, and learn as much as I can in the process. Once Bel arrives, we also plan on using San Francisco as the jumping off point to visit a whole range of places across both North and South America – lets do it when where living there! (Just getting to another country from Australia is a whole bunch of hours on a plane )

Mop and Bucket

A lot is about to change for me on both a personal and professional level, but I’m quietly excited about the opportunities that await me. I don’t exactly know what this means for my blog, but I do know that I plan to still remain active in the community.

I guess all I can say is stay tuned… and if you’re in the Bay Area shoot me a message to catch up

* PS. You don’t want to know how many times I wrote “Centre” instead of “Center” while writing this post.

 An Impatient Start

Let me make a couple of things clear right from the outset:

1. I am not a programmer! Yes I have written the odd script here and there in the deep dark past, but I am by no means a programmer. All of my scripts have been about automating some task I had to do. As long as it worked, I didn’t care how efficient or pretty it was – it did what I needed.
2. I have no intention of becoming a full time programmer! I like being a network architect and I like building and playing with network toys. All I want is the ability to make my job easier, which leads me to my last point…
3. I am lazy! I don’t like repetitive work. I would rather do something once or twice and move on. Computers are here to do the mundane stuff for us, so we can create more awesome. I would rather write scripts for other people to do it next time instead of bugging me about it.

So with the above three stipulations in hand, I started to learn Python. Now, when I say “started”, I literally mean a week ago. I already knew the basics of loops and conditionals etc, but I couldn’t read a lick of Python this time last week. I tried the various online tutorials such as over at Code Academy and Learn Python the Hardway, but I knew the only way I was going to get my head around Python was to jump in and just start coding the working I had on my plate.

A Looming Project

I have a project starting in the next couple of weeks that is going to entail configuring about 50 switches with mostly the same configuration, followed by customising port layouts etc. Now just time involved in unboxing all those switches, cabling them up in the lab, firmware upgrading them, prepping the config and doing burn in tests can take a couple of days.

I knew this would be a prime candidate for “automation”. I had better got off my butt and work out how to do this!

So I contacted Jeremy and we hopped onto a Google Hangout where he was able to unleash 2.5 months of “Python knowledge” on me. It was 11pm for me and 5am for him, and it was so much fun Over the course of our conversation we discussed a couple of the core concepts and data structures structures in the Junos-EZ libraries, and Jeremy discussed an idea he had to make extending the existing code base even easier. When I woke up the next morning, he had already committed it to the Github repository.

The Basic Structures

There is a whole heck of a lot in the Junos-EZ libraries, but by only understanding the very basics of the following components, I was able to create some pretty awesome scripts – with only 6 days of Python experience and about 24 hours with the Junos-EZ libraries

Device

The Device object represents a particular network device. When you call the .open() method, the script establishes an NETCONF over SSH connection to the device. From here you can make any of the NETCONF RPC calls you want against the device.

Tables

Now one of the great things about this library is that Jeremy has gone to great lengths to ensure that the average user of these libraries don’t need to understand the deep internals of the code to be able to add functionality. Tables are a prime example of this.

A table essentially represents all the data collected for a certain RPC request, sorted and keyed on a particular set of values and presented to the user as a collection of native Python data structures. The end user only needs to describe the data sets in YAML format without knowing the Python objects below.

The Table I use in this example is called PhyPortTable, shown here:

PhyPortTable:
  rpc: get-interface-information
  args:
    interface_name: '[fgx]e*'
  args_key: interface_name
  item: physical-interface
  view: PhyPortView

Views

A view is applied to a table to create a custom combination of the data in the table. As such, a combination of table and view definitions can be created with just a handful of lines of code yet scale infinitely.

The above PhyPortTable example calls the PhyPortView filter as shown here:

PhyPortView:
  fields:
    oper : oper-status
    admin : admin-status
    mtu: { mtu : int }
    link_mode: link-mode
    speed: speed
    macaddr: current-physical-address
    flapped: interface-flapped

The Opportunistic Script

So there I was onsite working with a customer yesterday afternoon, and I was asked –

“Can you please get me a list of all of the ports on the following switches, and tell me the current operating status and when they last flapped?”.

This request required looking at 5 switches and about 300 ports. Now what was I to do? Within the last 24hrs I had learned enough to know I could probably whip up a piece of code that would generate the required output. And it turned out to be relatively simple.

The code I wrote is shown here:

from jnpr.junos.op.phyport import *
from jnpr.junos import Device
 
dev = Device( user='netconf-test', host='lab-switch', password='lab123' )
dev.open()
 
ports = PhyPortTable(dev).get()
 
print "Port,Status,Flapped" #Print Header for CSV
 
 
for port in ports:
        print("%s,%s,%s" % (port.key, port.oper, port.flapped))
 

This is by no means the prettiest code on the planet, but remember our goal was to just remove the mundane so we could increase the awesome, not become a programmer.

• Lines 1 and 2 tell Python to load the relevant libraries.
• Lines 4 and 5 make the NETCONF connection to my lab switch.
• Line 7 is where “the magic” lies. This line requests that the collection of data be returned as defined by the “PhyPortTable” and assign it to a variable called ports.
• Line 9 prints a simple CSV style header to the console
• Lines 12 – 14 loop through the collected data set and print the values for “oper” and “flapped” (names as defined in the view) in CSV format.

The output of this script is shown here:

Port,Status,Flapped
ge-0/0/0,down,2013-05-24 08:06:54 UTC (11w6d 01:21 ago)
ge-0/0/1,down,2013-01-11 11:56:10 UTC (30w5d 21:32 ago)
ge-0/0/2,down,2013-05-18 08:09:32 UTC (12w5d 01:18 ago)
ge-0/0/3,down,2013-04-18 16:57:15 UTC (16w6d 16:30 ago)
ge-0/0/4,down,Never
ge-0/0/5,down,Never
ge-0/0/6,down,Never
ge-0/0/7,down,Never
ge-0/0/8,down,Never
ge-0/0/9,down,Never
ge-0/0/10,down,Never
ge-0/0/11,down,Never
ge-0/0/12,down,2013-07-06 06:00:48 UTC (5w5d 03:27 ago)
ge-0/0/13,down,2013-07-06 06:00:48 UTC (5w5d 03:27 ago)
ge-0/0/14,down,Never
ge-0/0/15,down,Never
ge-0/0/16,down,Never
ge-0/0/17,down,Never
ge-0/0/18,down,Never
ge-0/0/19,down,Never
ge-0/0/20,down,Never
ge-0/0/21,up,2013-08-02 08:20:46 UTC (1w6d 01:07 ago)
ge-0/0/22,up,2012-09-09 14:10:50 UTC (48w3d 19:17 ago)
ge-0/0/23,up,2012-09-09 14:10:51 UTC (48w3d 19:17 ago)

I was able to run this script across each of the switches I needed to query and provide an “Excel Version” for the customer who asked for the information.

Mop and Bucket

This post only covers an extremely simple example, but most of what we really want to stop doing manually every day is not much more complicated that the above example.

I am going write a follow up post in the next couple of days to discuss how within 24hrs of starting with the Junos-EZ library I was able to bring LLDP discovery functionality to the library with no real skill other than the ability to cut, paste and pray my way through it.

Anybody can work on this stuff, so get out there and start coding!

This is my wife’s first trip to the US, and I know she wants to get out and about and see things (also probably while Im in conference too). I know her list includes seeing the Golden Gate Bridge and Alcatraz… oh… and… “The Full House House”.

Thankfully we have the company of two of my good friends who are locals – Ashton (from Juniper) and my old work mate Cooper Lees, and we are working out “what we should see”.

So what do you consider “must see” things in this area? Let me know in the comments and we will see what we can fit in.

Also, while we’re in town, I would love to catch up with any locals in the area for drinks/coffee/food etc so again, let me know

New offerings on the storage fronts, developments in the server space in the form of the boom of virtualisation, and the simple existence of the network amongst the fact that none of these technologies changed the existing/fundamental laws of networking.

Software-Defined Networking has sprung up as a way of providing both advancements in our current architectures and providing agility in changes needed in the future, but what is truly needed is a true abstraction of the entire data centre model that encompassed all of compute, storage, security and networking. The ability to define all of the requirements of your existing data centre and have them deployed and rolled out across which ever stack you are using (Private / Public / Hybrid / Tomorrows Favourite buzz.), in a consistent and definable manner.

Merging the requirements of each of the existing silos and describing them in a uniform, consistent and repeatable manner is a great step towards blending the cultures of these teams and beginning to solve real problems instead drawing lines in the sand. Continue creating more awesome!

Platform as a Service offerings are already delivering on a model of consistent application delivery (assuming your code fits within certain criteria), but PaaS is not always appropriate for every situation. I have several large “end customers”  who do not have staging or lab environments that appropriately mirror their production environment because the current glue is far to complicated to recreate. If the entire infrastructure was abstracted to the point that they could roll out a complete mirror at the click of a button this would be a no-brainer.

Thankfully, there are many smart people thinking about just these problems, and what it means to the industry. Tom Hollingsworth wrote these words over at Network Computing discussing some of these initiatives, and the guys from GestaltIT / Tech Field Day have joined with the team from SDNCentral to bring together the Software Defined Data Center Symposium in September. It’s still early on in the buzz around SDDC but, like Cloud and SDN before it, over the next 12 months I expect we will hear far more about this as a topic and a trend.

For those of you not local to the Bay Area, the event is also going to be streamed live. For me this means tuning in from 1am Sydney time, but I plan on being online for the entire event. I had the good fortune to be present for the Software Defined Networking Symposium back in 2011, and I learnt an amazing amount from the event, and I expect the SDDC Symposium to be just as informative.

Registrations have now opened, and tickets can be booked and event details can be found at http://sddc13.eventbrite.com/.

It truly is an exciting time to be in this industry!

I personally have been involved in the development, technical review, and exam rewrite process and I can attest to the effort that the certifications teams go to to ensure the validity and integrity of their offerings. Weeding out sources of brain dumps and NDA violations and other activities that threaten this integrity work becomes an on going commitment that requires many hours of dedication.

On the other side of the line is the requirement to have the partners representing the vendor to maintain a level of skills and customer satisfaction. This ensures that when the brand is represented in the market that it will be delivered by the most skilled people capable of delivering the best outcome from the products on offer. This ensures that the vendor brand is not tarnished by substandard implementation or post-sales response.

The easy option is usually to mandate that partners levels be broken into tiers and that each partner must maintain a minimum set of certifications as well as some minimum dollar commitment. And I dont doubt that this is effective in the short term. It’s an easy metric to graph and report on. Sadly it also has the exact opposite effect than the original desired business goal.

The problem usually comes about because various partners start requiring all new staff to get X, Y and Z certification. The number of people obtaining these certifications purely to get a job, and not to truly understand and learn the concepts increases. With this too is the growth of brain dumps and other practices that reduce the integrity such as brute forcing exams or engineers sitting in countless classes to achieve continued education requirements.

As a result meeting minimum number of certified people becomes the goal, and not the education of the suitable engineers capable of delivering the best outcome for both the customer and the vendor. Just as we saw with the CCIE program prior to v4 or the MCSE program in the late nineties and early 2000s – The market gets flooded with sub-par certifications and integrity is diluted or lost.

And in the end, everyone loses.

A couple of things have happened over the past few weeks that made me think about “The Smartest Guy in the Room”, and I thought I would share a few incomplete thoughts on the matter.

As a Consultant

Back on June 18, Matthew Norwood (who I would nominate for the award of “Nicest man in Network Blogging and Puppeteering”) wrote this blog post about consulting. In this post he talks about how as a consultant sometimes you have to accept that you are not the smartest guy in the room. At first this may seem odd, especially because usually our customers are paying us lots of money because we are experts. Funnily enough, on consulting engagements my job is more “I know where to find how to do that thing you are expert in”.

The most recent example of this was a few weeks back I was working on a Proof of Concept lab with a customer to see how we could integrate a series Juniper MX routers with their existing ASR9000 MPLS topology. Thankfully these sorts of things are fairly standard offerings on both of these platforms but this particular customer had their entire network built on Multicast over MPLS Point-to-Multipoint LSPs. Now when you consider that most people consider Multicast a “corner case” in networking, then these additional requirements made it a corner case inside of a corner case! On top of the fact that the customer engineers I was working with did this day-in and day-out, there was no pretending I was the expert. Instead my job became “I know where and how to make the Juniper MX do what you want”, and that was how I proceeded. And I can tell you this was one of the most enjoyable engagements I have had in quite some time.

As an IT Guy

It’s been stated many times that when you look at a group of IT guys, that most likely many of them were the “nerd” or “geek” growing up and were used to being the smartest guy in the room. As such, we often get interested in all sorts of technologies and ideas and run off on different tangents. I work with a couple of amazing guys who seem to tackle any odd-ball concept that comes to mind – like rigging a relay in circuit with the door control system so they can control the door with their pebble watch or simply building 3D printers to allow them to make all the toys they dream of. And often times they love to do this towards the end of the day/week when we are wrapping up units of work, and I know many late nights have been spent back in the office hacking away on something crazy “just because it can be done”.

Sadly, occasionally we take on tasks that are not our core competencies. This isn’t to say that we are unable to do the work, but simply it is not our strength and it can take much longer to resolve than it would a suitably trained / skilled engineer. A recent example of this was an incident that recently caused our team of network engineers to remember what it means to be a “Windows Administrator” and all the bits and pieces required to get some systems back online. We were more than capable of completing the work, but not necessarily in the most efficient fashion. We called in “a few favours” from friends with the required skills to sort this out, but  sometimes it goes against our gut feeling to seek advice. In times like this we need to accept that there are in fact people with strengths in these areas, and to ask for help is not about admitting defeat.

As Full Stack Engineer

And this leads into my last incomplete thought. Some time last week I engaged in a rant-fest with Paul Gear regarding the topic of breaking down silos within IT and what it means to be a “full stack engineer” (for lack of a better word). Admittedly the rant was primarily around how its not easy to break down silos when we still all refer to each other as “Server Guys”, “Storage Guys” and “Networking Guys” (nobody talks to/about “Security Guys” because they “just say no“), but over the course of the conversation I developed a few opinions (as I am known to do). And these are my thoughts on this…

Recently:

• I have started learning to program in Ruby, as well as learning about OpenStack. I have spent a fair amount of my “down time” learning about coding in Ruby and learning how to automate many of my regular tasks. I have picked up a few libraries developed by the guys at Juniper (mad props to Jeremy Schulman) and started learning more.
• I have started getting to grips with service automation using Puppet, and investigating how end-to-end provisioning of both server and network resources as a single process can improve delivery and satisfaction.
• I have built an OpenStack lab (as part of my beta testing of the Juniper Contrail product), and started to learn how to spin up and down workloads on demand and again how to integrate that with the various network requirements.

Do I want to be a programmer or a guy running servers all day? No, but I do want to be able to “talk the language” of the guys who do. There is great benefit in this ability not just as a consultant but as a member of a “Silo Free IT Team”. My view is that in the future, we will have blended teams of engineers, each with an understanding of the various aspects of the stack (Server, Storage, Security and Network), but we will still specialise in one or two of those areas. Working in such a team will be all about admitting you are not the smartest guy in the room and simply admitting “Yes, but I do know this part pretty well. Let’s come up with a solution”.

I dont see specialisation going anytime soon. Even within each of those four areas of IT there is a world of sub-specialisation that can be entire careers for people. The key is to have an understanding of all of the areas involved and know where best to apply your learned skills and experiences. *This* is what makes the future of IT teams… not a group of “jack of all trades” engineers, as some people interpret the idea of “breaking down silos”.

Mop and Bucket

I’ve learnt over time to know what I know, and to ask for help when I dont. Sometimes it takes me a while to get there, but almost every time that I do things get better There is too much happening in IT and too much change in our industry to remain an expert at anything and everything for long. Widen your perspective for high level understanding, and learn where you can best apply and extend your skills.

If nothing else, it will make for an interesting and progressive career!

Sadly, when I travel to the United States and we both attempt to speak “English” nobody can ever seem to understand me. Sometimes its my accent, and other times its the colloquialisms I am using that do not translate effectively, and I am treated by blank stares on the other person trying their hardest not to say “Huh?”.

I’ve learned to deal with this by talking slower and thinking carefully about the words I use to ensure that they dont have some local significance. Anybody who has met me in person knows that I talk loudly, quickly and for a long time, but put me on a call (or a podcast) with guys from the US and I have to slow it right down (and trust me, its painful listening back to it!).

So what does this have to do with networking? Well I was reading this post by Mrs. Y over on the Packet Pushers blog, and it started to resonate with some thoughts I had been having problems putting into words. In the article she mentions how the various wireless vendors implemented the CAPWAP “standard”, but the actual implementation of the standard with accompanying “extensions” means that solutions did not allow for cross vendor integration. I read this post about 30 seconds after reading this post from Ivan Pepelnjak where he mentions about NEC needed to implement certain features to their ProgrammableFlow controller to provide better stability, but at the potential cost of not being compatible with other vendors – the very thing OpenFlow was designed to support.

It may also be of note that I spent most of my day today working on some integration testing between Juniper MX and Cisco ASR9k routers to facilitate Multicast across Point-to-Multipoint MPLS LSPs. Part of todays work involved finding out exactly which parts of the “standards” were best supported across both vendors while not taking advantage of either vendors “nerd knobs” and “enhancements”. Sometimes each vendor had implemented different solutions to get around an “on the ground problem”, and it was partly my job to which ones played nicely across both – and with the least downtime.

So my thoughts (and I dont have any answers… just thoughts), come down to “What is better? Implement a standard, then put fixes and extensions on top of it to do what I need, or to build a new protocol?”. To a degree having “some form” of integration between vendors is very important, but if the 95% use case is making use of proprietary extensions then have we really achieved that? People ask “Why did Cisco come out with onePK instead of OpenFlow?”, but then I question “Well if they wanted to provide more functionality than OpenFlow provides, why extend the model with non-interoperable parts and pretend to still be OpenFlow?”.

Just like speaking the same language but still not understanding each other, how should we ensure better communication while not causing unneeded long term pain? Maybe the answer is to implement extensions, then work with the community / standards bodies to allow cross vendor in the future (and still provide first mover advantage for the innovator). Obviously commercials around this make this a less attractive option for the big players, but this is how standars get retroactively created.

I would be really curious to know your thoughts.

While trying to get the mix just right, my mind keeps going back to a comment I made last week on the “APAC Virtualization Roundtable” podcast (Episode 74 “SDN & Virtualisation from a Network Engineers perspective”)…

“Increase the awesome, remove the mundane!”

While initially sounding facetious, this comment is kind of where my brain has been going of late when trying to work out where I should focus my energies. While I’m thinking of ways to apply this idea to many aspects of my life, I would like to present them in the context of the presentation I am about to give (and the same context to which I spoke about in the podcast).

So I present to you my, modified, task prioritisation filter…

Remove the mundane

It’s a simple statement of fact that I get bored easily. It’s part of the reason why I blog so rarely… it’s hard for me to concentrate long enough to string sentences together once my work day is over! Another statement of truth is that I am lazy! I don’t like doing things over and over again. I believe that every network engineer must truly understand how the parts of the network interoperate together – be it Spanning Tree, OSPF, MPLS or firewalling. To do this, we need to get our hands dirty and “string tin together”. I also believe that there are only so many times we should do this by hand. Once you “know” it, automate it! By doing this you are not only speeding up the time it will take you should you need to do this again, but you are also effectively “documenting” the process in such a way that it records what has been done and allows other engineers to benefit immediately.

Now the realities of my day job mean that I cannot just refuse to do certain tasks because they are boring, but I can start to work smarter not harder. I really need to start automating the regular tasks I do in such a way that when I am required to do them, they can be done with a few taps on the keyboard or a few clicks on a website. Once I have automated these functions it then becomes easier to offload that to somebody else (i.e. make it their problem!).

This is why I’ve spent time over the past few months learning to code in Ruby (Ruby just works the way my brain works, I am sure Python is wonderful too!). This is also what tools like Puppet and Chef allow us to do. By moving our repetitive workloads into automated scripts, and starting to adopt aspects of the “Infrastructure as Code” mentality, we can start to make the boring and mundane tasks something we can spend less time doing.

I’m going to work on a series of posts about “Removing the Mundane” over the next couple of months, as I investigate and experiment with how automation and orchestration can improve the daily workflows for both myself and my customers.

I also honestly believe that “SDN” (such a loaded term!), will go a long way to helping us automate traditionally labour intensive tasks. Whether we are talking methods to directly program ASICS, or building overlay networks using protocols such as VXLAN, NVGRE or MPLS, the ability to define a service end to end and apply that as an atomic action across the network can not be underestimated.

Increase the Awesome

So now that we have freed up all of this time for ourselves, what should we do?

I am not sure if I am just old and at that stage of my career, or if I am just falling for industry buzzwords, but over the past 12 months my viewpoint of my role as a network engineer has changed. Despite what we might think, our customers are not buying stretched VLANs, VPNs, or TCP port 80 and 443 opened on the firewall. What they are “buying” from us is an application that provides a service. The skills I bring to the table are ability to deliver that service from where its hosted (whether in the cloud or our own data centres) to where it is consumed by the user, while also maintaining quality of service, privacy and responsiveness to ensure the best user experience.

The definition of this service include:

• All of the database, application, and front-end servers that the app depends
• Any storage requirements for the servers
• Any load balancers, and firewalls along the path that provide for scale
• Any layer 2 and 3 networking requirements required to allow the above components to operate
• … and probably many more I cannot think about right now!

If we can start to define the end to end requirements of the services we need to deliver and have them deployed orchestrated in such a way that they do exactly what they need to do, when they need to do them without our intervention we can begin to focus on actually delivering better applications and services to our end users. This is what I mean by “Increasing the awesome!”.

Once we take our focus away from the repetitive and mundane we can focus on delivering better services. The “server guys” learned this during the virtualisation craze, and put it to the ultimate test with “cloud networking”. Once the mundane task of spinning up servers and deploying “the standard stack” of applications was removed and servers could be deployed in minutes (sometimes seconds!) a whole new world of possibilities were opened up. It was no longer a pipe dream to spin up and down web servers on demand to meet demand (and reduce cost). Another benefit was the ability to focus on horizontal scalability by taking advantage of load balancers, Message Queues and scalable distributed databases because it became easier to deploy additional servers to a task instead of just larger ones!

Do I know what “awesome” is for the networking industry? Well other than beers paid for by vendors… no, but I certainly know that while we’re all focusing on mundane tasks, we are not focusing on delivering the awesome!

Deliver your Space Jam

This last one was not actually a part of my original comment, but its inline with what I have been thinking about. I am not sure if you have seen this “Pep Talk” by Kid President or not, but I urge you all to watch it.

I actually have a weekly reminder in my calendar for 2pm on Wednesday (Hump Day) with that link to “inspire me”. In line with “Increasing the Awesome”, you need to find something you are passionate about and work towards delivering that. Right now, I am working through a couple of things that I believe will make the “world a better place” while still utilising my professionals skills. Satisfaction in life comes from using what you do well to achieve a worthy goal.

What’s your Space Jam?

Now how will you work to deliver it?

Mop and Bucket

Our industry might be changing, even if it is unclear in which direction, but we need to focus on the best way to deal with these changes. We need to stop being road blocks, and start working with other technology teams, as well as the business as a whole, to make each others lives easier so that we can all focus on delivering more awesome.

(And to make sure this isn’t all just airy fairy rubbish… more awesome delivered the right way also means more customers thus more revenue – and happier ones at that!)

Disclaimer: I’m not going to claim these thoughts as anything original by me, I know for a fact I stole the “Increase the awesome” line from somebody who presented at a conference I watched on youtube, but for the life of me I cannot remember who or where. Having said that, this doesn’t change the fact that the message is true!

Update:

I found the original source of the “Increase the awesome” and I feel I must include it here. THANK YOU NASA!

It was about this time last year that I posted about my second JNCIE-ENT lab attempt, and sadly it didn’t go the way I wanted it to!  Due to work commitments I was not going to be prepared to sit the 2012 Q3 round of lab offerings, so I resolved to sit the December / January round.

I picked up my studies again and worked on my weak areas noted during my first two attempts. I paid particular attention to areas of multicast and switch security as these two topics were areas of weakness for me last time. I was lucky enough to work on a project at the end of last year that included nearly 1000 ports of 802.1x with dynamic VLAN allocation, so that proved to be an excellent “lab environment” for me.

After a need to reschedule for March, as the January exams were cancelled in Sydney, I knew I was going to do everything in my control to pass this time around. I didn’t want to face the thought of making attempt #4!

Long story short this time around I felt much more prepared and actually finished with more than enough time to go back through all of the questions to confirm the points I believed I had earned. I cannot say enough about good time management efforts during the lab. Set a maximum amount of time per question (or per point) and really make yourself stick to it. Unless you know you need this question to continue on to later questions, just leave it as it is (preferably in a non-broken state), and move on to other questions. Earn more points and come back later.

I finished up the exam reasonably confident, but I also knew I felt confident after attempt #2. I caught a train home and prepared myself for the 15 business day turn around for the exam results. Luckily I didn’t have to way this long to get my results, and after a couple of days I was advised that I had passed!

I am now JNCIE-ENT #368… and Im very happy / relieved

In previous posts Ive covered tips and tricks etc, so I would really like to dedicate this post to saying thanks to people.

All my thanks

• First I would like to thank Liz Burns and everyone at the JNCP team. Thanks for all the work you guys have put in to making these exams and the encouragement you provided me over the past three years has been must appreciated.
• All of my current and former co-workers. Thanks for the opportunities I was given to work on real life network environments and exposure to quirky designs. Also there is no end of thanks for putting up with me on all those days I had my cranky pants on
• All of my current and former customers. Without your need for new networks, and not to mention some of the crazy requests you have thrown at me over the years, I wouldn’t be able to get my head around some of the tricks of the lab.
• Thanks to my friends at Juniper, most notably Francois Prowse, Ashton Bothman and Doug Hanks. Again thanks for the encouragement and the kick in the butt I needed not to give up. Many people from within Juniper were invaluable in answering many of the problems I ran into while studying.
• To everyone on #juniper over on Freenode. Much appreciation for your advice… “hrmpf“
• To Chris Jones and the guys at Proteus Networks. I was lucky enough to be performing “Technical Editing” duties on the new Proteus JNCIE-ENT Preparation Workbook (which was obviously pre-release at the time). As part of this I labbed almost every scenario from the workbooks to ensure they were correct and the descriptions matched. I cannot recommend this guide enough to people studying for the JNCIE-ENT, and I plan to do a separate review in the near future.
• To Burkey and to Nick. I hope you guys both know what your support meant. #FHP
• To “The Wolfpack”. ARRRROOOOOOOOOOOOO! You know who you are, thank you for allowing me to “de-stress” and express myself in some pretty non-conventional ways
• Last but not least, to my wife Belinda. Thanks for all the love (and feeding) during this journey. You suffered more of the cranky pants than anyone else, and yet you still encouraged me to keep going. Love you heaps

Maybe I have ADD, maybe I just need to focus, but I have found that constantly having different projects going allows me to satisfy these tendencies. I feel I work better with more than one thing to occupy my time. I see friends who work for enterprise customers who spend their days submitting change requests that third party support companies fulfil, or spend months writing detailed design guides for projects that inevitably get canceled and all that time is spent without getting to touch the things they got into this industry for. Which brings me to my first point…

Toys, Toys Toys!

Im 32 years old, and I still love toys. Sometimes I think the only reason why Im in this industry is the ability to play with expensive and complex toys. And I get paid to do it! I enjoy the challenge of learning a new piece of equipment and deploying it into a customers network. I enjoy learning all the new opportunities that a new software update or a router line card can offer to my upcoming network designs (my sales guys also enjoy being able to sell those things to existing customers… bloody sales drones!).

I have worked at my current employer for 10 months now and in that time I have worked on many projects, not the least of which has included rolling out the second Juniper QFabric deployment in Australia (and one of the first in the world), delivering security solutions based on high end data centre SRX devices including IDP, SSL Inspection and Proxying, a relatively large Juniper MAG deployment across multiple sites with failover, and numerous network audits across many verticals including finance, utilities, enterprise and service provider networks.

The other aspect to toys is the ability to get your hands on all the right equipment to learn and play with *before* you need to deploy it. This really comes into its own when you have…

The right employer

Ethan’s posts hinted at being burned by his previous employer. I know I can attest to that over the past 15 years Ive been in the industry. Sometimes its the customers, sometimes its the employer. The right employer will understand your career aspirations and will endeavour to provide you with all the resources you need to be successful during both your time with them as well as your career beyond them. The right employer understands how often engineers change jobs in this industry and that what goes around comes around.

Your employer needs to understand that certification is beneficial to him, but more importantly that you as the engineer need to understand the content of the exams you are passing. Perpetuating the degradation of industry certifications by promoting brain dumps or becoming a “puppy factory” for certifications churning out sub-par engineers devalues both the certification as well as your ability to sell your services to customers.

The right employer will cover your expenses for gaining certification, and provide you with the resources, both equipment and time, to actually complete these career goals.

If you’re lucky your VAR will give you access to both pre-sales and post-sales implementation work giving you a wider view point of the network life cycle as well as building up skills that end customer engineers will never get to practice. And you will do that many times a week!

Honest about the downsides

• Youâ€re supposed to know everything: I agree with Ethan that this can be stressful, but it doesn’t take long to pick up the habit of either being one google search ahead of the others, or as I often say “Not knowing the answer, but knowing where to find them”. If you work for a consulting firm that doesn’t require your customers to buy some form of vendor TAC support then you are further against the wall and you/they are not operating in your customers best interest. *Always* have the ability to escalate.
• Youâ€re a commodity: Yes you are a commodity, but you also are (should be) “in demand”. If you are doing your job well, and your employer knows how best to leverage your skill set appropriately (not always in your control) then this works in everyones favour. If you are not doing your job well then you shouldn’t be a consultant, and if your employer doesn’t know how to effectively sell your skills you should be looking elsewhere. You will get abused, ignored and eventually get bored and quit or made redundant. Scary truth, but its better to move on and find something you are happier doing.
• Youâ€ll sacrifice your body if youâ€re not careful: Well I’m not even going to pretend to deny this one. I am living proof that ignoring the health aspects of your life will creep up on you, but Im not convinced this is specifically related to VAR lifestyle. Any high stress, fast paced career can do this to you. You just need to keep these things in check. On a side note to this one, I’ve taken up a Paleo/Primal lifestyle for the past couple of months and Ive found wonderful improvements to my health without major sacrifices (in both time and diet), but thats a whole other blog post!

Mop and Bucket

Yes working for a VAR can be hard work. It can be fast paced and involve a lot jumping between contexts, but if you are like me you just may find that the very draw card to this career option.

Sometimes I dream about working on a single network and finishing all those “little things” that I wish I could implement for all of the networks I build. Then I spend two weeks onsite at a customer and all I want to do is get out of there.

If you are willing to invest 12 months of your life to “give it a go”, you will learn far more in that time, and touch a wider array of equipment than you could hope to touch in 3 technology refresh cycles at an end customer.

And this is what keeps me coming back to work tomorrow!