When I visit clients to talk about DevOps, I usually ask them what their monitoring strategy is. Too often, the answer I hear is "We use Nagios". I think Nagios is a great tool, but it sure is not a strategy. Nagios does a good job of monitoring infrastructure. It will alert you when you are running out of disk, CPU, or memory. I call this reactive monitoring. In other words, Nagios is telling you that your resources are getting maxed out and you are about to have issues. Proactive monitoring focuses more on the behavior of the applications and attempts to detect when metrics are starting to stray away from their normal baseline numbers. Proactive monitoring alerts you that the system is starting to experience symptoms that can lead to a degradation of performance or capacity issues which is more preferable than Nagios telling you are about to be screwed. With reactive monitoring, it is not uncommon that customers start complaining about the same time that the Nagios alerts start going off. The goal of proactive monitoring is to head off issues so that customers don't even notice.

One of the most powerful aspects of the Internet of Things is the process of synthesis it achieves; it provides a mental model for people to associate and relate a number of different technologies under one umbrella concept and trend. Therefore one early quick win is a simple taxonomy for listing what these different technology camps are, so here is a first draft approach for this that is now included as the guiding framework in our IoT Technology Roadmap.

OpenStack. OpenDaylight. SDN. Cloud. It's all about abstraction, about APIs and "software-defined" (which really means software-controlled, but this is neither the time or place to get into that debate). It's about jailbreaking the network. Enabling access to features and functionality in a way that results in new services, increased responsiveness and overall, the operationalization of the network.

Not too long ago, it took even the most successful entrepreneurs several centuries or at least decades to reach a valuation of a billion and thus become a member of the exclusive Billionaire Boys Club*. Families like the Rothschilds, the Waltons or the Brenninkmeijers have indeed built up impressive capital wealth, but because it took them several generations, it often became quite diluted among brothers, sons, daughters, nieces, and even third-degree-nephews. With the advent of first: IT; then the Internet and now the cloud, that time frame has rapidly shrunk. Today companies with as little as 50 or even 13 employees reached valuations where reputable companies and world-renowned artists can only dream of. This acceleration is even more poignant when we look at applications in the heart the nexus of Social, Mobile, Cloud and Analytics (SMAC), such as Instagram , Tumbler and recently WhatsApp. And just like in the music industry there is a lot of interest in the tip parade: the list of runner ups; ideas and products getting ready to become the next mega hit.

Despite claims that there exists (or will, look out!) a mythical "god box" for the enterprise data center, capable of performing every data center function imaginable, it remains, well, mythical. Efforts to effectively secure the data center and the applications it delivers therefore requires a collaborative approach between best-of-breed technologies. But if collaboration across functional IT groups - development, operations, network and security - remains as elusive as nirvana, then collaboration across products has traditionally been seen as likely as sighting the Loch Ness Monster. The arrival of cloud and more recently SDN has changed that, not only encouraging but requiring changes in collaboration capabilities in order to remain considered best-of-breed.

We love analogies. No matter what the topic, analogies are a great way to explain something in a different context to make a specific point with a frame of reference that may be more familiar to those we are making a point to. There is one that seems to come back over and over again in our industry, the one that compares the network to the power grid, network connections to power plugs. I had not heard it for a while but at Interop last week, I heard it used twice in booth demonstrations as part of plug and play pitches. And I really do not like that analogy.

There is probably never going to be a perfect balance in the industry between Do-it-yourself (DIY) and Do-it-for-you (DIFY) networking. It seems exceedingly unlikely that there is a one-size-fits-all type of solution out there. And so we will invariably end up with a bifurcated market that requires multiple solutions for its constituents. But if there is not a perfect balance, which one of these is likely to see the most action? If you were to base your guess on industry chatter, you would have to conclude that DIY has the upper hand. There is a ton of momentum right now with both SDN and bare metal switching. On the SDN front, it is all about orchestration and automation. The ability to streamline customized workflows is attractive, especially for the large IT shops that sink tens of millions of dollars into managing their monstrosities. Once you get into anything that is customized, there is a degree of DIY-ness that is required. No product is designed expressly for your particular environment, so you need to the ability to customize what you buy to do what you want. Beyond that, there is an awful lot of talk about APIs and programmability.

