Tag: acquisition

  • WhiteSource Acquires Renovate to Automate Dependency Updates

    WhiteSource Acquires Renovate to Automate Dependency Updates

    WhiteSource has acquired Renovate, a provider of an open source automated dependency update platform that the company plans to make available for free.

    Rhys Arkins, co-founder of Renovate who is now director of product for WhiteSource, said that as software projects become more complicated, there’s an increased need for a mechanism to identify and track dependencies and automatically update them as changes and updates are made.

    That requirement is becoming especially acute with the rise of microservices-based applications, which substantially increase the number of dependencies that exist within and between applications, added Arkins. Microservices make it possible for DevOps teams to build and deploy applications faster, but the dependencies between the microservices often result in an application environment that becomes too complex to manage. Most recently, Renovate added support for Helm Charts used to package applications in Kubernetes environments, on which many microservices are now being deployed.

    In addition, WhiteSource plans to add support for Cocoapods, a dependency manager for Swift and Objective-C Cocoa projects.

    Prior to the acquisition, WhiteSource was reselling the Renovate platform, which has more than 150 contributors. Now that WhiteSource owns the Renovate platform, including a hosted GitHub application and self-hosted GitHub and GitLab applications, the company has decided to make it available for free under the WhiteSource Renovate brand name.

    In the future, The WhiteSource Renovate app will add support for Bitbucket Cloud and Azure DevOps, thereby expanding the sources of dependency data that can be employed to make updates less risky and time-consuming, said Arkins. In effect, WhiteSource wants its automated dependency platform to become a natural extension of any continuous integration/continuous delivery (CI/CD) platform, he added.

    Arkins said that when it comes to managing dependencies, the biggest challenge is getting developers to identify them. In the absence of a platform for managing that process, developers will either not declare dependencies at all or, more commonly, not provide the right version number for a specific release of software on which their application is dependent. The more automated that process becomes, the less likely it is DevOps teams will find applications breaking because of a dependency that they were unaware of or lost track of at some point during the project.

    With the rise of DevOps, many organizations are now employing a more structured approach to dependencies. However, Arkins noted, many organizations are unaware that an open source platform is available that automatically updates all dependencies.

    WhiteSource is best known for helping organizations discover vulnerabilities in open source code. With the acquisition of Renovate, the company is furthering its ambitions to become a provider of software composition analysis tools.

    It remains to be seen just how many organizations will incorporate an automated dependency update platform into their DevOps processes. While many organizations have embraced DevOps, the level of maturity in terms of DevOps sophistication is uneven. The more software projects an organization launches, however, the more likely it becomes apparent there is a need for a better way to manage software dependencies.

    — Mike Vizard

  • DevOps Deeper Dive: DevOps Arms Race Heats Up

    DevOps Deeper Dive: DevOps Arms Race Heats Up

    A massive amount of capital is pouring into DevOps companies as organizations finally begin to realize the extent to which they depend on software. While Marc Andreesen may have penned his famous “Software Is Eating the World” opinion piece way back in 2011, it’s only now that many organizations are starting to realize they are software companies that also manufacture something or specialize in the delivery of some type of digital service.

    The most recent example of a massive injection of capital into the DevOps space came in the form of a $268 million investment in GitLab earlier this month. That move followed the acquisition of SignalFx, provider of an application performance management (APM) platform, by Splunk in a deal valued at just over $1 billion.

    Arguably, DevOps vendors have been gearing up for this fight for the better part of the last decade. Way back in 2014, New Relic picked up $115 million after going public. Three years later, Cisco Systems acquired AppDynamics for $3.7 billion.

    Now all these companies are racing to build the platform through which organizations of all sizes will transform themselves into true software companies by embracing best DevOps practices infused with large amounts of artificial intelligence (AI).

    DevOps as a concept has been around now for the better part of a decade. However, it’s only now that organizations are embracing DevOps across the entire application development life cycle. Previously, organizations embraced DevOps within isolated areas of the IT organization. Today, there is a much more concerted effort underway to apply DevOps practices to build and deploy software on an industrial scale.

    Achieving that goal, however, will require a lot more than simply adding higher levels of automation to a continuous integration/continuous deployment (CI/CD) platform. As business leaders realize how dependent the organization is on new applications to drive additional revenue, they are demanding more visibility into the software delivery process. Every delay to a software project now has revenue implications for the business.

    As more organizations come to that realization, it becomes apparent that monitoring software continuously as it is being built and after its deployed is now crucial to the business, said New Relic CEO Lew Cirne.

    “If mission-critical software not working, then the business is not working,” he said. “You must watch it all; you can’t pick and choose.”

    To become the de facto standard within an organization for monitoring those processes, DevOps vendors are racing to build DevOps platforms capable of operating at unprecedented levels of both scale and speed, said SignalFx CTO Arijit Mukherji.

    “The scale of the data has increased,” Mukherji noted. “Everything needs to happen in real-time.”

    DevOps platforms need to be extended to include support for everything from distributed tracing to machine learning algorithms, which organizations will rely on to identify the patterns employed to build AI models, he added.

    That level of investment requires a lot of additional capital that DevOps vendors either need to raise or, in the case of SignalFx and AppDynamics, tap into as a subsidiary of a larger company.

    The rise of microservices is further exacerbating those challenges as the number of dependencies within and between smaller segments of code increases. That fundamental shift in application architecture will require organizations to re-engineer DevOps processes across both the application and infrastructure levels of the entire IT environment, said Matt Cleve, director and global lead for Business iQ at AppDynamics.

    “Real-time visibility into the entire application stack is going to be a lot more important,” Cleve said.

    AppDynamics and parent company Cisco together will be in a unique position to deliver on that promise, he added.

    A recent survey conducted by the Harvard Business Review (HBR) on behalf of AppDynamics finds only 22% of IT organizations have access to any kind of real-time IT metrics.

    Widespread adoption of best DevOps practices has been a long time in coming. What is clear now, however, is that the organizations that take full advantage of DevOps by the end of this decade will thrive the most through the next.

    — Mike Vizard

  • DevOps Chat: Splunk Moves Into Microservices With Omnition Buy

    DevOps Chat: Splunk Moves Into Microservices With Omnition Buy

    Swiftly after announcing its acquisition of SignalFx, Splunk is vaulting into microservices tracing by announcing its intention to acquire Omnition. Tech companies are rapidly making acquisitions to strengthen their position in the DevOps and contemporary cloud-native software stack.

    Rick Fitz, SVP and GM of Splunk’s IT Markets Group, joins DevOps Chat to share with us the drivers behind Splunk’s move into microservices and service mesh tracing. Information about Omnition is in short supply as Omnition’s been in stealth, racing to develop a product to address the observability needs of DevOps teams. Omnition has received some notice through its contributions to OpenCensus open source, now being merged into OpenTracing.

    In addition to this episode of DevOps Chat, check out Mike Vizard’s article about the Omnition announcement.

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

    Transcript

    Mitch Ashley: Hi, everyone, this is Mitch Ashley with devopsy.kinsta.cloud and you’re listening to another DevOps Chat podcast. Today, I’m joined by Rick Fitz, SVP and GM of the IT Markets Group at Splunk. And tailoring onto some recent news, the topic is about Splunk’s intention to acquire Omnition. They announced that on September 4th. Rick, welcome to DevOps Chat.

    Rick Fitz: Thanks, Mitch. Happy to be here.

    Ashley: Great to have you on. Would you start just by introducing yourself, tell us a little bit about what you do? And I’m sure most people know Splunk, but maybe a sentence or two about Splunk.

    Fitz:  Sure. A little bit about me, I’ve been building commercial software my entire career, and started out as a developer working for companies that were development oriented, and then the last 15 or 20 years, I’ve been working on just developing software for IT operations and application development teams in a commercial fashion.

    And in my new role now, I’m here as a General Manager, so I’m an executive here at Splunk, responsible for our strategy and vision of what we’re doing in the company. For those who don’t know Splunk—shame on you, darn it.

    Ashley: [Laughter]

    Fitz:  [Laughter] But let me tell you a little bit about the company. We are the company that actually built and invented, if you will, the ability to index logs at scale. And it made it really easy for the IT practitioners of the world to search that data and find, through an investigative lens, find the actual answer to those murky problems that are always out there. And so, the company is roughly 5,000 employees now, and growing very rapidly. So, we’re headquartered in California.

    Ashley: Well, just a little bit of trivia. I can’t claim credit for this, but I came across Splunk in probably 2006 or so at, I think it was an RSA conference. Tiny little booth, great ideas. Like, this is a cool idea. And of course, the company’s done really well, and I later became a customer of Splunk. So, congratulations on all the success and glad to see that you’re there, too, of course. Well, let’s talk—

    Fitz: Well, I thank you for being a customer.

    Ashley: Oh, absolutely, absolutely. [Laughter] So, let’s talk about Omnition. A lot of people may not know about them. Maybe they do, if they’re open in the—or involved in the OpenCensus, OpenTracing, OpenTelemetry projects, if I can say that right.

    Fitz: Mm-hmm.

    Ashley: They may know them from that, but they’re in ________ so there hasn’t been too much about Omnition. Tell us about that company.

    Fitz: Yeah. The—first, I’ll back up a little bit and kind of let you know why we even picked up a company called Omnition that no one really knows about. [Laughter]

    Ashley: Sure, that’s a good question, too.

    Fitz: The reality is that, in these large, cloud native worlds that a lot of us are starting to develop in, all kinds of things are changing. The things that we build on, the infrastructure we build on, the compute surface, the storage surface, there’s all these things that are now services that are available to us to leverage as application developers.

    And the other thing that’s changing pretty dramatically is just the way we actually build applications. The way we try to attempt to continuously integrate them, continuously deliver them. And perhaps one of the most profound things that’s occurred is that developers are now being asked to kinda own their code and they’re being asked to be on call or being asked to resolve issues.

    And so, if you will, they’re starting to become, as your website suggests, DevOps professionals.

    Ashley: A la DevOps.

    Fitz: Yeah. [Laughter] These trends start to kind of cause a paradigm shift—well, they have, actually, created a paradigm shift in the way you monitor. So much so that, probably over the last couple of years, DevOps practitioners have been talking about monitoring as—they’ve labeled it as a new world called observability.

    Ashley: Mm-hmm.

    Fitz: You know, I’ve been here around enough to know it’s simply monitoring. But I think what they’re trying to point out is that you need to observe the behavior of the data from the systems in order to make your lives easier. And that data comes in the form of logs, which is what Splunk has been known for a long time. It comes in the form of digital exhaust coming from monitoring tools in the form of metrics, which is really important.

    And then the last thing—and if you’re an application developer, I think we can all kinda relate to this—is the traces, the traces that actually come from the application code itself being executed are really great uses of good information.

    But all three of those things combined, the logs tell you kinda the root cause, the metrics tell you kind of what’s going on—is there a measurement that’s out of whack? Do I need to do something proactively to cause something to remove an error?

    And then the traces are really good for that logical layer—that logical layer telling you where to look. Do I have a backing problem? Do I have a code problem? Is it my problem, or is it a front end problem? And that kind of isolation is really important to trace it.

    So, that leads me to answer your question is that, you know, Omnition. Omnition was actually founded in 2018. The team is very small. They were in stealth mode, meaning they were building an application that was focused on tracing, and very specifically, they had a couple tenets in mind when they wanted to do this. They wanted to leverage open source. So, you mentioned that they’re big open source contributors, specifically to the OpenTelemetry project.

    And the other thing that they wanted to do is, they wanted to build this logical topology model that would allow you as a practitioner to isolate where a problem resides. And that was a pretty—it is a pretty novel way of looking at this particular problem. And it’s important, because having a thousand traces isn’t terribly intuitive or useful for a developer.

    Ashley: [Laughter]

    Fitz: But being able to isolate that it’s a front end problem so I can go talk to the guys that are in charge of that—or maybe it’s my logic that’s causing it, but maybe it’s a network issue, firewall issue or something like that. Or maybe it’s outside my firewall and I’m dealing with some latency issues from the world around us.

    Ashley: Mm-hmm.

    Fitz: But you need to be able to isolate that problem so you can solve it. So, long winded answer is, these guys, this team really figured out how to build this logical topology sitting on top of this trace data, leveraging open source—so, pretty darn powerful.

    Ashley: What I was really excited about with this announcement is, one of the things that I talk with companies about and work with them oftentimes is what DevOps, in this fundamental way that we’re creating more cloud native applications, how this really changed the way organizations work as well as how we create software, which I know you speak a lot about.

    And in some ways, what we’re doing is through this kinda granularization of functionality into containers, microservices, mesh—service mesh—it’s very interesting, because you can do lots of great things with it. But it makes the complexity of operating and monitoring—as you say, observability—even more difficult. So, that’s created this whole new cottage area, if you will, which is what Omnition went about, and actually some of the, they’ve had some developers who came over from Lyft, I think, went over to Omnition to help solve this problem.

    So, it’s fascinating to me to see Splunk bring this, this quickly, into your kinda product portfolio of companies, or at least that’s what we expect to happen with the acquisition, that you’re jumping right into service mesh, microservices, and observability, the monitoring of that. So, it seems like it’s a natural fit—maybe, you know, sooner than I expected it to happen, actually.

    Fitz: Here’s what’s interesting. I mean, we have the luxury of a lot of—you know, being around for a while and talking to a lot of our large enterprise customers that are going through this digital experience. You know, they’ve done their lift and shift, they’ve moved to kinda the lift, shift, and augment, and now they’re building a whole new series of cloud native digital services. So, they’re building in this new cloud native way. And when you start to talk to them, they recognize the problems, and they realize there has to be a way of doing this.

    And what we’ve found was, a number of them were trying to build it on their own, or they cobbled together a prototype that actually would kind of get ‘em there, give them some visibility. And then having a lot of those customers kind of advise us—because they’re very large customers at Splunk because of the fact that logs are a critical component of this strategy. But they were building the rest on the side, and in some cases, you know, using other companies to try to do it.

    And we just quickly realized that this is an opportunity for some of our largest customers, for us to come in and help them with this very critical issue and build alongside them as we move forward.

    So, yeah, we recognize that certainly the tracing part of this world is pretty new, but we think it’s the right approach, it’s the right answer to a long-standing problem, and I think the application architectures are at a stage in this cloud native world where this is perhaps the only way that this is gonna be accomplished. So, that’s why it was so strategic for us to do this.

    Ashley: You know, like, observability kind of being replaced for the term monitoring, tracing is also used—you used the word “also”—as kind of a new term in this service mesh, microservice world. Does it have a fundamentally different meaning to you as to what log analysis and things like that—is it substantially different or is it just an extension of what we’ve been doing in a non-container, non-microservice world?

    Fitz: Well, the only analogy is, it tends to be text, [Laughter] and you have to put it somewhere. And actually, some of our customers were putting it in the log and then extracting it, but that’s useful if you’re looking for one specific trace, but if you can imagine some of these applications are throwing up hundreds of thousands of traces a second, and sifting through that, while you can search through it, it’s great, but you really do need some analytics on top of it to organize it in a way that creates useful information. And that, I think, is again what Omnition has done.

    You know, answering the question, “Is this different from the old approach?” You know, I had the opportunity to work with an early Wily team. They had been acquired by CA Technologies, and I got to work with the team, which is an APM company. And the team actually invented bicode instrumentation, which is a way of doing instrumentation of the application on the fly. And it was very novel, because at the time, the operations teams were responsible for monitoring and the developers weren’t. So, the only way they could get their developer team to get visibility into the application—because they couldn’t tell their developers to actually put stuff into the logs.

    Ashley: Mm-hmm.

    Fitz: Well, they could ask. [Laughter]

    Ashley: [Laughter]

    Fitz: But they just couldn’t demand.

    Ashley: They might have ________.

    Fitz: Exactly. [Laughter] You know, us developers, how we are. And so the funny, interesting thing about that is, we tended to sell to the operations teams, so they could get that visibility into their application. In the open tracing world, because the onus, and it gets back to this DevOps ________, the onus is actually upon either an SRE function or, if you will, a DevOps function to establish the standards and policies. Those policies have been enforced by that team, and therefore, the developers, before they can actually bring product into production or bring code into production, there’s ________. And now, all of a sudden, you’re getting a lot more visibility and a lot more fidelity inside the code by that enforcement.

    And then, of course, open tracing is now on to its own standard, so you’ve got a standard to kinda drive. Before, there was no real standard, so you were just putting stuff into a log. And therefore, it’s hard for a vendor to look at it and develop an application to give you visibility into it.

    So, that’s definitely some of the big shifts that have caused this new paradigm to actually emerge, which is pretty awesome.

    Ashley: I think I saw in a blog post either on your site or Omnition’s that their investment and contributions to OpenTracing is something you’re likely to continue and support and want that to continue, is that correct?

    Fitz: Oh, absolutely. Absolutely. We’ve actually been, at Splunk, probably for the last four or five years, pretty definitely contributing to open source more, leveraging open source. We’ve been kind of on that bandwagon for quite some time. But this one, it makes a ton of sense. Both the OpenCensus and OpenTracing have now converged into OpenTelemetry. It makes a lot of sense. And I think that this is definitely where the world is—where it’s headed. I think it’s long overdue, actually. [Laughter] I’m glad to see these things kinda moving forward.

    Ashley: Given the players involved, I think if I recall right, OpenCensus was started by Google, but quickly followed by Microsoft and Dynatrace and Omnition—

    Fitz: Yeah.

    Ashley: – I think was part of this effort, too. So, it’s got some important names behind it.

    Fitz: Yeah, and most of the monitoring companies out there that are touching on applications are participating. So, I firmly believe it will take on as a standard. I think that’s pretty clear.

    Ashley: As you were considering an acquisition like Omnition, what were you hearing from your customers that led you to say, “We need to go find a company” or, “We found somebody like this. This would be a great fit for some of the problems and needs requirements that’s awesome we’re hearing from customers”? What was it that’s behind that, what you’re hearing from customers?

    Fitz: Well, there’s the big part of kind of the equation was this idea that we can use OpenTelemetry and spit this data into a log. But that’s good. I mean, that’s a great first step. I can search for something and that’s a fantastic, great step.

     But very quickly, the customers that we were dealing with at scale, they were saying, “You know, what’s interesting is that all this data—I have the data, but I can’t find any useful information out of the data, you know? I’m struggling with that.” And so, you know, we were in there building, on top of Splunk, the ability to model it and do different things. And we realized there’s the answer. The answer is to develop some form of analytics on top of this big, rich set of data that provides you really useful insight.

    And then, from my APM experience and FHIR experience, you know, the whole idea was having kind of a logical topology that represents the application, and I mentioned some of those words meaning back ends and front ends on the application itself. So, once you have that meta model in your mind and can decorate it with trace information, it becomes incredibly powerful. And that’s—when I broach the subject with our customer and said, “Is that really what you’re looking for?” they said yes.

    And so, we’re surveying the market and seeing is there anything out there, and then Omnition popped up, and it was like—wow, it’s a good day. [Laughter] It’s a perfect day for us, because we would’ve had to build this, and I think this team, with the expertise they have and the smarts they have is gonna be a welcome addition to the team and help us do it for us.

    Ashley: They do. They do have some great people. Now, Omnition, as I understand it, they describe themselves as a SaaS company. I assume this is a SaaS service that they’ve been building. Is it something new for Splunk in terms of a SaaS offering, or does this fit in well with other things that you’re doing?

    Fitz: No, it fits in very well. You know, SaaS grows from a business perspective as a very high growth business for us. We tend to, because data has gravity, [Laughter] we tend to have our software where the data resides. But more of that data is starting to reside in the cloud, so you know you’re starting to see people, as I mentioned, lift and shift or lift and shift and augment or building kind of in a cloud native way.

    So, we’re definitely—we’re part of that trend as well, and we think it’s the smart thing for all of us to get there. So, yeah, we are definitely gonna be SaaS on this particular offer, for sure.

    Ashley: Well, that makes sense, too, doing cloud native if you’re doing microservices, service mesh—more than likely, that’s gonna be stuff in the cloud. So, having Omnition there as well, that seems like the place to be, the right place to be.

    Fitz: Yeah. You know, it’s interesting, I was telling some sales reps yesterday, we were talking and I said, “You know, I contrast the conversation that I had with somebody who owns the data center with somebody who’s working in a cloud native way, and the vocabulary is completely different.” [Laughter] You know?

    Ashley: [Laughter]

    Fitz: Nobody says on premise or cloud—they just don’t think that way. They just assume that it is all cloud, you know? Whereas if you talk to somebody that’s still in a data center, they wanna know where the data is, where do I stack it, where do I rack it, where do I plug it in?

    And so, there’s definitely a difference in that cloud native world, the way people think.

    Ashley: Well, I’ve often had to believe, maybe learned over time, is that you can tell who drew the picture of a diagram on the whiteboard. Whatever is at the center is the data—if it’s the data center people who drew it, if it’s the cloud, it’s the cloud people.

    Fitz: Yeah.

    Ashley: But it’s interesting the transition we’re making with multiple companies investing in cloud management platforms, even down to storage providers and VMware and others. You know, I think eventually we’ll stop talking about hybrid. Everything’s a cloud, whether it’s just in your cloud or somebody else’s cloud and it’ll be managed much the same way. That’s where we’re headed, anyway.

    Fitz: Yeah, and I kinda share that point of view. I think, organizationally, we have to kind of force some of that standardization of vocabulary just to make our lives work. [Laughter] I think it’s gonna get—

    Ashley: Well, it’s also—yeah. [Laughter] I also think you have to do it from a cost standpoint, right? Complexity, managing a physical data center one way and then all these different clouds a different way. So, anyway, a whole ‘nother topic for another time.

    Fitz: Yeah.

    Ashley: We have just a little bit of time left—is there any message that you wanna make sure that gets out to listeners, to customers, future customers about the path that Omnition sets you down or other things about this pending acquisition that we wanna make sure folks know?

    Fitz: Yeah, let me just kinda share a couple things. One is, as I opened with, I think this world of observability is certainly all about having logs as well as metrics as well as traces. Just a couple weeks ago, we actually also announced our intent to acquire SignalFx, so we’re bringing in some of that metric capability. We’ve been known for years to be the log company, and then of course, Omnition is helping us with our tracing capability.

    And so, I think the combo is gonna be pretty darn powerful. I’d encourage your listeners, if they get a chance, if they wanna join us in Las Vegas this year at our .conf, which is our conference. We’ll be talking a lot about what we’re doing there and getting everybody up to speed. And if you can’t attend, all that stuff is posted online, too. You can check us out there, as well.

    Ashley: Yeah, there are definitely some great videos out there, too. Well, I wish you all the best with the acquisition and future business with Splunk. I just want to say thank you—Splunk is a great product, and when I had the opportunity to introduce it in organizations that I was running, all positives. So, it made a big difference in our world, and I think your move into observability around microservices, et cetera, is fantastic, and we appreciate you taking those steps.

    Fitz: Well, thank you. Thank you, Mitch, and thank you to all the listeners for your kind words. I’m sure you’re gonna share with me online later on.

    Ashley: Well, thank you, Rick—Rick Fitz, SAP and GM of the IT Markets Group at Splunk for joining us on the podcast today. And, of course, I’d like to thank you, our listeners, for joining us as well. This is Mitch Ashley with devopsy.kinsta.cloud, and you’ve listened to another DevOps Chat. Be careful out there.

    — Mitchell Ashley

  • Splunk Adds Omnition to DevOps Portfolio

    Splunk Adds Omnition to DevOps Portfolio

    Splunk followed up on its pending acquisition of SignalFx, a provider of an application performance management (APM), by also acquiring Omnition, a startup building a distributed tracing tool accessed as a software-as-a-service (SaaS) application.

    Rick Fitz, senior vice president and general manager for the IT Markets Group at Splunk, said Omnition consists of a small team of developers who have been especially active in maintaining OpenCensus, an open source set of libraries for various languages that make it easier to collect application metrics and distributed traces and then transfer the data to a backend of choice in real-time; and OpenTelemetry, a project led by the Cloud Native Computing Foundation (CNCF) that merges OpenCensus and OpenTracing to standardize the instrumentation and telemetry data collection.

    Distributed tracing is emerging as a requirement for APM platforms because the IT environment is becoming both more complex and ephemeral. Serverless computing frameworks are especially challenging because the only way to know an event occurred involving, for example, cloud bursting is to employ distributed tracing. The challenge is, distributed tracing requires organizations to capture, store and analyze massive amounts of data to pinpoint the root cause of any application performance issue, noted Fitz. As such, distributed tracing tends to be employed only by the most elite DevOps practitioners, as implementing distributed tracing is nontrivial, he added. On the upside, distributed tracing reduces the need to deploy a large amount of agent software across the enterprise.

    Fitz said Omnition will provide a set of capabilities that over time will be added to the SignalFx platform. Long-term, Splunk hopes to reduce the costs associated with distributed tracing to the point where that capability becomes democratized, he added, noting that as organizations embrace microservices to build cloud-native applications that will run in hybrid computing environments, increased reliance on distributed tracing is now all but inevitable.

    In general, Fitz said Splunk is working toward combining the best elements of DevOps with traditional IT service management (ITSM). Most organizations will be employing both approaches for years to come simply because some applications don’t need to be updated regularly, so it doesn’t make any sense to apply DevOps processes to those applications, he noted. At the same time, as DevOps processes are embraced in enterprise IT environments, appreciation is growing for IT operational challenges that stem from multiple applications running at scale which need to share a limited amount of IT infrastructure resources.

    With the acquisitions of SignalFx and now Omnition, Splunk is betting that it will be able to combine IT operational analytics based on machine data generated by logs with an APM platform to correlate application performance against infrastructure events. It’s not clear how long it will be before Splunk can fully realize that vision. In the meantime, the rate at which application and infrastructure management platforms will converge will only accelerate as developers are held more accountable for applications long after they are deployed in a production environment.

    — Mike Vizard

  • Splunk to Acquire SignalFx to Gain APM Platform

    Splunk to Acquire SignalFx to Gain APM Platform

    Splunk today announced it will acquire SignalFx as part of an effort to extend its reach beyond IT operational analytics and into the realm of application performance management (APM).

    Valued at approximately $1.05 billion, the deal to acquire an APM platform delivered as a software-as-a-service (SaaS) offering will expand and accelerate Splunk’s overall transition to a recurring revenue model based on cloud services, said Splunk CEO Doug Merritt during a call with industry analysts.

    Splunk is currently on pace to generate over $300 million per year from the cloud version of its IT operational analytics platform. Splunk revenues for the second quarter were $517 million, up 33% year over year, with software generating $350 million of that total. However, as Splunk transitions to more of a subscription-based pricing model, the company has some financial management challenges. GAAP operating loss for the company’s second quarter was $87 million. However, non-GAAP operating income was $47 million, even though operating cash flow was negative $129 million. That cash-flow issue is a direct result of the transition away from a perpetual software license model based on the volume of data consumed by the Splunk platform. Overall, Merritt said Splunk is firing on all cylinders and is still on track to have 20,000 customers by the end of its fiscal year.

    Merritt said once the deal is approved, sometime in the second half of fiscal 2020, SignalFx will provide a complementary set of services for monitoring legacy monolithic applications as well as cloud-native applications based on containers, Kubernetes and serverless computing frameworks. There are very few customers at this point who have not adopted cloud-native technologies, but for now they remain a small percentage of the overall number of application workloads being managed, he added.

    The goal is to provide a suite of services that will enable IT teams to investigate, analyze, monitor and act on data in real-time, said Merritt.

    Splunk is already widely employed by internal IT operations teams, many of whom already rely on a complementary APM platform. Splunk clearly expects organizations will prefer to acquire an IT operational analytics platform and an APM service from the same vendor. However, competition between APM platform providers is already fierce. That said, Splunk appears to be counting on increased demand for real-time application monitoring to differentiate SignalFx from rivals.

    It’s not clear to what degree Splunk might converge the various services now being provided separately by both companies. It’s also not clear how or whether this deal will accelerate acquisitions of the remaining independent APM platform providers.

    In the meantime, Merritt said SignalFx and Splunk’s earlier acquisition of VictorOps, provider of incident management platform based on best DevOps practices, will expand the amount of visibility Splunk has with application development teams.

    Ultimately, acquisitions of smaller, DevOps-oriented companies by vendors that today are still more closely identified with legacy ITIL-based IT processes, such as Splunk, are only like to increase. What will be interesting to watch is whether the tools and services being acquired by those companies wind up being the DevOps tail that wags the proverbial ITIL dog.

    — Mike Vizard

  • IBM Closes $34B Red Hat Acquisition

    IBM Closes $34B Red Hat Acquisition

    Following the official closing of IBM’s $34 billion acquisition of Red Hat today, leaders from both companies reiterated Red Hat will continue to operate independently of IBM but will leverage IBM resources to advance the hybrid cloud computing ambitions of the newly combined entity.

    Arvind Krishna, senior vice president for cloud and cognitive software at IBM, said IBM and Red Hat together will be in a better position to address what he described as Chapter Two of a continuing cloud journey. With 80% of applications still running in on-premises IT environments some 10 years after the arrival of public clouds, it’s apparent hybrid cloud computing will become the dominant form of IT, he said.

    Red Hat will play a critical role in helping customers achieve that goal using a common operating model based on distributions of Linux and Kubernetes container orchestration software, Krishna said. However, he added, IBM sees no need to rationalize its current middleware software portfolio, which often addresses use cases that Red Hat doesn’t.

    Paul Cormier, executive vice president and president for products and technologies for Red Hat, said Red Hat will continue to invest in products and projects independently of IBM. As such, Red Hat does not expect its relationship with its partners that compete directly with IBM to change substantially, he said. At the same time, he stressed that working more closely with IBM will accelerate a 100% open source approach to hybrid cloud computing that otherwise would have taken Red Hat “many years” to execute on its own. That hybrid cloud computing strategy, in contrast to rivals, will span virtual machines, bare-metal servers and public clouds, Cormier said.

    Other than introducing Red Hat to a potentially larger customer base, it’s not quite clear how being a unit of IBM accelerates the Red Hat strategy. Red Hat and IBM sales teams, for example, will have no incentives to cross-sell offerings and Red Hat will continue to promote its brand independently of IBM, in much the same way VMware operates independently of the rest of Dell Technologies. Both Red Hat and IBM also stressed there is no plan to impose an IBM culture on Red Hat or lay off any personnel. There is a consensus that open source software will play a role in enabling hybrid cloud computing that should generate opportunities for IBM to generate more professional services revenue.

    Longer-term, there’s clearly an opportunity for both Red Hat and IBM to promote the adoption of a common set of best DevOps practices across a hybrid cloud computing environment. Many organizations, however, are already moving to extend those best practices across all the platforms that make up very diverse IT environments.

    For now at least, organizations that have already committed to Red Hat appear to be lending their continued support. Red Hat’s fiscal year 2019 revenue was $3.4 billion, up 15% year over year. Fiscal first-quarter 2020 revenue was $934 million, up 15% year over year. Services revenue for Red Hat also grew 17%. Precisely how IBM and Red Hat intend to unlock the value of this merger beyond the momentum Red Hat already enjoys, however, remains a bit of a mystery.

    — Mike Vizard

  • CloudBees’ Acquisition of Rollout: The CEOs’ View

    CloudBees’ Acquisition of Rollout: The CEOs’ View

    As Mike Vizard reported yesterday, CloudBees, as part of its mission to build “the world’s first end-to-end automated software delivery system,” announced another acquisition: Rollout, a developer of a feature flag application that allows for simplified testing of new modules within an application.

    Not to repeat the gist of Vizard’s article; you can read it for yourself. But this continues what has become something of an acquisition tear by CloudBees. The company has acquired CodeShip and Electric Cloud, among others, while becoming one of the founding members of the new Continuous Delivery Foundation (CDF), under the Linux Foundation and a sister foundation to the Cloud Native Computing Foundation (CNCF) and the Cloud Foundry Foundation. The CDF is now managing the Jenkins project, as well as Jenkins X, Spinnaker and Tekton.

    CloudBees’ Mission

    Make no mistake: These acquisitions, along with the CDF formation, represent a major change for CloudBees. The team there is clearly trying to separate from the pack of “end-to-end” DevOps contenders. CloudBees CEO Sacha Labourey is pushing hard to raise CloudBees above the noise and the rest of the market. The company announced a $62 million round of financing about a year ago.

    You don’t have to be Warren Buffet to see that CloudBees sees an opportunity here. The company is driving toward achieving scale in product and revenue on the path to some sort of liquidity event (perhaps an IPO?) or market leading opportunity.

    For now, though, back to the Rollout acquisition. I had the chance to sit down with Labourey and the CEO and founder of Rollout, Erez Rusovsky. We discussed what Rollout does, its history and how it will fit into the CloudBees product portfolio.

    It is always great to interview a founder about his company being acquired. What a tremendous feeling of accomplishment to found and build a company, and have another entity value it so much that you are willing to sell it to them. This goes so far beyond validation.

    Congrats to Erez and the whole Rollout team and, of course, congratulations to Sacha, KK and the rest of the CloudBees team. This seems like a perfect fit.

    In the meantime, here is my conversation with Sacha and Erez on the acquisition and more. Enjoy!

     

    — Alan Shimel

  • CloudBees Acquires Rollout for Feature Flagging

    CloudBees Acquires Rollout for Feature Flagging

    CloudBees today announced it would extend the reach of the Jenkins continuous integration/continuous development (CI/CD) platform by acquiring Rollout, a provider of feature flag tool that gets employed to simplify testing of new modules within an application.

    Company CEO Sacha Labourey said the acquisition of Rollout would result in a feature flag capability that is more seamlessly integrated with the gates that make up a CI/CD pipeline process. The goal is to make it easier for DevOps teams to apply A/B testing of new application features against a subset of users before deciding to update an entire application environment, he said.

    Feature flagging, also known as feature toggling, enables DevOps teams to hide features from certain users at runtime. In effect, this creates multiple branches from the same source code that DevOps teams need to manage. Rather than having to employ a separate tool based on an entirely different user interface, CloudBees is moving to make feature flagging a core capability of its extended toolchain.

    In theory, feature flagging should be more widely employed than it is today. Many organizations, however, have found it challenging to incorporate separate feature flagging tools within their DevOps processes. CloudBees is now using some of the money it has raised of late to address that issue.

    Feature flagging today is largely confined to testing. However, there may come a day when more organizations will employ feature flagging to make different classes of user experience available to different end users. That approach, in theory, would make it possible to charge different fees for disparate application experiences using the same core application.

    In the meantime, the goal is to garner more feedback concerning new capabilities that might be added to an application before the features are made generally available. Developers often spend months developing new features only to discover end users are not employing those capabilities because of some trivial glitch that could have been discovered easily using A/B testing.

    There currently is no shortage of options when it comes to tools for implementing feature flagging. Labourey said CloudBees elected to acquire Rollout because the team behind it was deemed to have the best cultural fit with CloudBees. It’s too early to say whether other providers of feature flagging tools will be rolled up into other CI/CD platforms—providers of those platforms can either develop their own feature flagging toolsets or move to absorb a third-party provider either by acquiring them or forming a technology alliance. The depth of the toolchain being provided these days often has as much to do with what CI/CD platform ultimately gets adopted as the core integration and delivery capabilities.

    Regardless of the path chosen, it’s apparent that thanks to feature flagging, continuous testing processes will become more sophisticated. That may require some adjustments to existing best DevOps practices, but the days when development teams blindly experiment on end users in the hopes they are building the next killer feature mercifully are coming to an end.

    — Mike Vizard

  • CloudBees Increases Size of DevOps War Chest

    CloudBees Increases Size of DevOps War Chest

    CloudBees has increased the pool of dollars it is aggregated to drive further consolidation across the DevOps sector by $10 million, thanks to an investment from HSBC. The investment comes on the heels of $62 million in funding that CloudBees raised last year, which brings the total amount invested in the company since 2010 to now more than $120 million.

    CloudBees CEO Sacha Labourey said that funding announced this week will be used for, among other things, adding more products and services to the CloudBees portfolio via acquisition. CloudBees last month revealed it acquired Electric Cloud, a provider of a continuous delivery platform for both monolithic and microservices-based applications.

    Labourey said the HSBC investment represents of vote of confidence on two levels: Banks tend to be more conservative when it comes to investing in IT companies, and HSBC has already adopted CloudBees’ open source Jenkins continuous integration/continuous delivery (CI/CD) platform.

    Citing industry analysts’ estimates, CloudBees says the DevOps sector is currently valued at $4.61 billion. Within that sector, CloudBees estimate there are more than 15 million developers using some instance of Jenkins to automate their software delivery pipelines and 46 of Fortune 100 enterprises—including three of the Fortune 10—rely on the CloudBees Suite to implement Jenkins.

    While CloudBees clearly is a dominant provider of DevOps tools and platforms, the category is starting to draw attention from financially well-heeled vendors such as VMware. The virtualization platform arm of Dell Technologies earlier this month announced it will acquire Bitnami, a provider of tools for packaging applications that has gained a following among DevOps proponents.

    That wave of acquisitions coincides with a major shift from monolithic to microservices-based application development. CloudBees launched Jenkins X to provide a CI/CD platform optimized specifically for microservices. But just because CloudBees and Jenkins were able to dominate the first DevOps wave, it doesn’t necessarily follow that Jenkins X will be widely adopted as a de facto standard for building microservices applications. Competition to provide the CI/CD platform for next-generation cloud-native applications based on microservices is already considerable.

    In the meantime, traditional enterprise IT organizations will continue to monitor with interest merger and acquisition activity across the DevOps sector. Enterprise IT organizations tend to be wary of standardizing on development tools and platforms when there’s a chance the provider of that tool might be acquired by another vendor or entity they’d rather not work with. On the plus side, all the money being invested in DevOps startups is one of the primary reasons why DevOps is one of the most vibrant category in all of IT.

    It remains to be seen which company or tool will come out on top. But the contest will be fierce. The ultimate beneficiary of that competition is almost always the end customer—assuming, of course, they bet on the right DevOps horses in the first place.

    — Mike Vizard

  • Sauce Labs Acquires Screener Visual Testing Tool

    Sauce Labs Acquires Screener Visual Testing Tool

    At the SauceCon 2019 conference, Sauce Labs today revealed it has acquired Screener to add a visual testing tool to its portfolio of automated testing tools.

    Lubos Parobek, vice president of product for Sauce Labs, said the addition of Screener will make it possible for DevOps teams to not only test functions and performance using existing Sauce Labs tools, but also now confirm things such as the colors of a visual element of an application are being rendered correctly, for example.

    In addition to building their own visual tests, DevOps teams can employ Screener to automate the running on those tests and store baselines in the cloud to create a visual testing life cycle.

    At the same time, Sauce Labs announced the general availability of Sauce Headless, which leverages container technologies to make it possible to leverage a cloud service through which developers can now run tests via a Chrome or Firefox browser every time they commit code. Parobek said the goal is to make it easier for organizations to embrace continuous testing as an extension of the pipelines constructed using a continuous integration/continuous deployment (CI/CD) platform.

    The acquisition of Screener, he said, is part of an ongoing Sauce Labs effort to extend the reach of its testing portfolio beyond functional testing. Sauce Labs earlier this month launched Sauce Performance, its first set of application performance testing tools.

    The rise of DevOps is challenging traditional approaches to application testing as organizations move to combine various types of testing into a single continuous process. To meet that requirement, Sauce Labs is expanding its portfolio of automated testing tools at a time when the emergence of microservices-based applications is significantly increasing the level of dependency between all the components that make up an application. That increased level of dependency will require DevOps teams to rely more on automated testing tools. In fact, Parobek said the day is not far off when DevOps teams will include digital assistants that leverage machine learning algorithms to enable DevOps teams to continuously run those tests at the right moment in an extended DevOps pipeline. Those digital assistants will not replace the need for human testers anytime soon, but they will augment their capabilities to make is feasible to implement continuous testing at scale, he noted.

    In the meantime, as application testing continues to shift further left in the DevOps process, more developers will be building and running their own tests during earlier stages of the application development process. At some point, either another developer or dedicated tester still will need to evaluate that code to provide an unbiased opinion. But the number of common mistakes making it into the latter stages of the application development process should be substantially reduced. Ultimately, that shift to the left should result not only in more development projects meeting deadlines, but just as significantly higher levels of overall application quality. The challenge now, of course, is figuring out how to implement a best DevOps practice that pushes application testing as far to the left as possible.

    — Mike Vizard