NGINX Service Mesh with Alan Murphy


Allen Murphy. Welcome to the show. Thanks Jeff thanks for having me you were with F. Five beginning back in two thousand five. This was about fifteen years ago. Described the load balancer market. When you started at the company it was all hardware. I mean it was big big iron big volume the bigger the better our customers back then were founded two camps. They were either colocation a data center. They were running their own but either way to customers who were buying a five hardware or aggregating tons of data through those boxes so we dealt with a lot of really high volume clients and then a lot of more geographically distributed technology like global s to be able to distribute traffic between multiple data centers in Colo but it was all just massive ingress single point. Traffic Win was there. This industry shift from physical load balancing infrastructure toward in augmentation of the software based load balancing. I think the big shift came. I guess the first indication that shift was coming was when Colo's and data center companies started offering more segmented in granular services companies like rex basis. Great example they did a great job. Kind of changing the market away from single point service single point entry to more virtualization distributed services. So there's definitely a movement at the data center level back then or maybe around two thousand ten two thousand nine hundred like that but the big shift. No question was cloud and it was the reliability the stability in the cost and accessibility associated with cloud. And that immediately flip the switch of conversation from hardware to software and from single point aggregate traffic management to distributed traffic management and did that causing the other downstream effects in the market like as we went from physical load balancing to software based load balancing. Sure I think it solved too big right. I should say introduced to big changes to the way companies handle their application infrastructure. One was that the more you software if you use that as a verb Maurice software the more granular. They can start managing their traffic so instead of just having his front door service that we used to call the bigger hardware aggregation point instead of having a front door service. They could start managing traffic managing that door. So that kind of that first step gate closer and closer to the APP so further down the stack. I think that was a huge downstream. Change that moving to software naval virtual leising traffic management itself enabled and then I think the second one was the change of ownership so before they were typically one or two teams that were responsible for all of the traffic management functionality because they handled it all in that shift to software in that desegregation of the application stack of the services of the traffic management brought new teams into managing traffic. And today. We're we're talking with devops. You know down in the weeds. Day to day development engineers who have to deal with traffic management so huge changes downstream and the shift to software define networking was this all managed by commodity infrastructure or. Were there still specialized types of servers that needed to be used to host the load balancing and networking infrastructure. As things. Move to the cloud? I think it came down to what type of traffic was being managed. I think commodity whether it's hardware-software commodity for your run of the mill. Http traffic can absolutely be handled by a number of different services in different form factors in different locations and environments but when we talk about very specialized traffic management or the the function of that traffic management. You start to see less and less commoditisation. So if we're talking about their application aware traffic management for what we now call. East WEST TRAFFIC SERVICE TO SERVICE. Traffic for micro services. There's still a level of awareness and understanding environment the kind of moves it out of the commodity requirement or commodity bucket. And then if we're talking about really specialized traffic for service providers for financial institutions that have kind of their own way of formatting traffic of passing traffic but also traffic reliability. I think they're still absolutely a need for specialized components whether again those are hardware-software on Prem cloud doesn't matter the the more specifically towards the application need the more will still need specialized very very fine tuned application delivery software hardware. I do want to eventually get to a discussion of modern software defined traffic networking and Specifically Service Mesh Conversation. But since you've worked in this area for for so long and you've interacted with a lot of different client basis. You just mentioned that different verticals might have different needs for the hardware. Perhaps the software that they use to manage their networking infrastructure so financial services for example. Tell me more about how different verticals might have different needs for the networking infrastructure? Sure we definitely say it again if we're talking hardware software but it's a really interesting space to kind of zero in on what those differences are talk about a couple of examples so financial fintech fencer. Those companies are very very dependent on insanely high reliability. And it makes sense right. We need low. Latency high volume transactions for things like economic trading. We need the ability to embed security controls into the application language itself. The application traffic language so Fintech. They're very focused on something like low latency high availability if you look at service provider kind of four g historic service provider also very concerned with low latency but massive massive volumes of very large types of traffic. So we're talking about over. The top providers companies like Netflix need to distribute their content over service provider network those companies that service providers are very very focused on high resiliency high availability. But for much much bigger larger traffic patterns than you'd seen Fintech for example five G. brings a whole different scope to that because now we're talking about pushing services closer to the edge containerization still that high volume but now the ability to carve out that traffic in a different way that we would in a traditional infrastructure I think healthcare is another very interesting one because security regulations government control over that data or rather government control over how that data is used in access is paramount. Way also talk a lot about remote working when we're in healthcare prior to everything that's going on today. We talk a lot about big big software components that need to reside on site but they need to communicate back to a centralized secure cloud environment. So then we're talking about regulations and how to keep data sandbox and highly secure. So it's really really interesting to these. Larger verticals do have these different traffic necessities that require either specialized components or at least very their application aware components and F. Five. Now is the owner of engine necks. And we'RE GONNA be talking somebody today. You've spent considerable time working at F. Five as well as in genetics and both of these companies are heavily used products to define the the networking infrastructure for different companies so it. Fiv historical application has been the hardware load balancer. But it's moved into a lot of different software services that are required for networking. Dns infrastructure in. Genetics has been used as an edge proxy for a long time cashing infrastructure reverse proxy ing. Load balancing. I like to understand the acquisition from your point of view when f five acquired engine X. Why did that acquisition make sense? As you mentioned I was at the genetic side when acquisition happened from the moment I was super excited. It made complete sense to me when I left at five. Had been there for about ten years as you mentioned so let's in two thousand fifteen and the F. Five culture at the time was very much focused on helping customers support their software their drive the software and it was an exciting time at five but at the same time there was also this kind of internal understanding that hardware is still an important factor absolutely drives a lot of the customer requests and we still have those verticals that we talked about like service provider in two thousand fifteen when I left him of two genetics. It was a great opportunity to focus on as you mentioned the exact opposite side of that coin which is one hundred percent software but also one hundred percent. Devops an application focused deployments so all of our customers engineers were focused on application level. Reverse proxy and embedding that reverse proxy functionality. As literally close to the APP as you can get in today. We'll talk about sidecars a few minutes in that regard but it was very much focused on software. Only get the packet to the APP and then let's figure out how to handle it soon as it gets into our environment and software space so when the acquisition happened even with that kind of four year gap between Lena Five and then rejoining it made perfect sense to me because it kind of melded. The Best of those two worlds but also filled gaps where f five is predominantly hardware. Front door service with Dr. The software engineer was virtually one hundred percent software but starting to deal with kind of higher level network in order. That things like containerized networks. Bring in so that being able to put those two together of hardware network deep history understanding software application delivery deep industry understanding. Bring those together. It just filled both gaps so eloquently so perfectly made perfect sense and I was super excited to come back into F. Five with that software mentality and win that acquisition happened. You help build out some of the strategies for integrating with cloud providers and this is an interesting strategic task to build. Because you have these these gigantic cloud infrastructure providers that are to some extent providing commodity services in. And then you have. They have their specialized services that they built as well. But there was this huge reorientation while the orientation reorientation in the Industry. That's still going on. For how companies that are not cloud providers companies that are not these gigantic infrastructure providers integrate with the cloud providers tell me about defining the strategy for F. Five to integrate with cloud providers. I can speak first to the engineer strategy in the work that we did there in my role when I first joined in. Genetics was to help design some of that from the technology perspective. So what are the where the technology roadblocks? What are the hurdles? We need to get around what we need to provide those cloud providers from the genetic space and we were very fortunate because we had such a huge market awareness and breadth of deployment at engine X. Pretty much everybody in the world is using in genetics. So that in itself was driving questions back to us of. Hey we're moving our infrastructure into aws for example or GCP. We WanNa take that same functionality of genetics into that environment so on paper it was a literal transition. You're running engineering software on PREM PICK IT UP and move wherever you want still works today and we had so many customers who follow that model but at the same time we also had customers as you mentioned who are coming to US insane. Were either trying to build more intelligence into the cloud platform. We don't want to do just lifting shift or we WANNA consume some of the tried and true in Jenex resources through a consumption based model in the cloud so we had as you'd expect a really really strong marketplace offerings and all the cloud providers to someone could purchase genetics in a consumption based model. That was fine but we also spent a tremendous amount of time working with those providers on what value can engine x. Helped bring them in today. Some of the the largest platform tools incorporate engineering a lot of people use genetics without realizing its genetics. Because we have that flexibility and

Coming up next