All Posts in “Guest Bloggers”

Sometimes you have to create your own penis showing game – by Shane Walton

/ / #SeasonofGuestBlogging, Guest Bloggers, IT Career Advice, Shane Walton / Leave a Reply

Shane (pronounced “Shawn”) Walton is a retired federal employee currently working as a systems engineer for a startup cloud service provider.  A collector of certifications, he is attempting to add Cisco CCIE Data Center.   He has previously been a member of the United Stated Air Force and completed 25 years of combined federal service.  He is contrarian in nature so don’t be offended if he disagrees with you on twitter despite the probability that he actually agrees with you.  When not doing “network stuff” you will usually find him building hash cracking rigs and sniffing the airwaves for anything of interest.

I am sure most people are aware of the 2005 movie Waiting… While the restaurant industry and IT have few parallels, job satisfaction and trying to find a way to make the day to day grind interesting and challenging are a central tenant to any career. In the movie we learn that moral was very bad and no one was happy until a new employee was hired and implemented a game which is described enough in the title and won’t be described further. If you’re that interested, you can rent the movie. The point is they took it upon themselves to find a way to make work interesting and fun again.

I found myself in this dilemma after 25 years working in the same organization. For those 25 years I was lucky enough to always have interesting work. Nearly unlimited budget, an organization that was forward leaning with regards to technology adoption and always had a large project flanked by several smaller projects.

Then I left the government… I know what I described above does not sound like a government agency. Government agencies are slow to adopt, risk adverse and have almost no people capable of technical innovation but we were lucky enough to have leadership that was interested in pushing the envelope.

We were the first Federal organization to implement Cisco Nexus in our data centers. We learned so far forward we all but forced ourselves to be chosen as a location for one of the Air Force regional data centers. But that was all gone and I found myself working for a small company providing professional services (PS). That’s where I met Mike. I enjoyed working for the company. I traveled like most PS engineers, moving from project to project but nothing like I was used to. I wouldn’t say I was not satisfied but I wasn’t fulfilled. Soon I took the opportunity to stay on with a company I was contracted to.

This new job was with a small startup cloud service provider and I was REALLY happy. I had great pay, really good benefits that they paid for 100% and a culture that I loved with no travel, supporting internal engineering. Then things started to get stagnant and I wasn’t unhappy I was just bored. There were days I would sit with different configs up on all three of my screens and that would be how I was 6 hours later contemplating going home because it was obvious to me I wasn’t going to get anything done.

I wasn’t looking to leave but a friend of mine called me and said I need you to engineer and implement the first Cisco ACI capable device in the federal government. Not just the DoD, the whole public sector. I couldn’t have signed up any faster. I was chasing the great project. It was four phases, implement the hardware and test VXLAN followed an alphabet soup of new technology insertion with SDN, VMware NSX, Cisco ACI, automation and orchestration galore. It was literally a dream project with a period of performance that would provide stability for a very long time. The client was my old agency. I couldn’t have been happier.

It turns out though that sometime government contracts get hung up and back to back projects don’t always get funded in a timely manner. What I didn’t know when I took the job was that although my division of the company was making enough to float all of us on the bench for months the company was basically imploding financially everywhere else. As soon as the contract didn’t get awarded we started getting furloughed and eventually were given a choice to find our own work or be furloughed full time until we were billable. At this point I was going to take a contract with Cisco advanced services but that would have only lasted as long as that contract and continue making money for my titanic of a company so I very sheepishly contacted the cloud service provider to see if I could get my old job back.

I am now going on my 6th month back with my old company now and I am really happy. Not only am I really happy, I am not bored. Now I am building labs, working on new potential service offerings and taking it upon myself to push into different technology areas. I am going to finally take the time to finish my CCIE. I’ve finally found what I was missing in my search for post government job satisfaction.

It was always up to me to challenge myself and while it was nice to be in an environment that didn’t require me to look for interesting things to do I don’t need to jump from company to company to find it. I learned much like Ryan Reynolds and the rest of the gang that it isn’t the 100% responsibility of the company to ensure I am fulfilled in my job. Sometime you really do have to create your own penis showing game.

The Time I Bought a Raspberry Pi – by Farah Khan

/ / #SeasonofGuestBlogging, Guest Bloggers / Leave a Reply

Farah Khan is a core Systems Engineer at EMC. She received her undergrad degree in Criminology (minor in Arabic) at University of Maryland, College Park (Go Terps!) and is finishing up her Master’s degree in Systems Engineering at Johns Hopkins University. She has previously worked for a couple of different software development companies in the software testing/DevOps domains. You can find her tweeting sporadically, in between yoga classes and coffee shops.

Have you heard of a Raspberry Pi? An Arduino, a Photon, a Beaglebone? You know, those tiny palm sized computers? I kept hearing about them, but I didn’t understand the depth of their capabilities. I researched on a few, and found that the Pi was originally intended to bring computing to remote areas of the world- to spread the knowledge of technology to previously inconceivable locations. A couple engineers I spoke to highly recommended the Pi – for its price and power. The next logical thing I thought to do was to go out and buy a Raspberry Pi (I really just went to Amazon and searched for a Raspberry Pi, and ordered the first one I saw).

