In the beginning there was a simply acronym: MTTI (mean time to innocence). Weary after years of costly and time-consuming war room battles, IT organizations turned to AppDynamics to give an objective application-level view of production incidents. As a result, application issues are swiftly pinpointed and fixed, accelerating time to repair by up to 90%. In fact, gravitation towards fact-based constructive issue management spawned a whole new movement – DevOps – with the goal of ingraining this maturity and cooperative spirit into IT organizations from the ground up. The movement was discussed by Jim in a previous blog post. Of course, AppDynamics (or at least, easily accessible fact-based information about application behaviour in production) is a necessary prerequisite to this.

loud providers Google, AWS and Microsoft are doing some spring-cleaning - out with the old, in with the new - when it comes to pricing services. With the latest cuts, here's a news flash: There's a new business model driving cloud that is every bit as exponential in growth -- with order of magnitude improvements to pricing -- as Moore's Law has been to computing. Let's call it "Bezos' Law," and go straight to the math

We've talked before about the bifurcation of the network, which is driven as much by the evolution of network services from "nice to have" to "critical" as it is by emerging architectures. The demarcation line in the network stack has traditionally been - and remains - between layers 3 and 4 in the OSI model. The reason for this is that there is a transition as you move from layer 3 to layer 4 from stateless networking to stateful networking.

Like moving to IPv6, simply picking up your existing network architecture and moving it to a completely new one is not going to happen overnight. There will undoubtedly still be "traditional" networks hanging around even when SDN adoption is considered mainstream and fully mature. That's the nature of evolution; it doesn't happen in the blink of eye, it takes time. Right now organizations are faced with a variety of options in networking. From VXLAN to NVGRE, from traditional to software-defined, choices abound today. And chances are that most largish networks will actually take advantage of several of those choices, depending on what phase of adoption they're in.

Appthority is an app risk management company with a Software-as-a-Service solution that analyzes mobile apps for hidden behaviors that pose privacy and security risks. Our main customers are large organizations and we provide them with the first all-in-one App Risk Management service to uncover the hidden actions of apps and enable enterprises to create custom policies to prevent unwanted app behaviors. Appthority combines the largest global database of analyzed public and private apps with advanced policy management tools to automate control over risky app actions to protect corporate data on company-issued and BYOD mobile phones as employees bring their own apps to work.

Like every one I am updating my terminology to reflect the shift that occurred – Business and technical executives immediately get that when combined with a world of smart, connected devices then Cloud computing only makes more sense. We have entered an age where IoT Cloud Computing will become the dominant form of enterprise IT architecture. Smart devices aren’t much use if they aren’t sharing their feeds with some kind of enterprise system, and so new forms of middleware as well as entirely new forms of ERP will emerge too. In short how will that RFID device on the tin of beans ordered by your smart fridge, actually place the order into the supermarket logistics systems?

This past weekend, like many of you, I started getting the blood curdling password resets from a bunch of OpenSSL affected sites. I also got a few emails from sites indicating that I had nothing to worry about. Bad news, good news. Probably the biggest security story thus far for 2014 is Heartbleed, the OpenSSL vulnerability which potentially allows attackers to extract 64 kilobyte batches of memory at random without being noticed and leaving no trace. Sounds like the perfect crime.

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.

The Information Technology Acquisition Advisory Council (ITAAC) and the Telecommunications Industry Association (TIA) are announcing a slate of innovative leaders to serve as facilitators for the upcoming "Agile Sourcing Environment for Commercial Cloud" brainstorming session being held in Alexandria, VA on April 23, 2014. Enjoying a great response thus far, industry participants include Boeing, Oracle, Google,SAP, Leidos and Capgemini. Government participants include the US Navy, US Army, US House of Representatives and GSA.

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.