Archive

Category Archives for "Russ White"

Why I Support Certifications

I’m betting that I could take my certifications off my resume and still have a fair chance at finding a job. It’s a guess, of course, and I’ve never tried any sort of an experiment towards finding out, but the point is this: at some point in your career, certifications should become just one more thing on an excellent resume, rather than the focal point of your resume. Given this, why do I still support certifications? To answer this question, I need to back up into the certification development process a bit.

One of the strangest “mind trips” I’ve ever encountered was working with the “psycho’s” (psychometricians, really, but you know how engineers are with long words) through the entire CCDE/CCAr process. The two things we were challenged constantly were:

  • What does the minimally qualified candidate look like?
  • How do you intend to test for that skill?

Both of these are hard questions.

The first question we turned into a simpler one (again, you know how engineers are): Why do I care? When someone would suggest a particular question or skill, they were immediately met with the counter — Do I care? If I were a designer working on a Continue reading

Worth Reading 06:19

Much as I’ve been trying to keep up on interesting stuff to read on the right column, I still seem to have built a long list of bookmarks! Having nothing better to do on a Friday morning, I’m dumping them on your.

So there! :-)

I’ve posted in the past on the problems of the IT job market. Primarily I think it’s too much about “what narrow set of skills do you have,” rather than, “are you a good engineer,” and I think we engineers are as much to blame as anyone else for this. “Yeah, but do you know about the latest gobberfubble embedded fingernail pick API??” we say with pride, trying to find something we know about the person we’re interviewing does. Interviews shouldn’t be about making yourself feel better about your technical skill — they should be about finding a good engineer for your team. Okay, I’ve ranted long enough — it’s time for Infoworld to take over on this score with more practical advice.

The Midyear State of the IT Job Market.

By the way, I know my response to the esoteric game won’t work for everyone, but whenever someone gets me into this position of Continue reading

Anger

"

I suppose that when one hears a tale of hideous cruelty anger is quite the wrong reaction, and merely wastes the energy that ought to go in a different direction: perhaps merely dulls the conscience which, if it were awake, would ask us, “Well, what are you doing about it? How much of your live have you spent in really combating this?”

" C.S. Lewis —

LinkedInTwitterGoogle+FacebookPinterest

The post Anger appeared first on 'net work.

Review: Building Microservices

bulding microservicesBuilding Microservices
Sam Newman
ISBN: 978-1-491-95035-7

Scale out where you can, scale up where you must.

Someone, somewhere, should probably start a collection of “where you can, where must” sayings, as these rules of thumb (thumbs were used by carpenters instead of a ruler to measure an inch, apparently) are important to remember, even if they’re imprecise. Route where you can, switch where you must — really refers to using layer 3 versus layer 2 networking as much as possible — for instance. Scaling out, from the perspective of network engineering, is all about repeatable modules, spine and leaf fabrics, and distribution of the control plane (didn’t think of that last one, did you?).

But what does scaling out mean in the application development world? It means splitting services into modular pieces which interact over the network. The ultimate goal of splitting services is to get to the microservice.

But what is a microservice?

To answer this question, you need to turn to the first chapter of Scaling Microservices, which says, “Microservices are small, autonomous services that work together.” Sam Newman, in the rest of the first chapter, explains the concept well, from a number of different angles, Continue reading

Worth Reading: SD-WAN and Per Application Routing

SD-WAN Gives Us The Best Path We Always Wanted

Of course, routing on a per application (or a per packet) basis provides more optimization, but it also adds more state in the control plane, and it increases the speed at which that state changes. In my forthcoming book on network complexity, I’m going to work around a model of state/speed/surface, with a side of optimization, to gain an understanding of network complexity and how to manage it.

The post Worth Reading: SD-WAN and Per Application Routing appeared first on 'net work.

Explain-a-holic (Communicate Clearly)

But just a couple of days ago, I was talking to someone about managing expectations in the IT world. How do you convince someone else to buy into a project? How do you get them to back your idea, rather than inventing their own? While the question itself is interesting, I’m going to leave my thoughts on it to another post.

What I realized, halfway through answering the question, was that I was sucking up a lot of time talking about things that probably didn’t matter. I was spending time talking about the problems of getting people to own the problem, or make them believe they’d invented the solution, and specific projects I’d been involved in where we could never convince a wide group of people to buy into our ideas and solutions.

At some point, I’m certain I sounded like this snippet from a recent email —

Like if I asked, “what is 1+1?” he might say, “one takes 1, and adds 1 to it, and you get the next integer, which is really quite interesting, because you can do this over and over again, and never get the same answer, which is a bit like…”

There are, Continue reading

Worth Reading 06:12

According to the Data Center Journal:

What’s the problem with IT resumes? They’re useless.

The real problem with IT resumes, though, is we want to see a long list of technologies, because we want to find the specific technology we want to implement (or are implementing) — rather than a good engineer. The hiring process is a fishing expedition rather than a search for solid talent and personality fit. If we want to fix this problem we can. The question is — do we want to?

Bruce Schneier has some wise thoughts on airport security this week

We don’t need perfect airport security. We just need security that’s good enough to dissuade someone from building a plot around evading it. If you’re caught with a gun or a bomb, the TSA will detain you and call the FBI. Under those circumstances, even a medium chance of getting caught is enough to dissuade a sane terrorist

Replace “airport” with “network,” and you get the drift of where network security is going, I think. Of course, there’s the reality that you can’t stop insane attackers… Worth remembering. The same point can be made for network uptime, by the way. Perfection is Continue reading

An Example of Obsfucation

With reference to the Verification exercise embarked upon as a result of the Payment Claim Application received from you on the settlement of the subsidiary contract payment on the Over Due Contract Resettlement, I wish to inform you that a Provisional Approval have been given to recognize your claim and consequently commence the final process of the payment regularization, validation and release to you. By Standard Chartered Bank.

When you read a sentence and think, “I don’t know what that says,” it generally means nothing was actually said. IE — it’s spam.

The post An Example of Obsfucation appeared first on 'net work.

Rethinking Centralization

In general, my line of thinking here is this: some things work well when they’re distributed, others work well when they’re centralized. Our bodies have a “central nervous system,” which is tied to a single point of failure (the brain), though our brains turn out to have some redundancy. On the other hand, other systems in our bodies are distributed, such as our reaction to being cut (and bleeding to death). What we need to start doing is thinking through what works well where, and figuring out how to move each one to that specific destination.

Another parallel in this space is what we’re facing now in application development. We like to say that we’re moving towards the cloud — which means thin clients and thick servers. The reality is, though, services are being broken down into microservices and distributed, and a lot of the processing that takes place does so on the client side by code pushed there from the server. In other words, our belief that the cloud “centralizes everything” is an oversimplification.

Taking one step back, we can always build centralized systems that scale to today’s requirements — the challenge is that we don’t know what tomorrow’s Continue reading