SolarWinds has seen many product releases in the last week, including a new free product called Alert Central, and one of the products I’m responsible for marketing—Server & Application Monitor (SAM). The new version 5.5 is feature rich and truly demonstrates this product’s maturity. SAM now delivers server monitoring for more than 150 applications, as well as brand-new remediation features like starting/stopping services, killing processes, and rebooting servers.

What’s really impressive to me is how far this product has come since its birth in 2008. From a software development perspective, SolarWinds kills it with its ability to rapidly develop and deliver quality, function-packed releases. I’m not sure how the dev team maintains such high energy. Maybe they’re energized by our CEO’s pep talks, or the funny t-shirts, free snacks, and caffeine. Most likely, they’re glowing from the praise of our customers.

Whatever it is, I’ve noticed a few things that work really well around here that I wanted to share. Here are some SolarWinds tips for speedy software development.

1) Start with solid interactive design. This aspect of software development, along with having a high-quality (not buggy) product, is what makes my job as a product marketer SO EASY! Just yesterday I interviewed a customer on why he chose SolarWinds, and he said “The product just worked—it was easy to set up and easy to understand.”

Without solid interactive design, a company must spend a lot of money on pre-sales engineers and professional services staff. Sometimes developers are pulled away from their regular workload to assist customers with implementation. This gets in the way of developing quality software in a timely manner, and can erode revenue because marketing and sales teams have nothing new to talk about!

2) Prioritize features that will benefit all of your customers. This requires discipline. Sometimes it’s not sexy to work on features that everyone needs. Many companies go for developing the next cool feature that really only 2% of customers need. It becomes very easy to develop a feature that’s of little use to the typical customer. Even worse, add a few of these together and your product becomes a Frankenstein that’s difficult to understand, use, develop, or migrate.

When you develop features for everyone, you mitigate risk for everyone in your company. Your development plans will be more solid, and your sales and marketing organizations will have more flexibility to sell to a broader base.

3) Focus on DevOps across the company. DevOps is traditionally defined as “emphasizing integration and collaboration between development and IT operations to aid in enabling scale and speed while reducing errors in products/applications.” This concept is similar in nature to supply chain management, which is a total systems view of how to link processes throughout the company for maximum customer satisfaction.

That’s what I’m talking about: Applying that concept to product development and delivery, to extend DevOps to all the functions that touch a customer. Every function in the company touches the customer in a different way. Integrating systems reduces manual mistakes and speeds up deployment time but, more importantly, each function is involved in the QA process. This is not only important for catching bugs errors (e.g. broken links, inaccurate wording, etc.). It’s also invaluable when working through a new process or product, or during a major organizational change, like an acquisition.

Check out this blog to learn more about SolarWinds’ UX process, or view this page to find out about the latest release of Server & Application Monitor.

Software-Defined Networking has become one of those industry buzzwords that quickly gets so over-used and distorted that it is hard to tell what it really means or if it really matters.  In this blog post I’ll try to go back to the basics of what is SDN and how it is likely to impact the network administrator.

SDN was defined by the Open Networking Foundation (ONF), a standards group founded in 2011 by Deutsche Telekom, Facebook, Google, Microsoft, Verizon, and Yahoo!, as an architecture that “brings direct software programmability to networks worldwide.”  ONF is pushing this goal by defining and driving an OpenFlow interface.  The ONF website describes OpenFlow as follows:

“In a classical router or switch, the fast packet forwarding (data path) and the high level routing decisions (control path) occur on the same device. An OpenFlow Switch separates these two functions. The data path portion still resides on the switch, while high-level routing decisions are moved to a separate controller, typically a standard server. The OpenFlow Switch and Controller communicate via the OpenFlow protocol, which defines messages, such as packet-received, send-packet-out, modify-forwarding-table, and get-stats.”

So the basic concept is pretty simple, move the control functions into a software layer that talks to the hardware layer which still moves the data.  The key benefits of this approach, especially if all hardware devices used the same interface protocol, is that it would be much easier to programmatically provision network resources and automate configuration tasks at a common software control layer.