What am I going to do with it? Well, what I want to do is build a light show. I want to attach some LED’s to a VMAX, program the lights to be powered by the Pi… and hopefully remotely control it. I’ve been researching a dozen tutorials on LED light shows with programmable interfaces to control the lights flashing on and off. There are engineers within EMC who have been incredibly generous with their time to teach me (and others) about what they have learned.

But here’s the catch: I may have worked in software development companies, but I didn’t grow up soldering wires together. I may have deployed code updates to clients’ production servers, but I haven’t created scripts from scratch to automate a complete process. I may not have grown up an engineer, but I am learning to become one each and every day.

And that is the purpose of DCLabs- to enable an engineer to truly feel like an engineer. DCLabs is an initiative I’ve started within EMC, modeled after the famous PacLabs in the Pacific Northwest. It’s intended to reflect the natural progression towards open source that our industry is moving in (if not already there). DCLabs is meant to be an open environment where anyone can brainstorm and learn from not only themselves, but others as well. There may be folks who are a couple steps ahead of you but also started out at the same place as you. It is, by definition, a place to make stuff- whatever that “stuff” is. It’s a time and space to collaborate with other passionate individuals who may want to also learn code and eventually solve problems via automation.

Shifting The Focus of Our Security Lens – By Brian Tobia

/ / #SeasonofGuestBlogging, Brian Tobia, Enterprise Design Considerations, Enterprise Solutions, Guest Bloggers, Security / Leave a Reply

I was at a meeting recently with both the security and virtualization teams in the room and they were having trouble connecting security policies and objects that lived in each of their realms. A colleague of mine refers to this as the Rosetta Stone problem in which the security team is usually speaking a different language than the others. What is seemingly important to one team usually doesn’t resonate with the other. The two then become disconnected and one of the biggest advantages an IT team has, information sharing, can be completely lost.

So I came up with an analogy to try and help bridge the gap. Instead of looking at things in terms of IPS/IDS policy, firewall rules, vApp’s, or vDS’s, let’s think about attributes and behaviors of the one element that all teams share in common: the user. If we look at how, say medical insurance polices, are written, every trait about a person is considered and this is the core of what the policy is made up of and also how much it costs (it always comes down to dollars, right?). What if we did the same thing for security policies? If each group or piece of infrastructure that we are trying to secure could communicate back elements about a user, we could combine these all together so not only would we have a more comprehensive security policy, but we would also be speaking the same language.

In this model, security policies now become much more dynamic and rulesets that are active across devices are much more adaptive. You can move from having an environment-wide VDI policy for internal users to having a virtual machine whose policy and access level changes to fit each user as they login or logoff. This not only closes many of the gaps we have with current “Swiss cheese” firewall or security device policies, but it also locks down many communication paths that are most likely unprotected today to the most restrictive set.

I mentioned information sharing before and this is really where open standards and integration between all the security tools in an environment can play well together. The first advantage here is the ability to enforce consistent policy based on user identity across an entire infrastructure. These can be things like Active Directory Group, geographic location, login history, the nature of the access request, etc. All these ingredients can be combined together into something like a recipe that dictates what the security policy should be. For example, the security policy being enforced if I’m sitting in an office accessing servers in the datacenter or if I am connecting from an airport in a new country that I’ve never traveled to could be very different.

The other big advantage of this user-centric approach to security is the increased information flow between solutions. If you think of all the security controls in your environment as a chain of services instead of individual pieces, information about what actions have been taken or what user identity attributes are present can be passed along this chain. This now allows for a device down the line, say Device C, to make a decision or modify policy based on outcomes that have already been produced by Devices A and B. Not only can each control now be smarter by utilizing this additional information, but now you get a global view and enforcement of security policy that is making smarter decisions.

Now notice I didn’t mention any product names…that was on purpose. We’re still getting there within the ecosystem of solutions. Whether it’s open source tools, open API’s, or just vendors working together for these integrations, I hope that shifting our viewpoint from being more device-centric to the magnifying glass now being focused on the actual user will result in better solution collaboration and a wider adoption of newer security technologies. Additionally, if security teams are less isolated from being left out of the design process and also if their reputations can be a little less tarnished from all this, it wouldn’t hurt either 🙂

Brian has been an IT professional for over 10 years in various customer-facing consultancy and technical roles. He specializes in virtualization, networking, and security technologies and holds various industry certifications such as: VCAP5-DCA/DCD, VCP4/5, VCIX-NV, and CISSP. He has authored multiple courses on networking and security topics and is an active member in the industry communities. Brian was also nominated as a VMware vExpert for the past 4 years for his work within the VMware and partner communities. He currently works as a security and compliance specialist for the NSBU within VMware.