Tag: software-defined networking

  • SonicWall Adds Multi-Gigabit Switches to SD-Branch Portfolio

    SonicWall Adds Multi-Gigabit Switches to SD-Branch Portfolio

    SonicWall has added a line of multi-gigabit switches to its software-defined (SD)-branch offering that unifies the management of wireless access points and firewalls that include software-defined wide area network (SD-WAN) capabilities.

    Dmitriy Ayrapetov, vice president of platform architecture for SonicWall, said the switches will replace a series of switches that SonicWall had been reselling from Dell Technologies. SonicWall spun out of Dell at the end of 2018 after being acquired in 2012.

    SonicWall has been making a case for unifying the management of remote office networking via a central management console dubbed Capture Security Center. To achieve that goal, the company embedded SD-WAN capabilities in its firewalls while expanding its portfolio to include wireless access points and switches.

    Ayrapetov said in the wake of the COVID-19 pandemic, interest in centralizing the management of remote offices has increased for two reasons: First, IT teams are no longer inclined to travel to remote offices unless there is an absolute requirement; and second, following the economic downturn brought on by the pandemic, there’s more interest in reducing costs—an issue SonicWall addresses by consolidating the management of networking and security.

    As part of its SD-Branch offering, SonicWall also makes available client software in multiple forms, providing IT teams with capabilities such as URL filtering to block access to malicious websites that can be applied to any device on the network, including systems that employees are using to work from home. That capability makes it possible for IT organizations to enforce cybersecurity policies regardless of where employees are located or what network they are using to access IT resources in a branch office, said Ayrapetov.

    Longer-term, Ayrapetov said it’s clear organizations are moving toward zero-trust networking architecture to better ensure cybersecurity using SD-WANs and other technologies to access cloud applications. However, in the short-term, most organizations will continue to rely on virtual private networks (VPNs) to access IT resources located in a branch office, on-premises data center or public cloud.

    SonicWall has been making a case for its Boundless Cybersecurity platform, which can be broadly applied across a distributed computing environment. At the core of that platform is its Capture Advanced Threat Protection (ATP) cloud sandbox service that relies on deep memory inspection in real-time, machine learning and cyber threat intelligence to identify malware and other potential threats.

    As part of that architecture, SonicWall also provides zero-touch deployment capabilities, which eliminate the need for extensive cybersecurity expertise to deploy its appliances and services.

    It’s not clear to what degree organizations will be consolidating the management of networking and cybersecurity. However, the smaller the organization, the more likely one team is managing both networking and security. As the number of cybersecurity threats organizations face continues to rise at a time when IT budgets are under massive pressure, chances are high many larger IT organizations soon also will be consolidating the management of networking and security.

  • Cisco Moves ACI Strategy Forward

    Cisco Moves ACI Strategy Forward

    Cisco is advancing its hybrid cloud computing strategy with release of version 5.0 of Cisco Application Centric Infrastructure (ACI), a software-defined networking (SDN) that can be deployed on cloud platforms or networking equipment deployed in an on-premises IT environment.

    The latest version of Cisco ACI adds support for a transit gateway between virtual private cloud (VPC) instances on the Amazon Web Services (AWS) cloud to provide a more efficient means of routing traffic across east-west and north-south cloud computing environments.

    Cisco is also extending the networking services it provides for the Microsoft Azure cloud to include VNET peering within the Azure Virtual Network, shared service deployments, additional service automation functions.

    Via ACI 5.0, IT teams are now provided a centralized view of cloud resource inventory within AWS and Microsoft Azure along with status indicators and a set of wizards to simplify configurations.

    Cisco also has deepened the level of integration between Cisco ACI and Kubernetes as well, to increase the level of scale that can be achieved in IT environments based on platforms such as VMware vSphere.

    Finally, Cisco has added support for role-based access control (RBAC) in multi-tenancy environments along with two-factor authentication (TFA) capabilities enabled by the Cisco DUO platform. Cisco also added a more flexible policy construct, dubbed Endpoint Security Group (ESG), that can be employed to group endpoints based on L3 attributes and apply contracts between ESGs.

    Srinivas Kotamraju, senior director for product management for Cisco ACI, said the latest update to the SDN platform provides IT teams with the equivalent of many of the same networking services that Cisco historically has provided in an on-premises IT environment.

    Cisco has been making the case for a hybrid cloud computing approach to delivering network services that enables IT teams to manage those services via a central console. Rather than having to manage networking services provided by each cloud service provider, Cisco ACI makes it possible to deploy the same SDN across multiple clouds and on-premises IT environments. Cisco contends that approach ultimately serves to reduce the total cost of delivering networking services by both centralizing management and making it easier to automate the management of networking services across multiple IT environments.

    There are two primary ways Cisco exposes those networking services. DevOps teams can take advantage of application programming interfaces (APIs) to programmatically invoke ACI services. Alternatively, Cisco provides network managers access to a graphical user interface (GUI) through which they can access a command-line interface (CLI) to configure a specific router or switch.

    Kotamraju said with the rise of DevOps the number of organizations giving developer programmatic control over networking services continues to rise. It’s too early to say to what degree NetOps and DevOps teams might ultimately converge; however, Kotamraju said finding ways to meld those two groups is being discussed more frequently within many IT organizations as applications become more distributed.

    Of course, the biggest challenge when it comes to achieving that goal will be more cultural than technical. However, as networking services become more accessible via APIs, it’s now more a question of when and how than if.

  • How SD-WAN Is Driving Business Continuity in a COVID World

    How SD-WAN Is Driving Business Continuity in a COVID World

    The coronavirus outbreak has thrown the economy into flux, creating changes to entire industries that would have been unpredictable a few months ago. While demand for travel has decreased dramatically, other businesses such as grocery chains, financial services and retailers are under immense pressure to serve customers in new ways. Enterprises with thousands of employees have been forced to work from home on a moment’s notice. For the IT departments powering these industries, SD-WAN will be key in increasing visibility for newly remote companies, ensuring company data is heavily guarded and managing demand for products.

    As stay at home orders made their way across the U.S., companies with thousands of employees had to immediately start working from home, many for the first time. In other words, companies were forced to navigate a completely remote workforce with little opportunity to put the infrastructure and tools in place to support its employees. Without adequate time to prepare for a smooth transition, a number of issues arose, such as realizing that IT departments didn’t have insight into the user experience of business applications for their employees’ home networks. As a result, they were unable to monitor performance and usage patterns to anticipate potential issues for employees. IT workers were unable to remotely troubleshoot and fix networking issues, increasing pain points across teams and decreasing overall productivity.

    SD-WAN Becomes IT’s Saving Grace

    This is where an AI-Driven SD-WAN can play a major role in managing remote enterprise networks to deliver better experiences and ultimately boost productivity. By providing full visibility into what’s happening across the network, AI-driven SD-WAN solutions can ease the burden of a remote workforce by proactivity responding to real-time issues. The sources of problems across the network can be vast. Intelligent SD-WAN systems not only find the root causes of problems, but also provide solutions. This can save IT departments significant time and effort in troubleshooting an issue, improving the remote IT operational experience as well as the employee work from home experience. 

    Doubling Down on Secure SD-WAN

    Security is another network concern that comes into play when employees work from home. There is an overwhelming amount of confidential data flowing across each network, and in this new environment, enterprises must take extra precautions to ensure data is heavily protected. As employees move out of the office, they’re relying more on home and public networks, moving sensitive corporate data to insecure spaces. 

    IT teams are increasingly relying on SD-WAN to help improve network security by encrypting traffic and segmenting the network to minimize damage if breaches do occur. Secure SD-WAN incorporates security solutions including firewall, anti-spam and web filtering. These solutions work together to prevent remote employees from accidentally leaking data or causing network security disruptions that can affect the rest of the workforce. SD-WAN is critical in improving a company’s overall security posture. By implementing a secure SD-WAN solution, companies can have more peace of mind, and employees can focus on their task at hand.

    The Role of SD-WAN in Evolving Supply Chains

    As employees spend more time working and living at home, their new consumer behaviors are quickly changing overall demand and forcing supply chains to evolve accordingly. Companies have scrambled to get a handle on their supply chains, and SD-WAN has become a key component in managing the demand for products; by shifting to the cloud and integrating SD-WAN into product inventory, companies can have access to cloud resources to power their inventory systems. For example, by integrating SD-WAN into grocery store chains, individual stores have been able to communicate with each other and support constantly changing customer needs. An increased demand for yeast at one store can be balanced by a decrease in demand in another. Enterprises can use the inventory system to allocate their products accordingly and record patterns to provide restocking guidance that is up to date as consumer behaviors continue to evolve.

    The Bottom Line

    Ease of management, security and visibility are the key pillars to ensure business continuity for enterprises in a COVID world, and by doubling down on SD-WAN, organizations can benefit from all three.

    SD-WAN is quickly becoming the unsung hero in this shift to remote work by giving organizations the network visibility IT managers require as well as extra security precautions that are more critical than ever. And as businesses and our ways of working continue to evolve with the times, SD-WAN will enable employees across organizational networks to communicate safely and securely.

  • Managing a New Kind of Complexity in Software-Defined Networking

    Managing a New Kind of Complexity in Software-Defined Networking

    Software-defined networking (SDN) has moved up the enterprise IT agenda in recent years. And it’s easy to see why–in theory, SDNs are far quicker and easier to control and alter than traditional networks. By using open protocols to apply controls from the network edge, SDNs enable network engineers to shape traffic from a single centralized console, rather than working with individual switches across the network.

    In turn, this makes software-defined networks far more agile than traditional networks, with opportunities for automatic load balancing, streamlined processes, on-demand provisioning of new applications and traffic flows–in short, a network that works much harder for the organization. So, it’s no surprise that organizations are embracing SDN. A 2019 Verizon study found that while just 15% of respondents said their companies had implemented SDN, 57% expected to do so within two years.

    However, deploying SDNs can introduce new challenges for network staff revolving around complexity–in particular, complexity in relation to managing network security. Let’s take a closer look at what this means.

    A Shift in Complexity

    Any organization that moves to a software-defined environment essentially moves from datacenter-focused firewalls into a model where its security policies are defined by software within its fabric. This requires a far more granular level of security policies, on a much larger scale and with far more agility, than in traditional networks. Why? Because security controls are much more diverse.

    In a traditional setup, network security policy is relatively monolithic. A set of servers is protected by a perimeter firewall, filtering so-called north-south traffic that enters the network from the outside. Traditionally, east-west traffic within the datacenter itself is not subject to any filtering, which introduces security risks–particularly in terms of enabling malicious parties to laterally explore the environment once they have compromised a single endpoint.

    By contrast, in an SDN environment, built-in firewalls are considered part of the infrastructure. It is likely that the organization will have multiple tenants, each containing a unique set of granular security policies dictating which assets can connect to which other assets within the SDN fabric. An SDN environment is likely, for example, to incorporate one contract with Cisco Application Centric Architecture (ACI), VMWare NSX distributed firewalls and so on. There is a lot of complexity to manage.

    Ultimately, the organization in question needs to identify which elements within the newly software-defined network need to connect to each other. Then, create granular security policies that enforce this, dividing the network into smaller zones to prevent lateral infiltration by malicious parties. In short, they need to introduce micro-segmentation. 

    Managing Micro-Segmentation

    There are two main challenges associated with micro-segmentation from a security point of view. First, the organization needs to define the micro-segmented zones, and second, it needs to enforce and maintain the security policies that enable that micro-segmentation.

    How do we define micro-segmentation zones? This is all about understanding the assets within your environment, which databases contain the most sensitive data and therefore need to be segmented off from each other, which assets are talking to each other and how traffic is flowing throughout the network. Crucially, all this should be contextualized in terms of business applications–in other words, you need to understand the traffic that makes business applications work. This enables you to design a micro-segmentation architecture–and the security roles to enable it–that are centered around your business-critical services. Solutions that automatically discover and map all of the traffic flows within and through a datacenter are invaluable at this point.

    Then we move onto enforcement and maintenance of those rules on an ongoing basis, and this is where a security policy management solution is truly critical. All this complexity and dynamism cannot be managed manually. Each time a new business application is introduced, or an existing one removed or amended, the security policies also need to change–and these changes could be happening on a daily or even an hourly basis in a large organization.

    Automating the Management Process

    So, given the flexibility and rapid changes that SDN enables, how should organizations approach managing and maintaining security policies across their entire enterprise network? The most effective way is with an automation solution that holistically supports the SDN environment and its security controls, alongside existing traditional on-premise firewall estates.

    It’s important to note that the SDN deployment will be subjected to the same compliance and auditing requirements as existing networks. The security management solution must be capable of providing visibility across both physical and virtual network functions so that the overall compliance status can be centrally monitored and logged for audit purposes.

    Automated security policy management solutions generate filtering policies based on enabling only the traffic required for every application in the datacenter. This is a way of approaching intent-based networking, which comes back to looking at the components of each individual application and how they are communicating with each other. Furthermore, automated security policy management solutions audit and record every single change that is made across the network, making it easier to demonstrate compliance continuously.

    With the right automation solution, IT and security teams can eliminate time-consuming, error-prone manual security processes, such as connectivity discovery and mapping, migrating and ongoing maintenance of their environments. This frees up the teams to strategically maximize the benefits of the SDN deployment, and reap its rewards of increased flexibility and enhanced network security.

  • Why SDN’s Hot Streak Continues in 2020

    Why SDN’s Hot Streak Continues in 2020

    The software-defined networking (SDN) market is expected to grow by double-digits between now and 2023, driven by the increasing mainstream adoption of this technology. And for good reason: SDN gives IT the ability to make changes through software code instead of reconfiguring each device, and manage data traffic from a central console to move it in any direction.

    Communication gear still drives the physical movement of bits, but software drives the data plan and the control plan. This allows network managers—and even applications—to dynamically manage network resources based on complex system needs. SDN supports real-time integration across multiple servers, services and clouds, and it also processes huge volumes of data. IT departments can now overcome traditional networking issues such as performance bottlenecks and develop a more responsive network strategy.

    SDN Plays a Critical Role in Cloud Adoption and Improves Security for IT Departments

    SDN architecture integrates easily with cloud-based environments, both public and private ones. This gives network managers greater flexibility, speed and automation in managing their network clouds.

    On the security front, SDN allows an IT department to divide a network connection between an end user and the data center, and provide different security settings for the various types of network traffic. For example, a network could have one public-facing, low security network without any sensitive information. But another network segment could have a software-based firewall and encryption policies that allow for more sensitive data to travel over it. Having the ability to match security policies to specific workloads is a key advantage of SDN. 

    One of the hottest trends with SDN is microsegmentation, where IT professionals customize security settings to different types of traffic. With this security model, the goal is to apply segmentation rules down to the workload or application. This mitigates the likelihood of an attacker migrating between compromised workloads or applications to others. Basically, microsegmentation creates intelligent groupings of workloads based on their characteristics as communicated inside the data center. This approach does not depend on dynamically changing networks, specific business or technical requirements which means microsegmentation provides enhanced security.

    The software-defined wide area network (SD-WAN) takes SDN even further by connecting enterprise networks over large geographical areas, such as branch offices and data centers. Traditional WAN connections typically needed technology that required special proprietary hardware. SD-WAN moves more of the network control into the cloud through software, allowing for greater scalability, flexibility and reduced hardware costs. SD-WAN is expected to grow even faster than SDN in the coming years for several reasons:

    • Greater reliability of application performance, a huge advantage for users in today’s digital workspaces.
    • High level of connection security for cloud applications without performance trade-offs.
    • Increased bandwidth which reduces congestion and slowdowns.
    • More business agility through faster deployments of new applications.
    • Simpler IT administration through a centralized console instead of in-field configurations.

    SDN and its offspring of SD-WANs continue to defy expectations in creating greater agility, flexibility, security and reliability. Leading-edge IT organizations are embracing the imperatives of digital transformation through SDN and SD-WAN to provide for agile deployment, provisioning and operational management.

    — Melinda Cross

  • DevOps: Embracing the Telco Cloud

    DevOps: Embracing the Telco Cloud

    Ongoing developments in technology have led businesses to look to the cloud for greater flexibility, scalability and processing power. The telecoms industry is no different. Under growing pressure to meet the demands of the internet of things (IoT) and 5G, service providers are increasingly adopting cloud and virtualization technologies such as network functions virtualization (NFV) and software-defined networking (SDN) to provide them with the capacity they need to manage the explosion in data traffic.

    In an environment in which traditional telco revenue has been eroded by OTT (over-the-top, or IP-delivered) players, the commercial advantages offered by a telco cloud have never been more important. It’s hardly surprising then, that the global market is expected to grow at CAGR of 20 percent, reaching $29 billion within the next two years.

    Don’t Believe the Hype

    Despite the messages of benefits, however, operators have reservations, with many expressing concern that the hype around the promise of NFV and SDN is just that—hype.

    During a panel discussion at the MPLS, SDN and NFV World Congress 2018 in Paris, representatives of Orange and Nokia, among others, raised questions over the current level of investment in the technology. SDN was described as “not really a new concept” and NFV as being a “bubble.”

    It was additionally suggested that the benefits of virtualization weren’t particularly economical. Operators are becoming increasingly aware that the cost savings that NFV promises often are offset by the need to deploy entire racks of compute resources to handle processes that previously would have been supported by a single appliance. When you factor in the CPU and server requirements, along with the necessary power and physical rack space, the cost of delivering the same performance as a dedicated solution can be at least as expensive as a custom-designed alternative.

    Performance and Power

    Given the fundamental role that both SDN and NFV play in underpinning telco cloud, opinions such as those expressed in Paris are concerning—particularly when publicly voiced and apparently widely held. It’s clear then, that if they’re not already doing so, operators need to address these issues to realize the potential of telco cloud in the most cost-effective and efficient way possible. Indeed, time is of the essence, as the performance and scaling problems that operators face with generic NFV infrastructure are only set to get worse once 5G networks are fully implemented. The sheer volume and speed of data traffic through a 5G network, for example, will bring entirely new requirements in terms of scalability and performance.

    Encouragingly, though, steps are being taken to tackle technical challenges around performance and power consumption, particularly with regard to generic hardware. By distributing workloads between x86 general purpose processors and software-reconfigurable, FPGA-based SMARTNICs that are optimized for virtualized environments or VNF re-architecture, operators are turning to hardware acceleration as a means of improving performance both now and in the future.

    Look into the Cloud

    The analyst forecast mentioned at the beginning of this article illustrates that, while discussions continue around the relative economic benefits of virtualization, there’s no denying that cloud-based network infrastructure is beginning to take root across the telecoms industry.

    Increasingly we are seeing operators moving workloads on to virtualized or containerized infrastructure, for example, as they look to improve performance, reduce costs and hyperscale as required by their various network functions, applications and services.

    What’s more, inspired by other sectors that have successfully leveraged cloud-native functionality, operators are embracing Agile and DevOps development practices. Telco cloud provides operators with the development agility they need to combine and re-combine existing functions that, when tested and proven for scale, can deliver entirely new network capabilities. With the ability to quickly bring innovative new ideas to market, operators now have a new avenue of revenue to explore.

    The benefits extend into the wider ecosystem, too. Not only will an open multi-vendor platform running on open source software improve operational and cost efficiency, but by allowing software from multiple vendors to be more quickly integrated, it will enable the creation of innovative new network services and IT functions that, in turn, could led to new revenue streams.

    And, of course, the new paradigm shift will improve the customer experience. Shortly after last year’s Mobile World Congress (MWC), for example, Verizon and Colt carried out the first demonstration of two-way, inter-carrier SDN orchestration, making near real-time bandwidth changes in each other’s production networks. The implications of this are significant, offering enterprise customers in particular flexibility on demand.

    The 5G networks and the new generation of handsets, including foldable devices, dominated this year’s MWC. One look at the show’s agenda, however, shows just how important the cloud has become. And in meeting the demands of 5G and all it entails, its importance will only grow. It’s time, then, for operators to take a serious look into the telco cloud.

    — Naveen Kumar

  • APIs and DevOps

    APIs and DevOps

    As always, there are interesting trends in DevOps, and I wanted to point out one that is starting to bother me: the “API economy,” and how it impacts DevOps decision-makers.

    Traditional infrastructure—SAN, LAN, physical systems, etc.—were generally controlled the best from the command line. While there are a million of them, Cisco IOS is probably the one that you’ll remember best (or you stopped using to read this—just depends upon the shop). When large-scale automation started, these command lines became a bit problematic. After all, scripting was possible, but painful, and often had non-portable hardcoded values.

    Virtualization, and later cloud—and even later SDN and NFV—all made this better, but on a layer over the top of (and normally not well integrated with) the physical layer. Years ago I bemoaned that we had doubled the workload of operations by re-implementing what was already implemented at the physical layer. So we were configuring the physical—even for cloud you have to get to the cloud—and then configuring the virtual.

    Then “Software Devs as Kingmakers” came along, followed by “the API Economy,” and finally we started to see some serious attention paid to APIs by infrastructure vendors that should have done so long ago (some former employers of mine might belong in this group).

    Here is the thing: There is a difference between having an API and having an API that is useful. When shopping for solutions, be they physical or software, don’t allow APIs to be a check box because it’s “the API Economy.” And don’t assume that an API useful to DEVops is what is needed to automate infrastructure. Monitoring APIs—particularly ones that provide you detailed information about an app as it runs—are useful to DEVops, and assuming you have tools that are or can be integrated, might provide value to devOPS.

    But monitoring is not management. devOPS is increasingly automated, and increasingly needs viable APIs that can help them deploy/configure infrastructure. Vendors are responding, but the quality of APIs at this point in time varies widely. So make certain that evaluation looks at APIs available with an eye to suitability to task. devOPS needs management and might be able to use monitoring, while DEVops generally needs monitoring and has little use for management.

    This is not 100% true of course, there are a billion different shops, most doing things in slightly different ways, but think of storage (because it can be done in few enough words to fit in a blog)… An app needs access to storage, ways to be notified of storage space limitations, and possibly to metadata. Operations needs to provision, migrate, backup, replicate… The list goes on. These all contribute to the availability and quality of the application, and are all DevOps, but the focus is different. And having a simple “number of blocks free” API will not help with the DevOPS needs even if it helps developers manage a piece of the application.

    But we have more options than we ever did before! So fear not, just watch what your prospective vendors are doing, and check in with long-term vendors on occasion, too—because things are constantly changing, nearly always improving.

    And keep rocking it. Presumably you are working this out already, knowingly or not, or you wouldn’t have time to read this blog.

    — Don Macvittie

  • To Be Continuous Podcast: Category Creation featuring Martin Casado

    To Be Continuous Podcast: Category Creation featuring Martin Casado

    In this episode of “To Be Continuous,” Paul and Edith are joined by Martin Casado, General Partner at Andreessen Horowitz. He previously was co-founder and chief technology officer at Nicira, which was acquired by VMware in 2012. While at VMware, Martin served as senior vice president and general manager of the Networking and Security Business Unit.

    The group discusses the deeply complicated and difficult process of category creation, with a special focus on technology infrastructure products.

    This podcast is brought to you by Heavybit, a program that helps developer-focused companies take their product to market.

    [soundcloud url=”https://api.soundcloud.com/tracks/283115632?secret_token=s-zX7AW” params=”auto_play=false&hide_related=false&show_comments=true&show_user=true&show_reposts=false&visual=false” width=”100%” height=”166″ iframe=”true” /]


    Edith Harbaugh: What do you like about continuous delivery?

    Martin Casado: I think that there’s a broader movement around continuous delivery that is really interesting, which is, traditionally, infrastructure and operations came from an independent group. My first job out of undergraduate was working on simulations code in a national lab.

    I couldn’t control anything about infrastructure. I really didn’t have budget to buy a pencil. You get infrastructure, and you’d have some application to code, and you’d work on that application. We’d fiddle around with our MIG files or whatever, and that was pretty much it.

    The cool thing about the broad movement now, and I think CI/CD (continuous improvement/continuous delivery) is just part of this, is more and more applications, application developers, are actually getting responsibility for operations.

    This is provisioning, this is delivery, this is deployment. That’s a big huge change in not only what technologies get created but who’s consuming it and why they’re consuming it. I think it’s actually one of the more interesting trends right now.

    Edith: This would be a great time for you to introduce yourself.

    Martin: My name is Martin Casado, and I’m a general partner at Andreessen Horowitz.

    Edith: But you did stuff before you were at Andreessen.

    Martin: That’s right. The quick arc, as I mentioned, I used to be a research scientist at Lawrence Livermore National Labs. I spun out of that, did my PhD at Stanford. My research was in networking, so I was part of the team that started software-defined networking.

    I was there for four years, spun out of that, started a company called Nicira where we did software-defined networking. I did that for five years. That was acquired by VMware. I ran the networking security business unit at VMware for almost four years, and four months ago I decided to change and become a VC.

    Edith: So you basically created a category. What drove you to do that? What made you decide to start something knowing that it was so hard?

    Paul Biggar: You’re talking about software-defined networking? For the viewers at home, Martin roughly invented software-defined networking.

    Martin: There’s a whole bunch of people contributing, but I think a lot of the original momentum came from my thesis. You know, I’m going to be totally honest. If I had any idea how hard it was, I never would’ve done it.

    Edith: Really?

    Martin: I think so.

    Edith: I think you would’ve.

    Martin: Well, maybe. But it would’ve been a lot more daunting. I came out of Stanford pretty darn naive, like, “This is going to be easy!” Now, nine years and tons of gray hair later, I just realized that, man, it was a battle. I don’t think I had one-quarter that was easy. Everything was a battle.

    This is the way that I think about it. If you’re an entrepreneur, and you’re going to do category creation, you basically just have two jobs, in addition to product development. And job No. 1 is, there’s going to be some constituency out there you’re selling to, and that constituency, they wake up every morning and they think about all sorts of stuff, but they’re not thinking about your thing, because it hasn’t been created yet.

    That object in the mind space, that object doesn’t even exist in their brains yet. The first thing you have to do is create that object. It’s like Leonardo DiCaprio at “Inception.” You go in, you’re planting an idea in somebody’s head. It has to become a thing, something people think about, something people know and integrate.

    This is from nothing, and that’s hard. For us, it took five-plus years, and it touches every aspect of thought leadership such as analyst relations and technical conferences and broad marketing.

    Paul: So the activities that you’re doing in that category creation are largely marketing and getting people to hear about the activity and learn about it?

    Martin: I think so. I think maybe technologists will view marketing as this pretty shallow thing, but I think you’re exactly right. It’s marketing. But it is often very technical marketing, for example, in the guise of open source.

    In releasing open-source projects, you’re getting people to use it, you’re going to standards bodies, you’re going to conferences. It’s an incredibly technical thing, but in the end, it’s marketing in the sense that you’re actually creating awareness and a market.

    The first thing that you’ve got to do as an entrepreneur is, if you’re doing category creation, nobody’s thinking about your thing. You’ve got to get them to think about your thing, which is a lot of work. In my experience, five to seven years.

    Then the second thing that you have to do, which is just as much work, is then you have to attach a value to that thing. And I think we as technologists, there’s this kind of fallacy that we have where, “I’m going to create this new widget.” Let’s say I create the iPhone.

    Paul: Everyone will know how amazing it’s going to be.

    Martin: Exactly.

    Paul: Just build it and they will come.

    Martin: Yeah, there’s intrinsic value in my widgets. I take my widget, I put it on a sidewalk and someone picks it up. They’re like, “This is amazing. It’s worth millions of dollars!” And that’s totally not the reality.

    The reality is people only see value if they exchange money and they’ve used it.

    And if you’re doing category creation, how do people know what that value is? It’s a very difficult thing.

    Paul: And when you say attaching value, do you mean monetizing? Or is there more to it than that?

    Martin: I meant more the idea. Ultimately, this materializes monetization. Let’s say that you’re my constituency, and I’ve created this new widget. First I need to get you to think that this is actually a real thing. I’m going to call it a new phone. So, you need this new phone. First I need to convince you that you need the new phone.

    Then the second thing I need to convince you is it’s worth tens of thousands of dollars to you because you need to mentally actually attach that value to it. And it turns out introducing new concepts don’t necessarily have value if they’re new concepts.

    Normally, the value comes from, for example, an actual transaction. There’s a psychology around this. Or at least some experience with it, knowing that it’s going to, I don’t think you can just sit back to a couch experiment and be like, “Oh, I think this is going to save me money, therefore it’s worth something.” It really requires a lot of effort to make value.

    Paul: So the category that I see being created, or the one that’s closest to me at least, is this idea of containers and Docker, and more specifically Kubernetes, the idea that there’s this cloud infrastructure over there. The way that I became aware of it is exactly the way you’re talking about it. There’s open source coming out there that you can use and you can hack on yourself. There’s talks up there where people blow your mind.

    Martin: I think that actually this point, and certainly for all the listeners, I think this is one of the most salient points of this decade, actually, which is going to be a weird thing to say. At least an infrastructure’s the following.

    In the past, how did we create mindshare and customer bases? Well, there’s this whole pmm function and this whole sales function. And if you look at the big enterprise companies, if you look at Cisco and IBM and Oracle, really their power is this function. They own the sales channel.

    They have great relationships with the analysts, they’ve got great relationships with the customers, they’ve got certifications and the classes. So anytime they have a new concept, they take that concept and they cram it down the machine.

    As a startup, it doesn’t matter how cool your technology is, the hardest thing is to actually penetrate that channel.

    But when it comes to this new era of open source, now you actually have this hack that’s never existed before, where the buyer is shifting from an operator to a developer. Developers like open source, and you can actually create these concepts by getting open source out there and getting them to use it.

    Paul: We’ve been talking about this sort of thing, just the idea that it’s bottom-up now versus top-down.

    Martin: Not only that, it’s a totally different buyer that’s a totally different aesthetic. I don’t think developers care as much about analysts. I don’t think developers care as much about the 42-long sales dude with white teeth and the boat. I don’t think developers care as much.

    Paul: They won’t even answer his call.

    Martin: Exactly. About the channel, I think they don’t care about complex procurement processes.

    Edith: Having sold software for a little bit myself, if you get into a bigger corporation, you still don’t start to run into that.

    Paul: You get there, because the developers were first asking for it to exist.

    Edith: The longest part of our sale cycle is you get bounced to procurement and legal.

    Martin: Absolutely. I think this is the most important nuance of this argument, is exactly what you said. I’ve always maintained that open source and the developer is replacing marketing and pre-sales, not sales.

    You get credibility to the account, you can get things to technical close and technical validation, you can get account pull. So it’s almost like filling the pipeline, getting the transaction done, I still believe. For a long time, you need to have a professional, direct sales force that will be in there pushing things for procurement.

    Edith: It’s just a lot of work, because you pass the technical evaluation. They’re like, “Okay, go talk to procurement.” And to procurement, you’re a widget.

    Martin: Right, but the good news is, now it’s possible. Where in the past, to get that much legitimacy, to get things to technical close, was very difficult. You didn’t have the certification, you didn’t have access to the buyer, you didn’t have the account rep to make the introduction. You didn’t have any of that.

    Edith: That’s true.

    Martin: And now you do, and now it’s just about actually going through the logistics. And you’re absolutely right, it’s hard, it’s baroque. I’ve called it tribal bloodletting. It’s all of that, but you can do it as a startup.

    Paul: The thing that I think is really interesting is the converse of that. It’s that people who work in open source now are becoming actually incredible marketers. They don’t refer to themselves as such, but they have amazing social media presence.They build up tons of channels, whether it’s mailing lists or just Twitter followers.

    Edith: It’s like everybody recreates marketing. Everybody’s like, “Oh, we don’t need marketing.” Then you’re like, “Well, what is this thing over here where you have an email list?” Oh, that’s not marketing.

    Paul: It’s not marketing because I’m a developer.

    Martin: I really think that those that know how to do this are some of the most valuable people in the entire industry because this is the new entree for products into customer bases. I mean, there’s another kind of potential pitfall here, which is, let’s say you’re using open source for marketing.

    Now, there’s probably $7 billion have been invested in open-source companies and only about a $1 billion worth of returns. I’m not sure if those numbers are true, but I hear them quoted all of the time. But the reality is, a lot of money’s gone into it and not a lot of money has come back.

    The reason is because now, if you’re using open source to do marketing, you’re almost cannibalizing your sales motion. And so for a long time, the only open-source model we knew how to work was the Red Hat model, which is a services company. Only Red Hat’s ever pulled it off. It’s been very difficult.

    But another shift has happened in the last few years is people have figured out that actually you can use open source for marketing, but you don’t have to confuse that with your actual product offering.

    And with the rise of services, you can actually use open source for customer traction. You can monetize the service, and when it comes to services, no discussion of open source or closed source. So I think that we’re actually starting to unlock viable business models where you use open source for marketing.

    Edith: Who do you think does a good job of that?

    Martin: I think GitHub is a great example, right? Git isn’t even built by GitHub. It’s the standard in Linux. But if you look at GitHub, it’s a very fast-growing company that’s based on open source, and so everybody knows about it because of Git. So Git is doing the marketing. And this is just one example, I think there are many.

    Paul: It’s funny that you cite that as based in open source, because almost none of their stack is actually open source.

    Martin: Exactly, it’s a service offering. That’s what I’m saying.

    Paul: When you say service, you’re referring to software as a service, not service as in consulting?

    Martin: Absolutely. I should’ve been more clear. The long-standing question for us, certainly since 1995, is how do you build an open-source company that has the margins of a closed-source software company? Because you’re open source, basically you become a service and support company.

    What has happened in the last decade is exactly what you’re saying: people will realize that you can get account credibility and account traction, account knowledge, through open source.But then you can offer a back-end service offering as a service offering, and monetize that, and it’s often a closed-source stack on the back end of what you’re doing.

    But you don’t talk about open source/closed source as much with service offerings. It’s normally if you’re consuming something on-prem that you think about those things.

    Paul: How do you feel about this? People who are building, let’s say CircleCI as a good model, but there’s a ton of them. Building something that’s a SaaS product, a hosted SaaS product, but that then sells to people who use it in their own VPC and pseudo on-prem sort of thing.

    Edith: Oh gosh.

    Martin: I come from this somewhat traditional world of selling enterprise software. In there, there’s this whole discussion, and I was part of this discussion, of is it on-prem or is it off-prem in general? And I think that you framed this question perfectly. I’ve realized that that’s a false dichotomy. It’s actually not the right question to ask. I think as a service, is it actually an operational model and a delivery model? It doesn’t really matter if it’s on-prem or if it’s off-prem.

    I think that the days of selling closed-source software to companies is done.

    But you can sell them services and you actually can sell them appliances. But if you look at appliances, appliances almost look like services. They’re boxes that have services, and often the upgrade is happening remotely, management is happening remotely.

    I do think that the right model for these companies, I think CircleCI’s a great example of this, you have open source that customers use, you have a SaaS offering, but you also have an on-prem delivery offering as long as you don’t change the operating model, as long as it still looks like a SaaS model somehow, whether it’s a managed service or something like that.

    I think as soon as it becomes shippable software, where you have to manage a heterogeneous set of environments, you have to manage all the day-two ops. It becomes unwieldy.

    Edith: I had a really interesting discussion the other day with the VP of Sales from CircleCI and somebody from Microsoft. CircleCI was basically like, “We love that it’s selling on-prem. It’s helping you.” Microsoft is like, “We’re trying to get off-prem desperately.” So it was not the argument you thought was going to happen.

    Paul: I think it’s probably because of how sensitive the IP is. If you’re talking about something like, well, documents are pretty sensitive, but the source code is very sensitive. And so people are not as happy to ship that off-prem as we once thought was going to be the case.

    Edith: Microsoft’s reasoning was, and this might be the way Microsoft had done it, is they have 10-year maintenance agreements.

    Martin: We have, “If you have a problem, upgrade to the latest version and then we’ll deal with you.” I think that’s kind of what everyone has. There used to be this idea that you’d create a fork and then you’d backport things to that fork or the old version, or something like that.

    I don’t know anyone who’s doing this sort of services, the SaaS with a managed to on-prem version that does anything but “the latest version is the version.”

    This podcast is brought to you by Heavybit, a program that helps developer-focused companies take their product to market. Throughout the program, founders work on developer traction, product market fit and customer development. If you like what you hear, be sure to subscribe to Heavybit’s Podcast Network on iTunes.

    — Malia Powers

  • Why DevOps Should Care About SDN

    Why DevOps Should Care About SDN

    Software-defined networking (SDN) and DevOps are not mutually exclusive. Actually, DevOps wants SDN, whether it knows it yet or not.

    Why?

    If software is going to eat the world, then SDN is going to eat networking.

    Networks are becoming more complex, and one way to manage them more effectively is through SDN. Also, organizations are demanding faster changes, yet networking changes traditionally have been a manual process.

    In a profession where network engineers typically work in seclusion and use significant manual processes, it can provide a set of tools to align with DevOps. This is why DevOps needs to care about it.

    Software-defined networking leads to infrastructure as code (IaC), which makes network automation possible.

    Software-Defined Networking and Infrastructure as Code

    SDN, in its simplest form, is controlling networking hardware with software. But there is more to it: Software-defined networking means networking switches and routers no longer need to be controlled with proprietary software. This creates an opening for innovation and is how we now have OpenFlow.

    This implies that networking now can culturally align itself with DevOps. The question will become whether it wants to. IaC is where networking will find its home with the DevOps team—it is like SDN for Ops.

    Why Does SDN Matter for DevOps?

    Software-defined networking will open communication and make automation possible—two ideas that are fundamental to an effective DevOps team.

    Open communication between networking can be easier when the mindset and tools are enabling a similar process. For DevOps, the current stack is providing tools to do exactly this. We see this with the Ansible and Red Hat DevOps networking partnership.

    What’s more, SDN enables network automation. Automation is an important goal for DevOps, which before SDN was not workable. Network automation can mean a better integration of DevOps and networking, as networking comprises many manual processes and, as such, is a bit isolationist. Aligning goals can provide better communication and collaboration.

    The Power of Network Automation

    SDN, IaC and DevOps networking are providing a set of tools and ideas that can push widespread adoption of network automation.

    Network automation is not a new topic, but implementation has been difficult. Technology had to catch up with demand: Before OpenFlow, networking infrastructure ran on proprietary software, which meant manual changes and configurations were commonplace and one-off scripts are the norm.

    With SDN and a technological environment conducive to network automation, we can begin to test different network automation strategies. Currently, however, organizations using automation only use it for segmenting their firewalls. We are in the early stages of what network automation can do.

    Just as DevOps is still finding ways to use automation in testing and development, networking is on its own discovery path to automation. The only difference is DevOps has a goal to automate and networking still views automation as a “nice to have.”

    Using NetDevOps to Bridge the Gap

    We have the conversation about SDN, IaC and network automation because networking does not have its functions accurately defined within the DevOps framework. That is why NetDevOps is a topic of discussion.

    The fact that SDN is still in its infancy stages and network automation is being discussed as “how to implement” shows there is a need for a cultural shift in networking that aligns with DevOps. This will help DevOps with communication and collaboration.

    DevOps wants automation and NetDevOps shares this goal. SDN is what makes this possible, and is exactly why DevOps should care.

  • Infrastructure as Code is SDN for Ops

    Infrastructure as Code is SDN for Ops

    As we continue to recognize the importance of DevOps—particularly its automation and orchestration aspects—to achieve the agility necessary for continuous deployment of apps, the question of how the term “Infrastructure as Code” (IaC) applies to traditionally network-bound systems and services is bound to crop up more frequently. After all, in addition to core IP-based networking characteristics required for an app to communicate and serve up content, an entire ecosystem of app services that support, secure and scale it must be considered.

    IaC is driven by the application of development principles to network infrastructure. Configuration, scripts, templates, profiles and the like are treated as code, in that they should be reviewed, versioned and provisioned from a centralized repository (one hopes on-premises) rather than managed as discrete network elements.

    In a recent article in TechBeacon, Boyd Hemphill, director of evangelism at StackEngine, noted, “The basic principle is that operators (admins, system engineers, etc.) should not log in to a new machine and configure it from documentation.”

    Christopher Null, CEO of Null Media and author of the article, then wrote, ” … But IaC is a concept that extends beyond simple infrastructure automation. IaC requires applying DevOps practices to automation scripts to ensure they’re free of errors, are able to be redeployed on multiple servers, can be rolled back in case of problems, and can be engaged by both operations and development teams.”

    The idea is that you can describe any given service as a set of artifacts and deploy (and redeploy) them at will. So rather than set up a system and configure it directly, its configuration any associated artifacts (such as profiles or templates) are treated as code and stored in a common repository. A controller—the orchestrator—is responsible for distributing those artifacts when necessary. The controller uses an API (or protocol such as OpenFlow) to manage the configuration of services across a distributed infrastructure. It’s decoupling the service definition from the service and its platform.infra as code

    Read that again. It decouples the service definition from the service and its platform and assigns responsibility for provisioning and configuration to a controller. Kind of like decoupling the control plane from the actual forwarding and switching actions (the data plane) and assigning operational responsibility to an external controller.

    At its simplest, treating infrastructure as code is separating configuration from the platform and enabling a software-driven or software-defined approach to provisioning, configuring and managing infrastructure. It’s applying the principles of software-defined networking (SDN) to operations, rather than to devices and systems.

    But as Null makes clear in his article, IaC goes beyond just automation and orchestration, adopting the best practices of development with respect to code reviews, versioning and management of that “code” to ensure consistent, predictable and repeatable deployments.

    It’s all driven by software, ultimately, and deployed by software, and defined by software but always under the auspices of the operational experts: the engineers and architects.

    Treating infrastructure as code is basically applying the architectural principles of SDN to operations itself. It’s SDN for ops.