This DevOps Chat features “the CEO’s view” as seen by XebiaLabs CEO, Derek Langone. Derek is one of my personal favorite CEOs in the DevOps space because he is very articulate, to the point and sharp. I think all of these characteristics come through in this DevOps Chat. As CEO of XebiaLabs, Derek is leading one of the leading companies helping transformations in enterprise DevOps. In this chat, Derek talks about with us about cloud and cloud migration.

As usual, the streaming media of our conversation is below. The transcript of our conversation follows below that.

 Audio

Transcript

Alan Shimel: Hey, everyone, this is Alan Shimel, staging-devopsy.kinsta.cloud, and you’re listening to another DevOps chat.  Happy to be joined today on DevOps chat by Derek Langone, CEO of Xebia Labs.  Hey Derek, how are you

Derek Langone: Alan, I’m excellent, thanks very much for having me today.

Shimel: Thank you. Just a heads-up to our audience, I had been working on this for a long time. Derek’s agreed to be sort of a regular guest here on DevOps Chat and we’re looking forward to hearing from him, oh, maybe once a month or so on topics that are of interest to hopefully our whole audience so you know they’ll be around DevOps and related to technologies.

So, this is the first one we’re doing and we were going to talk today a little bit about cloud and whether you already are a cloud customer or new to the cloud, how can DevOps and related technologies help you.

But before we do, Derek, in case there’s anyone out there who maybe is not familiar with Xebia Labs, you want to give them a real quick kind of pitch on Xebia Labs and what you guys are doing?

Langone: Sure, here’s the 30-second commercial. So, Xebia Labs is entirely focused on enterprise DevOps. We provide a software platform for large enterprises that encompasses three primary components, released orchestration so basically create your pipelines in our technology that are templated, repeatable, standardized, use our automated deployment engine which is a model-based agentless engine.

And then lastly, we have a machine-learning and AI-oriented reporting engine that collects all the data associated with your journey from development to production. It allows you to report on that for things like compliance purposes, regulatory purposes, security, and just a good old-fashioned scorecard – am I going faster? Is my quality up? Are my customers happier?

Shimel: Couldn’t have asked for more than that in 30 seconds, Derek, thanks. So, here’s the deal, we are approaching I think this year a threshold in cloud adoption where it’s something like 50 percent of enterprises will have significant infrastructure in the cloud, not just a toe in the water or an R&D project, but significant infrastructure in the cloud.
And that’s big, right?That means half of all enterprises have a large investment in cloud. But it also means half, don’t, right? And that’s always the flip side of the coin. I want to talk today to both of these audiences but let’s first start with the half that already has, right?

They’ve invested a lot time, a lot of money, probably a lot software or tools and personnel, but maybe they’re not getting everything they need out of their cloud deployment? How can DevOps help?

Langone: Well, DevOps by principle is sort of an accelerate opportunity, right? And if you look at a cloud investment, it’s a similar value proposition that you don’t have the requirement to manage this infrastructure, you’ve got less administrative overhead, you’ve just got on-demand, scalable infrastructure. So, that’s all oriented around speed.

The challenges we see with our customers that are generally large enterprises, the biggest banks, insurance companies, airlines, in the world represent our customer base. They’re moving aggressively to the cloud because it’s just generally less expensive and certainly much less administrative overhead.

But the consequences, the applications they’re trying to get there are very complex and don’t necessarily lend themselves to moving to the cloud very neatly. And what I mean by that is if you use an example like a large bank might have a money transfer application, core to every business that’s a big financial institution.

That application lives in many places; the back-end horsepower may be a mainframe, there’s referential databases that do some validation every time there’s a query. You’ve got distributed architecture, maybe a containerized front end that gives you your mobile banking access and things like that.

Moving all of that to the cloud is not simple, it really requires an incredible amount of orchestration, some very sophisticated deployment functionality. And we see most of our customers when we get engaged, them trying to do that with either the simple tools that come with the cloud platform providers, you know, the out-of-the-box Amazon or Azure tool portfolio.

Or in most cases, just using the good old- fashioned, using extremely talented valuable developers to write tons of scripts to try to move these components around and shift them to the cloud. Neither of those initiatives are generally successful.