This is largely what happens today in server virtualization.  A software virtualization layer interfaces with the applications and manages the underlying physical compute resources (e.g., CPU, memory, disk, etc.).  This abstraction has enabled a number of key capabilities including rapid provisioning, VM/application mobility, thin provisioning of storage, etc.

Big Vendor Positioning

The idea of abstracting the intelligence from the hardware naturally leads to the conclusion that the network virtualization layer would then be able to run on commodity networking hardware.  This is not a scenario that is likely to be very appealing to Cisco and the other big networking hardware vendors.  Looking at a parallel example in server virtualization, HP, Dell, IBM and others still sell a lot of servers even though VMware provides the most common virtualization layer.  However, it is getting harder and harder to maintain any differentiation at the hardware layer which is driving commoditization and squeezing profit margins – not an appealing vision for Cisco and the other vendors who would be happy with the status quo.  Larry Dignan’s article “Cisco makes its software defined network case: Do you buy it?” does a nice job of diving into the Cisco perspective in more depth.

In July 2012 VMware stepped into the picture in a big way with their acquisition of Nicira who has been focused on network virtualization using an SDN approach.  VMware is the dominant player in the server virtualization market so when they acquired Nicira for $1.05B it caught many people’s attention.  At VMWorld 2012 in San Francisco this past August, VMware continued to hit the theme of a Software-Defined Data Center that encompasses servers, storage and networking.  The positive side of VMware’s interest in SDN is that they have enough market presence already in the virtualization space that the other big players now have to be serious about moving forward with a SDN strategy of their own or risk losing their existing markets to VMware.  On the other side, VMware already has enough market power with their server virtualization capabilities.  It is scary to think about what they could do if they are able to successfully extend that dominance across both storage and networking as well.

So what should we expect from the big vendors like Cisco, VMware and others?  The typical approach for those vendors would be to talk a lot about their SDN strategy, claim open SDN capabilities within their products and pursue activities that have some SDN capabilities while keeping it proprietary to their product line so that they can maintain control of the customer.  With the existing VCE partnership between VMware, Cisco and EMC it will be very interesting to see how this dynamic plays out across network and storage.

How will this Impact the Network Administrator?

If history is any guide, the first challenge the Network Administrator will have to face is wading through the proprietary vendor features or capabilities marketed as SDN.  The admin will need to determine where there is real value, what is designed strictly to lock you in to a vendor, and what is just marketing hype.  In the longer term, SDN has the possibility of being a valuable capability that enables a transition to a more flexible and efficient network similar to what has happened with server virtualization.  With standardized, open SDN capabilities, the network admin would be able to programmatically automate key provisioning, configuration and management tasks.  This would allow more time to focus on business requirements and overall network optimization and less on device-level tasks.   As this transition occurs, probably over the next two to five years, the network admin will want to make sure they are at least keeping up with those changes.  By updating skills they can become the equivalent of the VMware (or Hyper-V, KVM, etc.) admin that can manage the physical server too instead of just being the legacy server admin.

Drawing another parallel, as the network virtualization layer does more, it will be harder to connect what is happening at the application layer down through the virtualization layer to the physical infrastructure.  The network administrator will want to make sure that they can monitor the network and maintain visibility from the application and virtualization layer down into the physical infrastructure.  This visibility enables both system troubleshooting and optimization.   For optimization it ensures that physical capacity aligns with the virtualization demands.   For troubleshooting you can quickly understand where network traffic monitoring or other analysis is needed to identify where the real problems are occurring and what the impacts are.  Keeping that end-to-end mapping capability from the network hardware to the network consumers will ensure that the network admin remains a critical part of the overall data center team.

While this change is likely to happen over years instead of months, it is always good to use change to your advantage as opposed to being caught napping.

By Mike Thompson, SolarWinds Networking Product Marketing Manager; on twitter @michl121

Want to be a guest blogger? Contact ITKnowledgeExchange with information about your company and/or proposed topic.

Disclaimer: ITKnowledgeExchange hosts this blog for informational purposes only. The ITKnowledgeExchange Team does not personally endorse any of the opinions, products or services posted here. Please contact individual bloggers with questions or comments about any posts.