Oracle added Talari to its shopping cart, picked it up from the hot deals section
Oracle was on the top of my list as a potential acquirer of an SD-WAN company. There are several other large companies which I’m pretty sure will make their way into SD-WAN during 2019, some will probably take the DIY route while others will go for an acquisition. The surprise was the acquisition target, Talari.
A lot has been written about the acquisition of Talari by Oracle, most of the information was around the details of the PR and previous SD-WAN related acquisitions (VeloCloud by VMware and Viptela by Cisco). This information, to my view, is not the interesting part of the story.
This blog post was written last week after the acquisition was announced and was waiting for the noise around the acquisition to quiet down before being published, yesterday Zeus Kerravala posted on nojitter an interesting post that is pretty much aligned with my view.
Clearly, adding SD-WAN to Oracle’s product portfolio will help it enhance its Acme Packet acquired SBC (Session Border Controller) assets for perfecting VoIP traffic and supporting the Oracle cloud business. In this post I want to look deeper into the details and answer 2 main questions:
- What’s the main reason for Oracle to get into SD-WAN
- Of all the vendors around, why Talari
Why SD-WAN is a must for Oracle
The PR mentions 2 areas where SD-WAN is relevant for Oracle but Oracle’s cloud business has the strongest need for SD-WAN, it is imperative for Oracle to be able to offer high-quality cloud services. This is being said regardless of the strategic approach for getting the SD-WAN boost, acquisition, self-development, partnership or licensing. Apparently, an acquisition was the selected strategy. We’ll see about the vendor of choice later in this post.
As for enhancing Oracle’s VoIP business, I view this as less critical. Oracle could have reached this by partnering with several SD-WAN vendors having them run in tandem with the Oracle SBC alongside any SD-WAN vendor’s router. This is due to technical and business reasons.
Technical
The SBC is highly delay sensitive but it is typically also compute intensive due to the termination of encrypted traffic (at least signaling, in some cases also the media itself) and in some cases also the need to perform transcoding (changing the compression algorithm of the voice payload). Summing this up, not really efficient to run the SBC and the router in the same VM space, it will need to be 2 different VMs or even 2 different physical machines, hence, we will not see a real integration of the Talari and Acme (SBC) SW but rather them running side by side.
Additionally, the attempt to integrate the SD-WAN router with the SBC will be a pretty challenging project.
Business
Oracle is probably hoping to sell more SBCs once it also offers SD-WAN. Reality is that SD-WAN and SBCs are different elements, SD-WAN does enhance VoIP traffic but it is relevant for all of the organization’s traffic so there are several decision points for selecting an SD-WAN vendor that have nothing to do with VoIP.
Given these points, it looks like Oracle will still need to partner and work with other SD-WAN vendors in order to support its existing and future markets.
Why Talari
The decision to select Talari as the acquisition target vs. other vendors is not a natural decision for Oracle to my view. Over the past year I had several discussions with the Talari team both at industry events and on calls that resulted in an interview with their CEO Patrick Sweeney.
My understanding from these conversations was that the core technology and DNA of Talari is in the HW appliances and branch-to-branch. If you read the Talari page on SDnetIndex you can see that the focus is on-premise, HW and branch-to-branch (I guess I should ask them to update it). I do know that the Talari team has been working on their virtual/SW products that can also be deployed in the cloud, looks like this effort was successful. Having said that, the origins of the company is HW and branch-to-branch, even the Products section relating to edge devices is named appliances.
Talari is a veteran in SD-WAN, their technology goes back way before the SD-WAN term was coined so they should have strong technical assets. Migrating this technology to virtual products that run in the cloud vs. branch HW products is a big challenge and Oracle will need to see if the work that was done over the last year or so is satisfactory for Oracle’s cloud needs.
The acquisition itself looks mainly like a technology and team acquisition rather than a market presence acquisition. Oracle has a strong presence in the enterprise market, the ±500 customers of Talari is not going to make a significant change for Oracle. What might do the change is Oracle’s sales machine selling the Talari solution but that is a challenge by itself as it requires expertise the Oracle sales team doesn’t have and cooperation between the 2 different teams. At least in the case of the Acme Packet SBC acquisition, I don’t think sales of SBC increased in the first few years if at all.
So, let’s ask again, of all the vendors out there, why Talari.
Given the fact that this acquisition was mainly a technology and team one, the market share of Talari wasn’t the main decision point, it was enough to have a “good enough” market presence to prove the validity of the product.
It looks like Talari had the best presumed ROI for Oracle compared to other options. The company did raise over $50M but since it is around for more than 9 years now and completed round E (and we don’t know if some of the rounds were actually down rounds), it was probably a good time for the investors to checkout their investment at a number I assume was significantly lower than the $449M of the VeloCloud-VMware deal (this is my guess, numbers were not published). With revenue of $16-20M/year it looks like it was either being required to bring in more funding in 2019/20 (a hard task given multiple previous rounds and low revenue) or cash out.
A few other possible candidates Oracle could have gone for:
Silver Peak – They have a bigger market share and higher revenue (over $90M) but would have also been much more expensive, especially given the money invested in the company so far which is more than $175M.
Versa Networks – They could have been a good option. Maybe the fact that they mainly sell to service providers vs. Talari that mainly sells to enterprises was one of the reasons but I believe it was all about financials. Versa is around for only 6-7 years and so far, got a pretty moderate investment of a bit over $40M. With investors such as Sequoia, the stage they are in and the state of the SD-WAN market, I assume they are aiming for much more than Oracle was willing to pay.
128 Technology – Could have been an interesting option for Oracle, they already have good connections given the fact that the founders of 128 Technology are the founders of Acme Packet which Oracle acquired for the SBC technology and service provider market. The main reason 128 Technology was not being a valid option for Oracle is probably the number in which Acme Packet was acquired for, $1.7B, I can only assume that the founders are aiming for even a higher number this time, out of range for Oracle for this type of company at this given point in time.
Closing notes
Oracle had to get its feet into the SD-WAN market and they are not the last cloud company to do so. Question is, did they make the right choice with respect to the target they selected for acquisition. Financially Talari was probably a good deal. Technically, I’m not sure. It really depends on the advancement Talari has made towards cloud and virtualization in the last year or so.
I guess only time will tell If this was a good technical choice or not. I have a feeling this is not the last move Oracle will be required to do in order to reach a strong position in this market.
- Learn about security and SD-WAN integration, should you trust your SD-WAN vendor for security features?
- Learn more about the MEF work on SD-WAN standardization
- Never miss a post. Subscribe to TheNewDialtone
Leave a Reply