Shimel: And I think you just hit it, Derek. Those are the two ends of the dumbbell if you will, right? One is to use the vanilla tools that the cloud providers give you and not to bang anyone but AWS is notorious for this, right?

They give you 60 percent of the functionality at a really low, low price of some of the best __ tools but it comes bundled. Or you go the other way, right, just totally customize the heck out of things, which is not scalable usually, nor repeatable.

Langone: No, it’s not, that’s the challenge. And just to hit those two ends of the dumb-bell as you said, the tools that come with the cloud providers, I mean, look, they’re sort of minimalistic by nature because it’s not the core business that they’re trying to provide. They’re infrastructure providers, they’re really not deployment technologists, right?

So they’re gonna give you a little bit to get some basic applications there but anything complex is really gonna fall down. And like you said, the other side of it is, and the more traditional approach, is just using your engineering assets to write a ton of scripts to provision infrastructure, to migrate applications, to request instances.

You know, it’s just an incredible amount of plumbing code that gets written that is super low-value and basically comes at the expense of much higher value activities that those engineers could be participating in, things like building new features and fixing bugs and just basically delivering more customer value.

Shimel: And with that approach, Derek, to me it’s always been, well, what happens next month when I have to do this again? I’m gonna rewrite all the scripts, waste all that time? It just doesn’t make sense. But you hit on this with your opening, the reality is that most of these organizations who may already have significant infrastructure in the cloud are not totally in the public cloud certainly.

They still do have mainframes, they have stuff in the closet, they have stuff in the data center. They’re living in a hybrid world, right, Derek? And so for whatever reason, and I’ve heard this from numerous, they hate the idea of using one tool for their public cloud stuff, one tool for their on-print stuff, one tool for their private cloud. They want one throat to choke, right? They want one tool.

Langone: Well, I think they want one platform that can kind of account for the migration and IT landscape that they are going through, right?

Shimel: Yes.

Derek Langone:And that’s sort of what we’ve tried to build at Xebia Labs. We work with the legacy infrastructure and give you velocity, repeatability, standardization for your mainframe deployments in the exact same way that we will accelerate your journey to containers and leveraging Kubernetes and Docker as well as, you know, getting onto what is generally hybrid cloud infrastructure.

We definitely see large organizations leveraging things like Amazon but in most cases, they’ve got some combination of a data-center cloud that they’ve got under their own control, as well as the sort of less mission-critical applications or the things that don’t represent the family jewels if you will in true public cloud infrastructure.

And when I talked to CIOs in these organizations about their aggressive shift to the cloud, they look at me and say, look, we’re moving to the cloud with a lot of new development and some of the less mission-critical applications but the five apps that we run the bank on are gonna be running on mainframes five years from now.

That’s not changing. We can’t break them up into micro-services and they don’t lend themselves to refactoring. We’re gonna continue to just add, you know, additional workload front ends but for the most part, they’re gonna stay intact. And that just represents I think the reality in enterprises.

Shimel: And that is dead on the reality. And I just want to make sure we’re talking about tools like Xebia actually give these organizations the ability to use one platform across these multiple infrastructures.

Langone: Yeah, I mean, look, I don’t want to just plug our platform because there’s others out there, there’s others out there, but at the end of the day, yes, what we’ve tried to do is basically build the technology that can accommodate the mission-critical requirements of a large enterprise. So, not only have we baked in the ability to deploy any technology from any starting point to any destination including public cloud, private cloud, hybrid, containers, you name it, right?

We’ve also baked in all of the things that enterprises need to account for, like the compliance steps, the security steps, the who did what and when to the software reporting, so that all of these standards are met if you’re migrating to infrastructure that’s off of your own premises.

None of those business requirements go away. In fact, in most cases, they get a little bit more stringent as the security team start to understand that if you’re gonna move applications outside of the firewall of the organization, then we need to put even more validation steps and security procedures in place.

And again, if you’re doing this manually with engineers, they need to script for all of that activity and maintain it every time there’s a slight change in the application.

It just becomes 50 percent of an engineer’s day managing these scripts that were built to move applications around when they could be using that 50 percent of their day to do things that are much, much more interesting for them and much more valuable to the organization.

