staging-devopsy.kinsta.cloud

Tag: NGINX

  • F5 Looks to Streamline Application Networking

    F5 Looks to Streamline Application Networking

    At its AppWorld 2024 conference this week, F5 announced a software-as-a-service (SaaS) edition of its NGINX application networking portfolio, which are now all available under a single enterprise license.

    Shawn Wormke, general manager for NGINX, said NGINX One will eliminate much of the friction enterprise IT teams currently encounter when implementing NGINX Plus, NGINX Open Source, NGINX Unit, NGINX Gateway Fabric and the Kubernetes Ingress Controller the company provides.

    As part of that effort, F5 is also now making available a unified console across its application networking portfolio that promises to streamline the management of the F5 application networking portfolio.

    Currently available under an early access program, NGINX One creates an as-a-service platform through which enterprise IT organizations can invoke and pay for these capabilities on an as-needed basis, said Wormke. The overall goal is to reduce the total cost of application networking by eliminating the need for IT teams to integrate the various elements of NGINX One on their own, he added.

    In general, application networking has become more complex with the rise of cloud-native applications based on microservices. By reducing the cognitive load required to network those applications, it becomes simpler to make network operations a more natural extension of DevOps workflows, noted Wormke.

    Most organizations have some level of experience with application networking using proxy servers, but as application environments have become more complex, the need for gateways and ingress controllers to provide these capabilities at scale has become more apparent. As a result, more IT organizations are starting to revisit how they are structured. There may always be a need for dedicated networking specialists to manage the physical network underlay, but as other networking services become more integrated with DevOps workflows, responsibility for some networking services is starting to shift further left toward DevOps teams that will either deploy these capabilities themselves or take advantage of a SaaS platform such as NGINX One. The overall goal is to be able to dynamically provision application networking services without having to wait for a network administrator to provision them.

    There are, of course, a lot of approaches to application networking that are now emerging. Regardless of how application networking evolves, however, the rigidity that has characterized the delivery of network services for decades should finally start to fade away. Today, outside of a cloud computing environment, it’s still common for IT teams to provision virtual machines or Kubernetes pods in hours only to wait days or even weeks for network connectivity to be provisioned. As IT environments become more hybrid and more workloads are pushed to the edge, there is a clear need for a more agile approach.

    Each organization will need to decide how best to approach application networking across legacy monolithic applications, microservices and event-driven applications at a time when IT environments have become much more complex to manage. The challenge, as always, is reducing as much friction as possible without unduly raising the total cost of IT to a point where it becomes unsustainable.

  • F5 NGINX Delivers Modern Management Platform

    F5 NGINX Delivers Modern Management Platform

    F5 NGINX has revamped an implementation of its management suite as part of an effort to make the platform both more accessible and simpler to use.

    Eric Braun, vice president of product management for F5 NGINX, said NGINX Management Suite 1.0 is based on a modular platform that makes it possible to dynamically scale instances of NGINX proxy software, application delivery services, application programming interface (API) management workflows and the company’s security offerings.

    That approach makes it possible to automate the deployment of F5 NGINX software without relying on manual processes that are prone to misconfiguration, Braun noted.

    The platform is based on a modern architecture that also makes it possible for administrators to enable development teams to self-service their own requirements within the limits of a set of policies defined via a portal, he added.

    The NGINX Management Suite replaces NGINX Controller, a more monolithic platform that is not based on an API-first approach to managing services, said Braun.

    The core modules of the NGINX Management Suite are an Instance Manager for the open source and commercial instances of the company’s proxy software, an API Connectivity Manager, App Delivery Manager and an App and API Security module. NGINX Management Suite will enable organizations to use NGINX App Protect Web Application Firewall (WAF) to protect applications and APIs while the App Delivery Manager module will be extended to enable configuring, securing, monitoring and troubleshooting of NGINX Plus when used as a load balancer.

    The revamp of the NGINX management plane is the latest in a series of efforts to modernize application and IT infrastructure management using a microservices-based platform that more easily scales as more resources are required. The more modular approach also gives IT teams more granular control over how various modules are accessed.

    It also makes it simpler for IT teams to deploy, for example, a service mesh or API gateway without having to add additional management platforms, noted Braun. That capability should significantly streamline the process of deploying those platforms because the need for a dedicated platform to manage them has been eliminated, he added.

    It’s not clear to what degree that latter capability will enable IT organizations to shift responsibility for managing various tasks further left toward application development teams. However, it is clear application development teams want to be able to self-service their own IT requirements and make services available without intervention from a centralized IT organization. In effect, IT organizations are trying to strike a balance between the benefits of centralization and the need to build and deploy applications faster within the context of a DevOps workflow.

    It may be a while before most IT organizations are able to consistently strike that balance. In the meantime, however, as IT management platforms continue to be modernized using APIs it should also become easier to integrate them. It will be up to each IT organization to then decide how many management platforms are going to be required, but at the very least, the various management silos that make up an IT environment today are finally starting to break down.

  • F5 Networks Planning Open Source Projects Beyond NGINX

    F5 Networks Planning Open Source Projects Beyond NGINX

    F5 Networks today revealed plans to launch multiple projects in the months ahead that will extend its commitment to open source beyond the NGINX proxy software the company acquired in 2019.

    The announcement was made during an online NGINX Sprint event; two of the projects are extensions of NGINX that will address networking requirements between microservices-based applications in addition to the management of fleets of NGINX instances. The third project is a platform-agnostic open source developer tool for building modern applications that does not necessarily require NGINX proxy software.

    At the same time, F5 Networks also unveiled an open source NGINX Modern Apps Reference Architecture that gives IT teams access to a complete, fully operational microservices-based application that can be deployed in minutes on a Kubernetes cluster. Based on a modular approach made up of open source components that come pre-wired and pre-integrated, F5 Networks is committing to extending this framework in collaboration with multiple third-party vendors and organizations.

    F5

    Rob Whiteley, general manager for the NGINX product group at F5 Networks, said the company is also committing to modernizing its NGINX proxy software to leapfrog rival open source Envoy proxy software being advanced under the auspices of the Cloud Native Computing Foundation (CNCF). NGINX is still more widely employed than Envoy largely because it is lighter-weight and easier to deploy, but Whiteley conceded that Envoy has more advanced capabilities.

    Envoy, of course, is at the core of the Istio service mesh. F5 Networks supports both Istio as well as a service mesh it has developed on top of NGINX. Depending on the number of application programming interfaces (APIs) that an organization needs to support, an IT team might make use of proxy software, ingress controller or an API gateway for a service mesh to manage them.

    Finally, F5 Networks said it will participate in the Kubernetes ingress project and that it is joining the gateway API community as its implements its own NGINX-based gateway controller to ensure its proxy software and Kubernetes remain tightly aligned in the future.

    In general, Whiteley said F5 Networks also is making a commitment to be clearer about where the line between the open source and commercial editions of its offerings is drawn. As a rule, the open source editions are designed for developers and small teams while the commercial version is designed to scale within enterprise IT environments. The overall goal is to promote innovation without enabling cloud service providers to reap all the revenue benefits of F5’s research and development by creating a service based on that open source software, said Whiteley.

    As part of that effort, F5 Networks is expanding the number of open source projects it supports to make it easier for developers to contribute code beyond the core NGNIX proxy software, said Whiteley.

    It’s not clear to what degree F5 Networks will be able to rally the open source community to advance additional projects beyond NGINX. The company is promising to provide additional details at an unspecified future date. However, Whiteley said there is still plenty of room for innovations not only in emerging technologies such as service meshes but also proxy software that is already widely employed within many enterprise IT organizations. Especially since most of them are embracing microservices-based applications that will ultimately change every aspect of IT.

  • Decoding the Self-Healing Kubernetes

    Decoding the Self-Healing Kubernetes

    A business application that fails to operate 24/7 would be considered inefficient in the market. The idea is that applications run uninterrupted, irrespective of a technical glitch, feature update or a natural disaster. In today’s heterogeneous environment where infrastructure is intricately layered, a continuous workflow of application is possible via self-healing.   

    Kubernetes, which is a container orchestration tool, facilitates the smooth working of the application by abstracting machines physically. Moreover, the pods and containers in Kubernetes can self-heal.

    In the Avengers movie, Captain America asked Bruce Banner to get angry so he could transform into The Hulk. Bruce replied, “That’s my secret Captain. I’m always angry.” You must have understood the analogy here. Let’s simplify: Kubernetes will self-heal organically, whenever the system is affected. 

    Kubernetes’s self-healing property ensures that the clusters always function at the optimal state. Kubernetes can effectively self-detect two types of objects—podstatus and container status. Kubernetes’s orchestration capabilities can monitor and replace unhealthy containers as per the desired configuration. Likewise, Kubernetes can fix pods, which are the smallest units encompassing single or multiple containers. 

    The Three Container States Include

    1. Waiting: created but not running. A container, which is in a waiting stage, will still run operations such as pulling images or applying secrets, etc. To check the waiting pod status, use the following command:
      Checking waiting status
      Along with this state, a message and reason about the state are displayed to provide more information.
      Waiting before entering running stage
    2. Running Pods: containers that are running without issues. The following command is executed before the pod enters the running state:
      postStart
      Running pods will display the time of the entrance of the container.
      Time of entrance of the container
    3. Terminated Pods: a container that fails or completes its execution. The following command is executed before the pod is moved to terminated:
      prestop
      Terminated pods will display the time of the entrance of the container.
      Terminated pod - time of entrance

    Kubernetes’ Self-Healing Concepts – Pod’s Phase, Probes and Restart Policy

    The pod phase in Kubernetes offers insight into the pod’s placement. We can have: 

    • Pending Pods–created but not running.
    • Running Pods–runs all the containers.
    • Succeeded Pods–successfully completed container lifecycle.
    • Failed Pods–minimum one container failed and all containers terminated.
    • Unknown Pods.

    Kubernetes execute liveness and readiness probes for the pods to check if they function as per the desired state. The liveness probe will check a container for its running status. If a container fails the probe, Kubernetes will terminate it and create a new container in accordance with the restart policy. The readiness probe will check a container for its service request serving capabilities. If a container fails the probe, then Kubernetes will remove the IP address of the related pod. 

    Liveness probe example:

    Liveness probe example

    The probes include:

    • ExecAction–to execute commands in containers.
    • TCPSocketAction–to implement a TCP check w.r.t to the IP address of a container.
    • HTTPGetAction–to implement a HTTP Get check w.r.t to the IP address of a container.

    Each probe gives one of three results:

    • Success: The container passed the diagnostic.
    • Failure: The container failed the diagnostic.
    • Unknown: The diagnostic failed, so no action should be taken.

    Demo Description of Self-Healing Kubernetes

    We need to set the code replication to trigger the self-healing capability of Kubernetes. 

    Let’s see an example of the Nginx file:

    Nginx example

    In the above code, we see that the total number of pods across the cluster must be four.

    Next, let’s deploy the file.

    kubectl apply nginx-deployment-sample

    Let’s list the pods, using:

    kubectl get pods -1 app=nginx

    Here is the output:

    output_nginx-deployment-test

    As you see above, we have created four pods. 

    Now, let’s delete one of the pods.

    deleting a pod

    The pod is now deleted. We get the following output:

    pod deleted

    Let’s list the pods again.

    get pods

    We get the following output:

    Output: 4 pods

    We have four pods again, despite deleting one. Kubernetes has self-healed to create a new node and maintain the count to four.

    Conclusion

    Kubernetes can self-heal applications and containers, but what about healing itself when the nodes are down? For Kubernetes to continue self-healing, it needs a dedicated set of infrastructure, with access to self-healing nodes all the time. The infrastructure must be driven by automation and powered by predictive analytics to preempt and fix issues beforehand. The bottom line is that at any given point in time, the infrastructure nodes should maintain the required count for uninterrupted services.

  • F5 Networks Launches Next-Gen ADC Based on NGINX

    F5 Networks Launches Next-Gen ADC Based on NGINX

    F5 Networks this week launched version 3.0 of its NGINX application delivery controller (ADC) that adds application programming interface (API) management tools, analytics and monitoring tools, a service mesh, a certificate manager, a developer portal and integrations with multiple continuous integration/continuous deployment (CI/CD) platforms.

    Ken Bocchino, director of product management for NGINX at F5 Networks, said as the first major update to the NGINX Controller since F5 Networks acquired NGINX last year, the 3.0 release represents a concerted effort to reduce the total cost of DevOps by bundling many capabilities that previously would have needed to be acquired separately.

    In addition, NGINX Controller 3.0 reduces the complexity associated with building DevOps workflows because all the components that make up NGINX Controller have been pre-integrated, said Bocchino.

    Based on the open source NGINX proxy server, NGINX Controller is the mechanism through which commercial capabilities are provided and supported as part of the NGINX Plus subscription service offered to enterprise IT customers. Previous iterations of ADCs were much more infrastructure-centric than application-centric, noted Bocchino.

    While F5 Networks naturally would prefer IT organizations to consume all those services, Bocchino said the ADC has been designed in a modular fashion to enable organizations to consume services exposed as REST APIs as they see fit. A future version of the NGNIX proxy server will be able to support multiple types of service meshes, including the lighter-weight offering created by the NGINX team that will become available later this year as part of NGINX Controller 3.0, he said.

    Bocchino noted F5 Networks envisions the NGINX Controller playing a major role in driving further convergence across network operations, security and DevOps teams. NGINX Controller 3.0 facilitates that goal by providing a self-service portal along with role-based access controls and modular workflows that eliminate the need for tickets to be issued to achieve every IT task.

    It’s not clear at what rate that convergence is occurring. However, F5 Networks last year published a survey of DevOps and NetOps teams that suggests there is still a wide gap between NetOps and DevOps teams. The survey found only a little more than a third (38%) of DevOps teams cited the “integration of toolsets across vendors/devices” as a challenge to network automation. In contrast, almost half of NetOps respondents (47%) noted a lack of integration as a problem, second only to a lack of automation expertise (49%).

    F5 Networks by acquiring NGINX is betting than most organizations that have already embraced NGINX proxy server software would rather extend those existing capabilities versus replacing their ADC with a new stack of software based on, for example, the rival open source Envoy proxy server being developed under the auspices of the Cloud Native Computing Foundation (CNCF).

    How the proxy server war and associated ASC platform wars will play out is still anybody’s guess. What is clear is that DevOps teams will need to access a wide range of programmable networking and security services easily to take DevOps to the next level.

    — Mike Vizard

  • Announcing General Availability of NGINX Plus R18

    Simplify configuration workflows for DevOps and enhance the security and reliability of your applications at scale

    San Francisco, CA – April 9, 2018 – NGINX, Inc., the company based on the popular open source project and offering a suite of technologies designed to develop and deliver modern applications, today announced general availability of NGINX Plus R18. NGINX Plus is the only all-in-one load balancer, content cache, web server, proxy, API gateway and Kubernetes Ingress Controller. This versatility enables you to simplify your architecture for delivering both traditional applications and new ones based on microservices.

    NGINX’s flexibility, portability and seamless integration with CI/CD automation tools help accelerate enterprise adoption of DevOps. NGINX Plus R18 advances this objective by simplifying configuration workflows and enhancing the security and reliability of your applications.

    New capabilities introduced in R18 include:

    • Simplifying configuration workflows:

    ○ Dynamic certificate loading: NGINX Plus introduces lazy loading of TLS certificates. With lazy loading, TLS certificates are only loaded into memory when a request is made for a matching hostname. This simplifies the NGINX Plus configuration and reduces its size as multiple certificates can be handled within a single server block. Furthermore, you can save time and effort by automating the upload of certificates and private keys into the key-value store using the NGINX Plus API. This is especially ideal for deployments with large numbers of certificates or when there are a high frequency of configuration reloads.

    ○ Support for port ranges for server configurations: With this release, users can specify port ranges rather than just specific ports. Port ranges can be specified for both HTTP and TCP/UDP applications (Stream module). This also allows NGINX Plus to act as a proxy for an FTP server in passive mode.

    ○ Simplified cluster management: NGINX Plus R15 introduced synchronization of runtime state across a cluster of NGINX Plus instances. This release enhances clustering by enabling a single configuration to be used for each member of the cluster. This is particularly suitable for dynamic environments such as auto-scaling groups or containerized clusters.

    ○ Modular code organization with the NGINX JavaScript module: The NGINX JavaScript module now supports the JavaScript import and export modules, enabling you to organize your JavaScript code into multiple function-specific files instead of a single file as before. This greatly improves readability and simplifies maintenance, particularly if multiple teams are contributing JavaScript code.

    • Enhanced Security: 

    ○ Minimizing exposure of certificates: When managing TLS/SSL certificates for secure sites and applications, users configure NGINX Plus to specify the certificate and associated private key as files on disk. With this release, NGINX Plus loads certificates directly from the key-value store where they reside in memory. Keeping secrets off the filesystem makes it difficult for an attacker to obtain the private key for a server certificate.

    ○ Support for opaque session tokens: NGINX Plus supports OpenID Connect authentication and single sign-on for backend applications. With this release, NGINX Plus supports opaque session tokens issued by OpenID Connect. Opaque tokens contain no personally identifiable information about the user so that no sensitive information is stored at the client.

    • Improved Reliability: 

    ○ Enabling clients to reconnect upon failed health checks: NGINX Plus active health checks continually probes the health of upstream servers to ensure traffic does not get forwarded to servers that are offline. With this release, existing client connections can be terminated when an active health check fails. This enables client applications to reconnect, at which point they are proxied to a healthy backend server, thereby improving the reliability of your applications.

    For an in-depth look at these features and to learn more about additional features in R18, please read our blog. To start your free trial of NGINX Plus R18 along with NGINX Controller, visit https://www.nginx.com/free-trial-request-nginx-controller.

    About NGINX, Inc. NGINX, Inc. is the company behind the popular open source project trusted by more than 450 million sites. We offer a suite of technologies for developing and delivering modern applications. The NGINX Application Platform enables enterprises undergoing digital transformation to modernize legacy, monolithic applications as well as deliver new, microservices-based applications. Companies like Netflix, Starbucks, and McDonalds rely on NGINX to reduce costs, improve resiliency, and speed innovation. NGINX investors include: Blue Cloud Ventures, e.ventures, Index Ventures, Goldman Sachs, MSD Capital, NEA, Runa Capital, and Telstra Ventures.

    We are headquartered in San Francisco, CA, with our EMEA head office in Cork, Ireland and APAC head office in Singapore. Learn more at https://www.nginx.com/ or join the conversation by following @nginx on Twitter.

     

  • DevOps Chat: F5’s NGINX Acquisition, with F5’s Lori MacVittie

    DevOps Chat: F5’s NGINX Acquisition, with F5’s Lori MacVittie

    F5 Networks has acquired NGINX, the leading open source web server player. The move clearly puts F5 in the DevOps space, as well as the open source market.

    In this DevOps Chat, we speak with Lori MacVittie of F5 along with Sidney Rabsatt of NGINX. Some great insights into why this acquisition makes sense for both parties.

    As usual, the streaming audio is immediately below, followed by the transcript of our conversation.

    Transcript

    Alan Shimel: Hey everyone, it’s Alan Shimel, staging-devopsy.kinsta.cloud, DevOps Chat, and you’re listening to another chat. Today’s chat features two folks from an acquisition announced yesterday. In case you haven’t heard, F5 Networks has acquired NGINX. We’re going to hear more about it from two folks. Number one is our friend, Lori MacVittie from F5 Networks. Lori, welcome. Glad to have you here.

    Lori MacVittie: Thanks, happy to be here.

    Shimel: Fantastic. Joining Lori and I is Sidney Rabsatt. Sidney is VP of product at NGINX. Correct, Sidney?

    Sidney Rabsatt: That’s right, and I’m happy to be here too.

    Shimel: Well, everyone’s happy to be here. That’s not a bad thing. Are you happy to be here at the DevOps Chat or are we happy to be here talking about F5’s acquisition of NGINX? Let’s hope it’s both. Lori, give us a little background here. When I saw the deal yesterday. I said, “Wow, that’s a big deal.” I’m not sure – it’s certainly an expansion, up the stack, if you will, for F5.

    MacVittie: Up the stack, deeper into the app. It’s all about application delivery. One of the – Sidney mentioned earlier when we were chatting, building on NGINX’s vision, which as I read it, is flawless application delivery. That’s certainly something that F5 has always aspired to achieve as well, but there’s just pieces in the application stack that we don’t play in, or haven’t played in until yesterday with the acquisition. NGINX is the leading webserver. They’ve got an app server. They do some app delivery. They’re very prevalent in many, many places. So we’re very excited to have them on board to see how we can bridge the gap between those two worlds.

    Shimel: Absolutely. What about the perspective of NGINX? Money is always nice. Don’t get me wrong. What’s the attraction to F5 here?

    Rabsatt: I think there’s at least two sides of it. Working with the folks on this early on, we got to get a sense of the culture of the organization. It felt very compatible. The people we met were great. We had a great time talking, hanging out, sharing ideas. There’s some real optimism about what can be done together. The thing that really gets folks excited, especially on my side of the house, on the NGINX side of the house is the opportunity to do even more faster. We’re a startup. It’s grown to a good size. The set of resources that we have, but looking at F5 and talking to those folks, understanding that they have a shared vision. They see the world very similarly and bringing more resources to bear to execute on the vision that we’re always working towards. It’s something that’s very exciting for us.

    Shimel: I can’t disagree with you. I think we’re in violent agreement on it. It is a great opportunity. I guess the next question is how do we integrate, Lori or Sidney, how do we integrate the NGINX webserver, appserver, and the rest of the toolset into the F5 family? Or do we not?

    Rabsatt: Do you mind if I take a stab at it?

    MacVittie: Go ahead, Sidney, please.

    Rabsatt: Sure. Look, I think on the surface of things it might seem as if there’s a ton of integration that needs to happen, and a lot of overlap needs to be addressed, but quite frankly, I’ve been pleased to see how much complementary capabilities we actually have. Oftentimes, in the marketplace, folks will actually deploy both solutions side by side. It’s because we do slightly different things, both super important to folks. When we think about integration, there’s opportunity for F5 customers to be able to leverage NGINX solutions in places where they couldn’t necessarily before. That should be a net benefit to them.

    There’s the ability for folks that leverage NGINX solutions to take advantage of things that F5 does, that we don’t particularly do. I think that’s going to be another win for them as well. The integration is really focused on making sure we have the right extensions to the product line identified so we can really give customers the things they need to succeed in delivering those end to end applications, and yes, of course, we’re going to be looking to bring the best of both sets of technologies together in the places where it makes sense, but we’ve been pleased to see it’s not as many overlapping things as we might have found in some situations. We’re very optimistic about the path forward here.

    Shimel: So crystallize for me, where do you see things that overlap versus things that play well together? Can you give us some specifics?

    Rabsatt: Sure. Things that play well together fall into the category of “Hey, can I bring better scrutiny, better analytics, to the types of solutions that I might already have with NGINX?” On the NGINX side, I’m sorry – on the F5 side, “Hey, can I leverage solutions to give me a little bit more freedom and flexibility to build my apps wherever or however I might choose to?” So I think there’s some goodness there that folks will definitely get access to.

    On the integration side, you’ll find most of it is just around making sure that the products work seamlessly together. So to the extent of I have multiple devices in my environment. How do I have a single solution that gives me the ability to manage it the way that I need to? We still need to go through the work of understanding exactly how the different buyers are going to need to interact with the different solutions that we use going forward, but all that work is in progress and again, the overlap tends to be the little stuff. Oh, do you draw a report? Oh yeah, we draw a report. Do you guys do that too? Sure. So how do we bring the best of those technologies together? It’s that kind of thing.

    Shimel: Got it. Lori, interested to hear, you heard Sidney here. What do you add to that? What are your feelings on it?

    MacVittie: I think he encompassed everything well. We already – you already see both of us in F5 and NGINX together in a lot of environments. From our perspective, I think we’re looking at – one, continuing to invest and amplify the NGINX vision and what they’re trying to execute on, but also where can we add security? Security is a big deal that has to extend from end to end. Right now, that’s a very disjoint process sometimes. That’s why we keep telling security to shift let. I think this is an opportunity that we’re going to be looking for to be able to do those kinds of things and shift that security even lefter with NGINX.

    Shimel: Absolutely. It’s funny when you think about security being a driving force behind this acquisition. With NGINX being a webserver, that’s been an area and app server, that’s been an area where security has been required and important forever, even going back to IIS in the day, Internet Information Server and stuff. Here’s an area though I was thinking about. So many people in the public cloud use NGINX as their webserver of choice, whether we’re talking about Amazon or even Microsoft Google or any of them. Lori, does F5 maybe view this acquisition as a way to expand your footprint in public cloud? If so, how?

    MacVittie:  I don’t think we looked at exactly how that’s going to play out, and what we’re going to do with that. The webserver is something different from the proxy technology that most of our products are built on. So there’s some differences there in how that works. We’re still looking at roadmaps and trying to figure that out. For right now, we’re just going to keep going ahead with both sets of road maps and moving forward. As we continue to explore what we can do together, we’ll figure out where it makes sense.

    Shimel: Sidney, same – flip side of that coin – of that question to you around public cloud. Do you see an angle where F5 helps there?

    Rabsatt: Yeah, I think F5 already had strong relationships with quite a few of the cloud vendors as do we, and we expect that – we ultimately want to give folks a choice. This all boils down to organizations are trying to build the applications that make sense for them. They want to be able to leverage the best tools and capabilities that help them deliver those applications while giving them the freedom to build the application they want. So whether that is on one cloud, on multicloud, across clouds, and on prem locations, they need that flexibility to do what makes sense for them. A big part of what we’re trying to accomplish here is making sure that F5’s large customer base has the capabilities that NGINX large user base has, which is again, that freedom of flexibility. That means that whether it’s on Amazon Google, Microsoft, any cloud, or any on prem solution, they get to deliver their applications with the security, controls, the visibility that they desire.

    Shimel: Excellent. I’m just – in hybrid situation, what about – one of the hottest topics certainly in technology today is the whole Kubernetes container thing. I know both F5 and NGINX had Kubernetes-related solutions and playing in that market. What, if any, does this acquisition, what if anything does this acquisition bring to that? Either one?

    Rabsatt: I would say it should be a net benefit. NGINX, there was a recent report I saw. It’s in the public domain. NGINX is the most commonly used ingress controller for Kubernetes environments today. If you think about what Kubernetes means for organizations that are building these modern applications, it’s giving them an environment that allows them to build typically microservices-based applications. So getting those applications exposed to the outside world requires the first thing, the foundational element, the hierarchy of need. It’s getting traffic in and out of that Kubernetes environment. How do you do that? Through the ingress capability.

    Our ingress controller is pretty much the number one solution out there for doing that today. That’s the first place people have to start before they get into some of the more complex or exotic things they’d like to be able to do. So our customers, our users are already benefitting from that. It’s allowing them to do what they need to do when it comes to adopting or testing Kubernetes for their own uses.

    Shimel: Sure. Lori, even independent of NGINX, what effect is this whole move to Kubernetes and container-ized environment having on F5’s business?

    MacVittie: Wow. On the business? Don’t really know. No. There is – we see a lot of customers asking. One, they want guidance on how to do this at scale and safely. A lot of our customers are very concerned about security, about performance. How do they bridge those two worlds, coming out of Kubernetes and trying to get into an environment where there’s a lot more traditional apps and infrastructure still supported? It’s trying to bridge those two worlds.

    Our customers are looking at it and they’re bringing it in and they’re adopting it, but they’re also having challenges with the deployment side where NetOps traditionally sit that they don’t have the skills to do the automation. They have problems with integration of the toolsets to build those pipelines. So one of the things that this kind of an acquisition does is bridge that gap. Hopefully we’ll see better integration and easier in and out, both actually in the flow of traffic, but also just between the teams in the businesses, so we think this will help address some of the pains at the people level in organizations by having this end to end delivery chain with both F5 and NGINX.

    Shimel: Sure. Sidney, maybe you would know. What are the plans with some sort of common interface or more integration between the two lines?

    Rabsatt: I’d say it’s still very early on. We have some good ideas, but we’re not really in a position to preview too much. I will say there’s going to be a focus on again, making sure we’re bringing the best of both solutions together. Again, not nearly as much overlap as you might have expected, or we – I should say as we might have expected. Yeah, what we’re looking at is really the opportunity to bring more features to the things we already have, more so than trying to get rid of things. We’re looking forward to getting this innovation stuff underway. We’ve had some very early conversations, but over the next days and weeks, we’re going to be digging into it very deeply.

    Shimel: Makes sense. Lori, so this was as we said right from the outset, what we’re turning to is a move up the application stack. What – is F5 done with that? Will we see more F5 potential either via the acquisition or holistically – organically moving up this stack here in the application world?

    MacVittie: I can’t obviously comment on any kind of [laughter] –

    Shimel: Can’t tell _____ acquisition is. I get that one.

    MacVittie: That’s right. With any company, that’s always a possibility. We have been transforming ourselves in the past year really moving forward with a lot more innovation in terms of exploring things and looking at – we’ve got Aspen mesh going, which is service mesh trying to bring some sanity to Kubernetes inside for scaling. Cloud services, we’ve made a lot of our services as a service. You just hook them up. We’ve been moving deeper into the application stack for a while. This is just going to accelerate that transformation from ADC to application services company.

    Shimel: Understood. Understood. Well, guys it really is exciting. One of the things I sit here at staging-devopsy.kinsta.cloud and Security Boulevard and we go to all of the conferences and we cover all the news, and you hear so much “What’s bleeding edge, bleeding edge, bleeding edge?” We tend to forget, or we overlook what are the nuts and bolts, the bread and butter that keeps the internet and these applications going? It is things like the NGINX web server that is the dominant web server in the world today. It is things like the F5 lineup of software and of _____ actually that have been delivering the internet to the public since 2002 or whatever it is. Lori, you probably know, but so it’s good to see innovation continuing to happen. It’s good to see new combinations taking place.

    I’m excited to see what comes out of – Sidney, as you said, it’s very early on. It’s a day after the acquisition was announced. Maybe we could check back in six months and see how things are progressing along these lines. In the meantime though, just the usual questions. Everyone from NGINX is staying on? There’s not going to be layoffs as part of the consolidations and stuff, or again too early to tell?

    Rabsatt: I mean what we know is F5 is interested in our organization and not just products. They’ve made it very clear they want the vast majority of folks to stay and we expect that to continue to be the case. We look forward to what the future holds together.

    Shimel: Yep, understood. Look, I wish you a lot of success, both you guys individually, as well as F5 and NGINX. It’s an exciting combination. Congratulations to both organizations and Lori, I think congratulations on especially to F5 for really making a real great addition to the family there.

    MacVittie: Thank you. I know there’s a lot of us. We’re just really excited about this and about the future and what we can do together.

    Shimel: Cool, cool, cool. All right, congratulations, guys. We’re going to call it a rap on this edition of DevOps Chat. Lori MacVittie for F5 networks. Sidney Rabsatt for NGINX, soon to be F5 Networks. Thanks for being our guest today on DevOps Chat. Thank you everyone for listening. You’ve just listened to another chat. Bye bye.

     

    — Alan Shimel

  • F5 Networks Acquires NGINX to Meld NetOps with DevOps

    F5 Networks Acquires NGINX to Meld NetOps with DevOps

    As part of an effort to better align DevOps and network operations (NetOps), F5 Networks plans to acquire NGINX, a provider of widely employed open source loading balancing software.

    The two companies revealed in a call with financial analysts that the primary goal of the $760 million deal is to meld the two companies’ combined expertise to develop application delivery controllers (ADCs) that are optimized for modern applications based on microservices.

    F5 Networks CEO François Locoh-Donou said F5 Network plans to continue operating NGINX as an independent brand in addition to maintaining support for the NGINX open source community. NGINX CEO Gus Robertson will become general manager of the NGINX business unit. NGINX founders Igor Sysoev and Maxim Konovalov also plan to stay on.

    Locoh-Donou also disclosed that while NGINX software is employed today at more than 375 million sites, the company only generated $26 million in revenue in 2018, mostly by providing commercial support to enterprise customers. F5 Networks will move to combine investments both companies have been making in containers to deliver a next-generation ADC optimized for microservices-based applications spanning multi-cloud computing environments, he said.

    As part of that strategy, however, both companies will need to come to terms with Envoy, an open source load balancing project led by the Cloud Native Computing Foundation (CNCF). Envoy is already providing the foundation for multiple service mesh projects that make load balancing a feature of a higher-level mechanism for managing services running on a Kubernetes cluster. Obviously, F5 Networks hopes to fulfill an opportunity to manage multiple instances of service meshes running on multiple Kubernetes clusters that.

    In fact, Locoh-Donou cited industry research that forecasts by 2022 there will be more than 198 million workloads running on some form of a microservices-based architecture. In contrast, 44 million workloads are expected to be running on legacy platforms.

    Locoh-Donou said F5 Networks also expects to leverage NGINX to expand its presence in application programming interface (API) management and associated web application services, which he noted collectively represent multibillion-dollar market opportunities.

    The decision to acquire NGINX reflects the inevitable melding of NetOps and DevOps, he added, noting that inconsistent approaches to managing application service across emerging microservices-based environments are a recipe for creating unstable IT environments.

    While it’s still a little too early to determine to what degree NetOps will be subsumed into DevOps processes, Locoh-Donou said F5 Networks plans to advance adoption of NGINX software by educating its core base of NetOps administrators on how microservices applications are deployed across extended networks and the rigors of the DevOps processes required to manage them.

    Both F5 Network and NGINX made a name for themselves by interconnecting IT environments made up largely of virtual machines. While virtual machines are not going away anytime soon, so-called cloud-native applications built using containers running on Kubernetes clusters require a different approach to delivering infrastructure services. The challenge facing the combined company is finding a way to deliver those services in a way DevOps teams want to consume.

    — Mike Vizard

  • F5 Acquires NGINX to Bridge NetOps & DevOps, Providing Customers with Consistent Application Services Across Every Environment

    • F5, the global leader in multi-cloud application services, announces the acquisition of NGINX, an open source leader in application delivery.
    • Strategic acquisition and organic investment to secure long-term revenue and EPS growth.
    • Together, F5 and NGINX will enable multi-cloud application services across all environments, providing the ease-of-use and flexibility developers require while also delivering the scale, security, reliability and enterprise readiness network operations teams demand.
    • F5 is committed to continued innovation and increasing investment in the NGINX open source project to empower NGINX’s widespread user communities.
    • F5 will maintain the brand with current NGINX CEO, Gus Robertson, and founders, Igor Sysoev and Maxim Konovalov, joining F5 to continue to lead NGINX.

    SEATTLE & SAN FRANCISCO–(BUSINESS WIRE)–F5 Networks, Inc. (NASDAQ: FFIV) and NGINX today announced a definitive agreement under which F5 will acquire all issued and outstanding shares of privately held NGINX for a total enterprise value of approximately $670 million, subject to certain adjustments.

    “F5’s acquisition of NGINX strengthens our growth trajectory by accelerating our software and multi-cloud transformation,” said François Locoh-Donou, President & CEO of F5. “By bringing F5’s world-class application security and rich application services portfolio for improving performance, availability, and management together with NGINX’s leading software application delivery and API management solutions, unparalleled credibility and brand recognition in the DevOps community, and massive open source user base, we bridge the divide between NetOps and DevOps with consistent application services across an enterprise’s multi-cloud environment.”

    “We believe every organization can benefit from the agility and flexibility enabled by modern technologies without compromising on security, manageability, and reliability,” continued Locoh-Donou. “The combined company will enable every customer—from the app developer to the network engineer to the security specialist—with the tools they need to ensure their apps are available and secure across every platform, from the enterprise data center to private and public clouds.”

    F5 will enhance NGINX’s current offerings with F5 security solutions and will integrate F5 cloud-native innovations with NGINX’s software load balancing technology, accelerating F5’s time to market of application services for modern, containerized applications. F5 will also leverage its global sales force, channel infrastructure, and partner ecosystem to scale NGINX selling opportunities to the enterprise.

    “NGINX and F5 share the same mission and vision. We both believe applications are at the heart of driving digital transformation. And we both believe that an end-to-end application infrastructure—one that spans from code to customer—is needed to deliver apps across a multi-cloud environment,” said Gus Robertson, CEO of NGINX, Inc. “I’m excited to continue this journey by adding the power of NGINX’s open source innovation to F5’s ADC leadership and enterprise reach. F5 gains depth with solutions designed for DevOps, while NGINX gains breadth with access to tens of thousands of customers and partners.”

    NGINX’s thriving open source community was one of the most attractive elements of this combination, and F5 recognizes the trust that the user community has in NGINX’s technology. Open source is a core part of F5’s multi-cloud strategy and a driver for F5’s next phase of innovation. As such, F5 is committed to continued innovation and increasing investment in the NGINX open source project to empower NGINX’s widespread user communities. F5 expects the combination with NGINX will accelerate its product integrations with leading open source projects and will enhance its strong technology partnerships with open source vendors.

    Upon closing of the acquisition, F5 will maintain the NGINX brand. Gus Robertson, along with NGINX founders Igor Sysoev and Maxim Konovalov, will join F5 and will continue to lead NGINX. Robertson will join F5’s senior management team, reporting to François Locoh-Donou. F5 will maintain NGINX’s operations in San Francisco, California and other locations globally.

    Transaction Details

    The acquisition of NGINX is expected to increase F5’s software revenue growth and increase the Company’s software revenue mix in fiscal year 2019. It secures F5’s Horizon 2 (fiscal year 2021 to fiscal year 2022) objectives of mid-to-high single-digit revenue and double-digit non-GAAP earnings per share growth. Short-term, the Company expects that the acquisition and organic investment in new and emerging solutions will result in modest earnings dilution in fiscal years 2019 and 2020.

    F5 provided the following regarding its Horizon 1 (fiscal year 2019 to fiscal year 2020) outlook, following the completion of the NGINX acquisition:

    Analyst and Investor Meeting
    Horizon 1 (FY19-FY20) Outlook, March 2018

    Post-NGINX Acquisition
    Horizon 1 (FY19-FY20) Guidance
    Total Revenue Growth Low-to-mid single-digit growth Mid-single-digit growth
    Software1 Revenue Growth 30%-35%+ growth 35%-40%+ growth
    Software1 as a % of Product Revenue Mid 20s% 25%-30%
    Non-GAAP Gross Margin ~85% ~85%
    Non-GAAP Operating Margin 35%-37% 33%-35%
    Non-GAAP EPS Mid-to-high single-digit growth Low single-digit growth

    1

    		 Software includes standalone Virtual Editions, including subscriptions & utility, and as a Service offerings

    All forward-looking non-GAAP measures included in the outlook exclude estimates for amortization of intangible assets, share-based compensation expenses, significant effects of tax legislation and judicial or administrative interpretation of tax regulations, including the impact of income tax reform, non-recurring income tax adjustments, valuation allowance on deferred tax assets, and the income tax effect of non-GAAP exclusions, and do not include the impact of any restructuring charges, facility exit costs, or other non-recurring charges that may occur in the period. F5 is unable to provide a reconciliation of non-GAAP guidance measures to corresponding U.S. generally accepted accounting principles or GAAP measures on a forward-looking basis without unreasonable effort due to the overall high variability and low visibility of most of the foregoing items that have been excluded. Material changes to any one of these items could have a significant effect on our guidance and future GAAP results. Certain exclusions, such as amortization of intangible assets and share-based compensation expenses, are generally incurred each quarter, but the amounts have historically varied and may continue to vary significantly from quarter to quarter.

    F5 intends to fund the transaction through cash on its balance sheet. In conjunction with the transaction, the Company is suspending its common stock share repurchase program. The Company will continue to evaluate market conditions and other factors including F5’s capital requirements in determining when and whether to continue such program and the levels of such program. The program does not require the purchase of any minimum number of shares and the program may be modified, suspended, or discontinued at any time.

    The acquisition has been approved by the boards of directors of both F5 and NGINX and, following execution of the definitive agreement, received the requisite shareholder approval of NGINX. It is subject to regulatory approvals and other customary closing conditions and is expected to close in the second calendar quarter of 2019.

    Foros acted as financial advisor and Wilson Sonsini Goodrich & Rosati provided legal counsel to F5 on this transaction. Qatalyst Partners served as financial advisor to NGINX.

    Investor Conference Call Details

    F5 will host a live webcast and conference call to discuss the transaction beginning at 5:30 p.m. ET, today, March 11, 2019. The live webcast can be accessed at: https://www.f5.com/company/investor-relations.

    To participate in the live call via telephone in the U.S., dial 800-593-9913. Outside the U.S., dial +1-212-287-1824. Please call 10 minutes prior to the call start time. The webcast replay will be archived on F5’s website.

    Additional Information

    About F5

    F5 (NASDAQ: FFIV) gives the world’s largest businesses, service providers, governments, and consumer brands the freedom to securely deliver every app, anywhere—with confidence. F5 delivers cloud and security application services that enable organizations to embrace the infrastructure they choose without sacrificing speed and control. For more information, go to f5.com. You can also follow @f5networks on Twitter or visit us on LinkedIn and Facebook for more information about F5, its partners, and technologies.

    About NGINX

    NGINX, Inc. is the company behind the popular open source project trusted by more than 375 million sites. We offer a suite of technologies for developing and delivering modern applications. The NGINX Application Platform enables enterprises undergoing digital transformation to modernize legacy, monolithic applications as well as deliver new, microservices-based applications. Companies like Netflix, Starbucks, and McDonalds rely on NGINX to reduce costs, improve resiliency, and speed innovation. NGINX investors include Blue Cloud Ventures, e.ventures, Goldman Sachs, Index Ventures, MSD Capital, NEA, Runa Capital, and Telstra Ventures.

    F5 is a trademark or service mark of F5 Networks, Inc., in the U.S. and other countries. All other product and company names herein may be trademarks of their respective owners.

    F5 Forward-Looking Statements

    This press release contains forward-looking statements including, among other things, statements regarding the continuing strength and momentum of F5’s business, future financial performance, sequential growth, projected revenues including target revenue and earnings ranges, income, earnings per share, share amount and share price assumptions, share repurchases, demand for application delivery networking, application delivery services, security, and software products, expectations regarding future services and products, expectations regarding future customers, markets and the benefits of products, and other statements that are not historical facts and which are forward-looking statements. These forward-looking statements are subject to the safe harbor provisions created by the Private Securities Litigation Reform Act of 1995. Actual results could differ materially from those projected in the forward-looking statements as a result of certain risk factors. Such forward-looking statements involve risks and uncertainties, as well as assumptions and other factors that, if they do not fully materialize or prove correct, could cause the actual results, performance or achievements of the company, or industry results, to be materially different from any future results, performance or achievements expressed or implied by such forward-looking statements. Such factors include, but are not limited to: customer acceptance of our new traffic management, security, application delivery, optimization, and software and F5aaS offerings; the timely development, introduction and acceptance of additional new products and features by F5 or its competitors; competitive factors, including but not limited to pricing pressures, industry consolidation, entry of new competitors into F5’s markets, and new product and marketing initiatives by our competitors; increased sales discounts; the business impact of the acquisition of NGINX and potential adverse reactions or changes to business or employee relationships, including those resulting from the announcement or completion of the acquisition; uncertainties as to the timing of the transaction; uncertain global economic conditions which may result in reduced customer demand for our products and services and changes in customer payment patterns; global economic conditions and uncertainties in the geopolitical environment; overall information technology spending; litigation involving patents, intellectual property, shareholder and other matters, and governmental investigations; natural catastrophic events; a pandemic or epidemic; F5’s ability to sustain, develop and effectively utilize distribution relationships; F5’s ability to attract, train and retain qualified product development, marketing, sales, professional services and customer support personnel; F5’s ability to expand in international markets; the unpredictability of F5’s sales cycle; F5’s common stock repurchase program and activities thereunder and differences may result from, among other things, actions taken by the Company or its management or Board regarding operations or strategy, and activities and conditions relating to pricing, trading, capital requirement and repurchasing of shares of F5 common stock including continued suspension or modification or discontinuation of the common stock repurchase program; future prices of F5’s common stock; and other risks and uncertainties described more fully in our documents filed with or furnished to the Securities and Exchange Commission, including our most recent reports on Form 10-K and Form 10-Q and current reports on Form 8-K and other documents that we may file or furnish from time to time, which could cause actual results to vary from expectations. The financial information contained in this release should be read in conjunction with the consolidated financial statements and notes thereto included in F5’s most recent reports on Forms 10-Q and 10-K as each may be amended from time to time. All forward-looking statements in this press release are based on information available as of the date hereof and qualified in their entirety by this cautionary statement. F5 assumes no obligation to revise or update these forward-looking statements.

    GAAP to non-GAAP Reconciliation

    F5’s management evaluates and makes operating decisions using various operating measures. These measures are generally based on the revenues of its products, services operations and certain costs of those operations, such as cost of revenues, research and development, sales and marketing and general and administrative expenses. One such measure is net income excluding stock-based compensation, amortization of purchased intangible assets, acquisition-related charges, net of taxes, and certain non-recurring tax expenses and benefits, which is a non-GAAP financial measure under Section 101 of Regulation G under the Securities Exchange Act of 1934, as amended. This measure consists of GAAP net income excluding, as applicable, stock-based compensation, amortization of purchased intangible assets, litigation expense, restructuring charges, facility exit costs, gain on sale of patents, non-recurring tax expenses and benefits, and acquisition-related charges. This measure of non-GAAP net income is adjusted by the amount of additional taxes or tax benefit that the company would accrue if it used non-GAAP results instead of GAAP results to calculate the company’s tax liability. Stock-based compensation is a non-cash expense that F5 has accounted for since July 1, 2005 in accordance with the fair value recognition provisions of Financial Accounting Standards Board (“FASB”) Accounting Standards Codification (“ASC”) Topic 718 Compensation—Stock Compensation (“FASB ASC Topic 718”). Amortization of intangible assets is a non-cash expense. Investors should note that the use of intangible assets contribute to revenues earned during the periods presented and will contribute to revenues in future periods. Acquisition-related expenses consist of professional services fees incurred in connection with acquisitions. In addition, non-recurring costs associated with the relocation of the company’s corporate headquarters have been excluded from GAAP net income for the purpose of measuring non-GAAP earnings and earnings per share in the first quarter of fiscal year 2019.

    Management believes that non-GAAP net income per share provides useful supplemental information to management and investors regarding the performance of the company’s core business operations and facilitates comparisons to the company’s historical operating results. Although F5’s management finds this non-GAAP measure to be useful in evaluating the performance of the core business, management’s reliance on this measure is limited because items excluded from such measures could have a material effect on F5’s earnings and earnings per share calculated in accordance with GAAP. Therefore, F5’s management will use its non-GAAP earnings and earnings per share measures, in conjunction with GAAP earnings and earnings per share measures, to address these limitations when evaluating the performance of the company’s core business. Investors should consider these non-GAAP measures in addition to, and not as a substitute for, financial performance measures in accordance with GAAP.

    F5 believes that presenting its non-GAAP measures of earnings and earnings per share provides investors with an additional tool for evaluating the performance of the company’s core business and is used by management in its own evaluation of the company’s performance. Investors are encouraged to look at GAAP results as the best measure of financial performance. However, while the GAAP results are more complete, the company provides investors these supplemental measures since, with reconciliation to GAAP, it may provide additional insight into the company’s operational performance and financial results.

  • NGINX Delivers New Products to Manage Microservices

    NGINX Delivers New Products to Manage Microservices

    At its annual user conference in Portland, Oregon, in September, NGINX delivered releases focusing on the application platform market and support of delivering microservices architectures:

    • NGINX Plus, an application delivery controller that combines a load balancer, content cache and web server.
    • NGINX Controller, a centralized management and monitoring platform for NGINX Plus, which orchestrates the delivery of applications across multiple environments, enabling companies to continuously deploy and update applications using tested and proven policies.
    • NGINX Unit, a multi-language server for applications, designed to work in highly dynamic environments. It features a full REST API that can be fully automated and used to deploy new application versions with no service disruption. It currently supports PHP, Python and Go with more language support coming soon.
    • The NGINX Web Application Firewall (WAF), powered by ModSecurity, which protects web applications against various Layer 7 attacks and provides DDoS mitigation, real-time blacklisting and audit logging.

    In addition to launching the NGINX Application Platform, the company has added the ability to use NGINX Plus as a Kubernetes Ingress Controller. Based on the open-source NGINX Ingress Controller for Kubernetes, this new feature enables the deployment of applications within Kubernetes and Red Hat OpenShift anywhere across a cluster so they can be reached by outside traffic.

    While these products combine to deliver a complete and manageable microservices solution, the most interesting of these is NGINX Unit. According to Owen Garrett, head of products, the complement of tools facilitates management of both north/south and east/west traffic for cloud-native applications. It’s small, lightweight, fast, polygot-enabled and programmable through an API and works with other Unit instances to deliver a service mesh.

    Key features of Unit that should be of particular interest to businesses deploying microservices relate to the ability to foster continuous delivery. For example, when the router accepts new configurations from the Controller process, the worker threads start to handle new incoming connections with the new configuration, while old connections can continue to be processed by the threads according to the previous configuration. That is: Router worker threads can work simultaneously with several generations of configurations.

    Additionally, Unit uses interprocess memory to communicate with the applications, thus allowing the Unit to provide greater agility in routing of HTTP requests. So, rather than forcing the application to directly listen, they can delegate network handling to the service mesh providing for increased scalability. They accept the clients’ requests, pass the requests to the application processes, get responses back from the applications and send the responses back to the clients. Each worker thread polls epoll or kqueue and can asynchronously work with thousands of simultaneous connections.

    — Alan Shimel