There’s a new craze occurring in homes, highways, workplaces and everywhere imaginable – the Internet of Things or as I like to call it, The Internet of Nouns. Sensors, thermostats, kitchen appliances, toilets and almost every person, place or thing will have a chip capable of connecting to the internet. And if you want to identify and find those things with recognizable words instead of a 128-bit IP address, you’re going to need DNS. DNS translates the names we type into browser or mobile app into an IP address so the services can be found on the internet. It is one of the most important components of the internet, especially for human interaction. With the explosion of mobile devices and the millions of apps deployed to support those devices, DNS growth has doubled in recent years. It is also a vulnerable target.

The industry often talks about how the data center perimeter is expanding,necessarily, due to technological shifts such as cloud and mobility and BYOD. But that isn't really the case. If you look closely, you'll see that the perimeter is actually shrinking, getting tighter and tighter around the data center. With just about everything web-enabled these days, the need for access to network to enable access to applications is, well, nearly gone. I can as easily share a file via a web-enabled application today as I could by copying it onto a network share using a VPN last year. With mobile devices inside the corporate walls as well as out, it's no longer effective to just implicitly trust what's on the local network.

Nick Lippis, who writes the eponymously named Lippis Report, had a fascinating report on the differences between enterprise and service provider environments with respect to network virtualization. He observes, through a survey of the ONUG (Open Networking User Group) membership, that what the enterprise needs is Network Service Virtualization (NSV), which he and ONUG define as the virtualization of "enterprise appliances, such as firewalls, load balancers, application accelerators, application delivery controllers, Intrusion Protection Systems, WAN optimizers, call managers, etc., instantiated for each application." (Lippis Report 217: It’s Network Service Virtualization in the Enterprise rather than Network Function Virtualization )

In any space, there is a very small vocal minority. Most people lack the time, interest, or even confidence to say what they think in public. So we are left with a vocal few who drive the conversation. In networking, the vocal minority consists mainly of the vanguards for change. For these people, the network is more than just some connective tissue inside a nebulous infrastructure. It is their life. They live and breathe it. Accordingly, they have strong opinions about how things work and, more importantly, how they ought to work. But what is happening now is that we are at some risk of the luminaries creating an impassable distance between their vision and the on-the-ground reality in many IT shops today.

The combination of cloud computing and big data is a match made in heaven. Big data requires a flexible compute environment, which can scale quickly and automatically to support massive amounts of data. Infrastructure clouds provide exactly that. But whenever cloud computing is discussed, the question comes up: When it comes to cloud security in a big data use case, the expectation is that any security solution will provide the same flexibility as the cloud without compromising the overall security of the implementation. When taking your big data to the cloud, the following four tips will enable you to achieve cloud flexibility paired with strict cloud security.

The CEOs of leading companies are already striving to create an agile business model -- one that responds quickly to competitive pressures and shifting market demands. Commercial agility often requires a corresponding accelerated business technology deployment. Meaning, the IT requirement is for applications to be provisioned in hours -- not weeks or months. That's a tall order for many corporate IT departments. Regardless, it must be done. More often than not, it's accomplished via a cloud services-based methodology. Savvy executives that proactively migrate their IT infrastructure to a cloud-centric architecture will generate new revenue that could surge by a factor of three from 2011 to 2017, according to the latest market study by IHS.

I am the CEO and founder of GovCloud Network, LLC. In a consultative role, I help companies develop and execute targeted media strategies via social media channels to over 1.5 million professionals across 20 industry verticals. With a specialty in cloud computing, we and our partners also provide the critical technical training and business education needed to thrive.

In the cloud lock-in is often a greater concern than lock-out*, but both should be top of mind for organizations looking to deploy cloud seriously, or better said, for organizations that want to deploy cloud for serious business. Lock-in is the phenomenon that it is often difficult (lengthy and expensive) for user organizations to switch suppliers, often because after some time the software becomes so closely linked with the way the organization works that saying goodbye to the vendor becomes virtualy impossible. It is no coincidence that there are only two industries (IT vendors and drug dealers) that routinely refer to their customers as "users".