Shimel: Sure, I mean, and again, we’re not tooting Xebia’s horn here but you know what, Derek, from a manager-executive point of view maybe listening to this, knowing that there are tools like that that will allow them to go across these different infrastructures, single platform, is important. I mean, that was always one of the big inhibitors.

Langone: No, you’re absolutely right, and look, what we’re tried to build into our platform is this templated approach. We have a model-based architecture, it’s agentless so you create templates and every single application that you have to move from development to production follows one of maybe three or four templates.

And we’re talking 3 to 4 templates account for 500 different applications, whereas the alternative is you’re basically hand-scripting 500 different paths to production. So it’s much easier to maintain, it’s centralized, it’s controlled, there’s reporting, there’s visibility, there’s sort of all the things that you need to be able to score your process for migrating applications, whether it be to the cloud, the containers, or just frankly, to an existing data center.

So, that’s really an important consideration. The other piece to consider, and again, a place where we’ve put a lot focus in our platform is leveraging what you’re doing already. So, we are a part of the process but you’ve got provisioning tools, like Puppet and Chef, you’ve got service ticketing, like Service Now or Gira, Jenkins on the CI side.

A lot of technologies are required to move applications from one destination to the next, so we integrate with all that infrastructure that’s already running right out of the box, and we basically allow you to pick best-of-breed components so that you’re not locked into one specific vendor. And that’s been a lot of the feedback that we get from our particularly big financial services customers.

They like the fact that if they want to switch cloud providers on the fly and move from Amazon to Rat Space or from Rat Space to Azure, they can do that with changing one configuration file in our product rather than having to rescript everything from scratch to reach a new destination.

So, it really comes down to you avoid vendor lock-in, but when you want to make a pivot, that pivot in our technology and our platform takes five minutes versus months of scripting. 

Shimel: Months, exactly. So, Derek, let’s make our own pivot, let’s talk about the other 50 percent of companies that aren’t moving major infrastructure to the cloud, or big parts of their infrastructure to the cloud. Let’s first of all say should they? Should they feel they’re getting left behind? Is it fatal to their business? What’s your feeling?

Langone: You know, I think every IT organization makes choices that line up to the business objectives of their firm. I wouldn’t say that the shift to cloud is mandatory. There’s certainly a strong value proposition associated with it. It’s very, very expensive to keep technology infrastructure fresh. That’s always been the issue.

You could build the data center but then, you know, 18 months later, all the technology in there is sort of out of rev, right? So you’re forced to buy it over and over and over again versus the cloud providers. You’re certainly paying the rental fee and that rental fee can be steep but you’ve always got state-of-the-art infrastructure to work against, and that’s just a very compelling argument.

The other pieces, the administrative element goes away so there’s less people required to maintain it because it’s getting maintained for you. But the majority of our customers are moving to the cloud but for specific reasons and with specific applications, right? They’re not just wholesale-lifting their entire application portfolio to the cloud because it’s just not practical.

So in the cases of customers that are still on premise, and that’s still the majority of large enterprises, I am not at all a cloud-denier. People are moving there and moving there aggressively, but when you look at large enterprises, I think your number was 50 percent are using and 50 percent are not.

My on the ground sort of feeling is it’s less than 50 percent that are aggressively using the cloud for many different reasons, not the least of which are just security concern that still sort of haunt these large organizations. But the fact is anywhere your applications reside, right now DevOps is a good investment.

Being able to increase the velocity at which you can build technology and deliver value through software to your end users is sort of a fundamental requirement nowadays in order to stay competitive in your own given space.

So, we help with velocity, like I said earlier, on mainframes distributed technology, legacy systems, building a repeatable standardized release and deployment process with all the reporting that you’d expect to be able to identify where you’ve got areas of friction that can be remedied.

So, we sort of approach with the same – our approach is the exact same whether it’s a legacy application or a nimble application that’s being written in containers to run in cloud infrastructure.
The templates are the same, the mechanics of how you release and deploy those applications is the exact same.

So, the beauty of our platform becomes anybody can use it, it’s understood, it’s centrally managed and it scales infinitely versus writing code which just is difficult and impossible to maintain over time. 

