Introducing Akka Cloud to Edge Continuum. Build once for the Cloud. Seamlessly deploy to the Edge - Read Blog
Support
interview opsclarity acquisition

Lightbend Acquires OpsClarity: Interview with CEO Mark Brewer (14 min)

What This Acquistion Means For Reactive Systems

Right on the tail of our recent big announcement of Lightbend's acquisition of OpsClarity, I took the opportunity to sit down with Mark Brewer, CEO and President of Lightbend, to discuss how this joining of forces now provides our customers with a full platform that meets the requirements of enterprise's designing, deploying, and managing Reactive systems. 

 

Follow Along With The Transcript

Oliver White: [Intro truncated] Mark, thanks so much for joining me today. I hope you're well.

Mark Brewer: Thanks, Oliver. Yeah, very well actually. Thank you for asking.

Oliver White: Excellent. Let's get started. So, Mark, in the last 12 months, Lightbend has acquired two companies -- BoldRadius and now OpsClarity. Can you share a little bit of the history of our growth at Lightbend and the vision of the future for us?

Mark Brewer: Sure. Lightbend has been growing organically for the last five years that we've been around. But there's also been opportunities to accelerate that growth a couple of times through acquisitions. I see these both as natural progressions in not just the natural growth of the company, but more importantly it's the best way to deliver what our customers need to be successful–our enterprise customers who are taking on this journey of building Reactive systems.

So BoldRadius, who we acquired in the middle of last year, was about bringing capacity inside the company to deliver services–specifically training and higher-level mentoring services to our customers and help them be successful with their projects and make sure that we had the capacity to train and enable our very large and growing partner organization and ecosystem. So that was a natural acquisition, because the company was dedicated solely to the Reactive Platform and Lightbend technologies.

This most recent acquisition fulfills another objective that the enterprises who adopt our technologies are in need of, and that is to help them not just build and design these Reactive applications, but specifically help them manage and deal with them as they go into production.

And we'll get into more details about what OpsClarity brings, but they also happened to be a perfect fit. Because they were building their monitoring system using Lightbend technologies, they are adopting what's going on. Virtually everything that they've built leverages the technologies from Lightbend.

Oliver White: You mention being able to serve our clients and others within the trends of the industry. Can you paint us a bit of a picture of what's happening at the macro-level these days in the industry, and why enterprises are adopting Reactive systems?

Mark Brewer: Reactive obviously is a category or a way of architecting designing systems that has been defined now for a number of years since the Reactive Manifesto was published in the middle of 2013. And I'm pleased to say that we spearheaded that effort, and that virtually every developer framework tool company, every application platform company has in some way embraced Reactive.

Reactive means that systems and applications are built to be responsive. Responsive to events, and responsive to the users if there's a user interface. They're built to be elastic, meaning they need to scale up and scale down in the cloud or possibly on-prem, and scale up and scale down as demand dictates. They're also designed to be fully resilient,  so that when failures occur, they can be dealt with without having somebody actually spin up a new server or a new node.

And finally, all of this is empowered through a message-based system. Where you've got messages going between distributed components. So Reactive systems is not new. It's still early in its life cycle, I would say. But when you see enterprises start making these big decisions to build a completely new system leveraging Reactive technologies like Lightbend, it's a big endeavor.

And the macro trends are driving people to this need to become much more agile in the way you develop and deploy your business logic or your business systems. You need to be more agile in just the way you deal with the change requests that come, i.e. if some new feature needs to be delivered. This is possible through Reactive systems, and microservices is kind of the architecture to deploy those new pieces of code.

Reactive is not just hype anymore. It's actually a reality in the enterprise. We see companies like Verizon who has taken to market a brand new product, their go90 platform. So if you watch any streaming of Showtime content on your phone or on a tablet with Verizon, that's powered by something called go90. But that's powered by a system completely built in a Reactive way. And of course, leverages the Lightbend technologies.

This new platform with Verizon (read the case study) went from zero customers using it to over a hundred million in just matter of days. That wouldn't be possible to build a system like that and get it out to market if it hadn't been designed from the ground up to be fully Reactive in the way I've just described.

There's another great example of a company that's built Reactive systems, also a fairly old-school company, Norwegian Cruise Lines (read the case study). Obviously, they're a cruise ship company. They decided to change the way people experience a cruise. Both in the way they paid for their cabins and paid for the different endeavors or adventures they went on on those cruises. They call it freestyle cruising. But the concept is pretty straightforward.

As a potential customer that was going to take a cruise, you have the ability to pick and choose all the services you want. And tailor it to yourself and family or whoever is traveling with you, and not be locked into just buying a package, which is the old way of doing it. And they've extended that to not just when you buy your cruise tickets, but actually while you're on the cruise itself.

It's much more flexible in your ability to change your plans. Maybe you've decided you don't want to go on a kayaking cruise, but instead you'd like to go snorkeling or something. And you can share that information with others as you experience it. So they might take your feedback and say this is something I'm interested in promoting because somebody said this was a fun little kayaking trip or snorkeling trip.

So the whole concept of this cruise system from top to bottom has been rebuilt and designed to not only be fully Reactive and resilient, but actually enable changes and new features to be added very simply or very easily. There are great stories published on our website about Norwegian Cruise Lines and Verizon. I encourage you to take a look at them, because they go into much more detail than I just did.