Shimel: Sure. So, Derek, you brought an interesting point up though and it was one that I wanted to hit on. And that is, look, for those who are just moving to cloud, right, there’s a choice to be made. Do I take my inherited legacy, not so much infrastructure as much as my legacy stack and just port this existing stuff to the cloud?

Or do I really just bite the bullet in Greenfield, right? Like, my stuff hasn’t been built on containers, maybe it wasn’t even built on hypervisors and virtualizations – who knows? But you know what, if I’m gonna move to the cloud, the heck with it, I might as well containerize and take advantage of micro-services and all of this.

But my goodness, that’s such a major, you know, throwing out babies with bathwater potential. What’s your advice to companies faced with do I just port my existing architecture, or do I go for broke in more ways than one and adopt the new stuff?

Langone: Yeah, I’ll tell you, in my experience, and I wouldn’t want to give advice ’cause every company sort of has to line up against their business objectives. But what I will tell you, what we see most often is people threading the needle, right? Basically taking these monolithic applications and starting to build components of those applications in containers on sort of more nimble infrastructure.

You know, a good example, as I mentioned earlier, a money transfer app, right? That’s a legacy application that’s been running in a big bank for 25 years. The horsepower on the back end that does all the computations is still a couple of IBM mainframes strung together. But you’ve got referential databases that are living in distributed architecture maybe onsite, maybe offsite in the cloud somewhere.

You’ve got containerized and mobile-centric front ends so you could do your mobile banking, web banking, things like that. So, that application lives in a lot of different places and you can, with some small investment in more nimble development platforms and infrastructure on the front end, really energize and give life to these legacy applications.

So, there isn’t a need to move the entire thing to the cloud. You can move components of it to the cloud, but again, when you do that, you get the benefit of the faster architecture and the ability to deliver value through your software more frequently for your end users.

But the consequences, getting those components to the cloud becomes really complex and that’s where our technology really lends a hand, where we understand those complexities, we’ve accounted for them already.

We do this sort of every day for the biggest banks in the world so you can take advantage of not having to reinvent the wheel and still get the benefit of the velocity that you’re looking for and the flexibility you’re looking for in these applications that need to live on.

Shimel: You know what, Derek, that was one of the best examples of hybrid cloud that I’ve heard. I think for too many people they think of hybrid cloud, they say, well, this application lives in the cloud, this application lives on my mainframe, this application lives in a data-center, my payroll system is here, my HR system is there, but that’s not really hybrid cloud.

Hybrid cloud is we have one application that different elements and components of it live in this hybrid world, right?

Langone: Yes, I think there’s a misunderstanding that you’re either in the cloud or you’re not, right? The fact is, I think, that in most cases, most of our clients, you’ve sort of got one leg in both places.

Shimel: Yeah, at the same time.

Langone: You’ve got I’m somewhat in the cloud, and they make decisions relative to where can I get the biggest bang for my buck? Some of this application needs to be in the cloud for a bunch of reasons so let’s do it, and then we’re just not gonna forklift up our mainframe apps and dump them on AWS. It’s a cost-ineffective strategy; we’d have to refactor them like crazy.

So, yeah, and I don’t think that trend is gonna change, right? There’s certainly a bunch of Greenfield development that’s going on, containerized apps micro-services, just cloud-centric development. And that’s great but that represents generally less than ten percent of the application portfolio in a large organization.

And that’s the fact is that 90 percent of the apps have been around for five years or longer, and those apps are critical to the business.
And they, over time, will migrate to the cloud and be refactored and rewritten.

But it’s just too big of an endeavor for any large company to take a 1000-application portfolio and say, hey, this year we’re going to rewrite all these for the cloud. I mean, I don’t know anybody that’s doing that.

Shimel: I would hope not. Hey, Derek, I think I told you before we started, time goes really quick here. We’re at maybe 25 minutes now, we were supposed to be 15, so we could probably talk about this all day, but we’ll continue the conversation on our next visit with you.

But, hey, this was great, Derek Langone, CEO, Xebia Labs. Thanks for being our guest on DevOps Chat today and we hope to have you back real soon here.

Langone: Thanks, Alan, talk to you soon.

Shimel: All right, this is Alan Shimel for staging-devopsy.kinsta.cloud, we’ll see you soon on another DevOps Chat.

— Alan Shimel