But these are examples of enterprise customers who've made a big decision to shift the way they design and build applications. To not just do it in a new way, but actually deliver much more value to their customers and ultimately, more profits to the business.

Oliver White: In looking at these case studies, it's very clear that agility is at the forefront of their intentions. And the ability to react to things in more or less real time, or near real time, that comes down to having insights available to you. And yet, the existing application monitoring platform tooling out there can't exactly be used for these Reactive distributed systems that are across all sorts of different nodes, running multiple microservices, perhaps using fast data pipelines to do real time analysis. So what are some common challenges facing enterprises these days that are looking to go Reactive, but they need to be able to see what's going on inside of, more or less, a big black box?

Mark Brewer: I think it would be helpful to just go back and look at the history of monitoring technologies and what they were built to solve for. Historically, back in the '90s and early 2000s, it was about infrastructure, right? About the machines themselves, and then maybe the operating systems and job application servers above it. But it was all about just the monolithic deployed servers, physical servers. And then later, of course, virtual servers.

But it didn't do two things. It didn't help developers design more efficient and effective systems because it was really at the infrastructure level. And honestly, it was controlled and operated by the operations folks, not by the developers or DevOps folks. So then we say the advent of companies or technologies from AppDynamics, and New Relic, and a number of others that solved for that.

They brought to developers a set of monitoring tools that let them instrument the code so they could get deep insight into how the application business logic was performing. And of course, if there were any kind of errors that occurred, they could quickly identify where it broke down, where things failed. It's still a monolithic kind of old -- well, call it heritage -- systems that allowed for application logic to all be in one place. One very large app server, generally, running that code. Possibly written in Java or something else.

And the instrumentation that was done by the developer and the visualization that you got through a tool like New Relic or AppDynamics gave you good insight into how your applications are performing. Of course, as you're building them, you got that same insight.

The problem is that this new Reactive world is very distributed, literally where you could have thousands of separate nodes or separate microservices that do one function really well. It's hard to tie them or put them all into one system.

That is true across the network, across the Cloud. And the visualization or the insight you need is not just about how's the code running, it's about how are these messages going from microservice to microservice. Are there any bottlenecks? Are there any network issues that could be causing a problem? Is there a connection to a database, some legacy data store that might be causing a bottleneck and creating these failures in the system? Or failure to be responsive in the system?

So it's requiring a new class or a new breed of monitoring tools. Monitoring tools that they, themselves are Reactive. And they can take -- not just take advantage of being deployed in a cloud as a service like OpsClarity is, but also have the ability to see across all of these disparate components that are being used. And I should have mentioned that before. In this new world, you get to choose your framework. You get to choose what kind of different infrastructure technologies you want that come from many different places.

So that Verizon story I told earlier, they used things like Spark and Kafka. Of course, using Akka and Play, the Scala language and a whole bunch of other technologies -- i.e. Mesos -- or DCOS from the Mesosphere team, to operate it. So that means I don't have one single piece of software that I'm monitoring. I literally have dozens of different pieces of software. And as you said, they're distributed widely. So you've got to also keep track of those messages going across the network and the individual components.

OpsClarity brings to market something that I would call the next generation, or the Reactive generation, of applications, and this is a monitoring tool that gives you insight into all of that.

We've been working closely with them for some time. It was just a natural progression of our business to bring them in-house so that we could then bring to market a full stack, if you will. A full stack of not just the developed tools and frameworks and the deployment and runtime components, but actually a monitoring solution that will let you get that insight we just talked about.

Oliver White: Indeed. Final question. OpsClarity is a relatively new player in the monitoring space and this acquisition is obviously going to bring some tremendous benefits to people using Lightbend technologies in production and development. Are you able to share some of the specific benefits that our users can expect?

Mark Brewer: Yeah. Right off the bat, all of our customers, all of our subscribers are going to have access to OpsClarity as their monitoring tool. And OpsClarity and Lightbend have been working together as I mentioned to not just assure that these technologies work well together, but actually give you deep insight into actors inside of Akka. So the mailboxes and the streams of data that's going between different actors where you can actually see how it's performing and see where there might be bottlenecks.

All our customers will have access to OpsClarity immediately. The objective here is simply to give them more visibility, and give them a better sense on how their applications can be improved if there are areas where they can be improved. We also believe that OpsClarity is going to be the basis for which all of our management tools will be presented to the customer in a user interface.

So if you're familiar with OpsClarity, they've got a very rich UI. A very compelling flow through the system, and how you look at reports, and how you dive into the components of your application. And we see that as being the foundation for our orchestration tools. The ability to deploy and manage your applications and the clusters that are being deployed to run them. And there will be other opportunities to leverage this technology. Right now, we're just excited about being able to bring on board a full monitoring solution and see where it goes from there.

Oliver White: Mark, thank you so much for taking the time to speak with us today. These are really exciting days at Lightbend. For more information, please visit us at Lightbend.com. Where you can find resources and also request to be contacted by a Lightbend representative for a brief 20-minute introductory conversation. Again, Mark, thanks a lot. Have a wonderful day and talk to you soon.

Mark Brewer: Thanks, Oliver. Have a great day.

READ MORE CASE STUDIES

 

The Total Economic Impact™
Of Lightbend Akka

  • 139% ROI
  • 50% to 75% faster time-to-market
  • 20x increase in developer throughput
  • <6 months Akka pays for itself