Landing Page Clusters Graphic

ON-DEMAND VIDEO

Why Application Modernization is Now a Top Priority for CIOs

Featuring Ashmeet Sidana, Chief Engineer and Founder of Engineering Capital

In this conversation, Ashmeet Sidana (Chief Engineer and Founder of Engineering Capital) and Oliver White (Director of Communities at vFunction) discuss how the team at Engineering Capital continue to identify big winners when investing in engineering-driven startups, and why he believes so strongly in the power of vFunction for Application Modernization for aging monolithic systems–which has skyrocketed from a nice-to-have to a major priority for global CIOs in the last year.

Scroll down to see the conversation transcript, and if you like what you hear you can request a vFunction demo for your team!


why app modernization projects fail

Research Report: Why App Modernization Projects Fail

intesa sanpaolo bank case study

Italy’s Largest Bank Transforms Mission Critical Monoliths into Microservices

intellyx ebook

Analyst eBook: Application Modernization Patterns & Anti-Patterns


Video Transcript

Editor’s note: the transcription below has been edited for clarity and readability.

Oliver White (OW): Good day everyone, and welcome to this vFunction podcast. My name is Oliver White, Director of Communities at vFunction, and joining me today is Ashmeet Sidana, chief engineer and founder of Engineering Capital. Today, we’re discussing how Ashmeet and his team continued continue to identify big winners when investing in engineering-driven startups, and why technology leaders have been driven to suddenly focus on application modernization for aging monolithic systems, which has skyrocketed from a nice-to-have to a major priority for global CEOs and CIOs in the last year. Ashmeet, it’s wonderful to have you on the podcast. Thanks for joining me.

Ashmeet Sidana (AS): Thank you, Oliver. It’s a pleasure.

OW: So before we get into the meat of the conversation today, could you give us a little background? What’s a 75 word version of your speaker profile bio? 

AS: Yes, so I think of myself as an engineer. I grew up in India, I came to Stanford to study and I have lived within a couple of miles of school ever since, so I’m entirely a product of Silicon Valley. I ran a company for five years, which is where I learned how hard it is to actually start a company and run a company, arguably one of the most interesting and best jobs in Silicon Valley. 

Now I have the other best job in Silicon Valley, which is to be a venture capitalist investing in people who are trying to start companies like that. I run Engineering Capital, which is a seed stage venture capital firm, typically investing very early, often as the first investor in companies that are taking “technical risk”. This is different from “market risk”, which is what most VCs focus on, and I can get into the differences between technical risk and market risk, if that’s interesting.

OW: Yes, absolutely. I note that your job title is “chief engineer”, so it’s a little evident that you and the team at Engineering Capital do things a little differently than typical venture investment firms, so maybe you could expand on technical risk vs market risk?

AS: Yeah, the Chief Engineer title is a bit of a pun. Engineering Capital itself is a bit of a pun in the sense that I am Engineering Capital, both in the sense of working with capital and trying to make it more, but also as in I run Engineering Capital, the firm. So it’s a little bit of a pun on that. 

The difference between technical risk and market risk is that market risk is what most venture firms focus on–they see an opportunity in the market, perhaps in an existing category. Perhaps people want to buy some things where there’s a need, and they’re going to try and build a product to fulfill that. 

Technical risk is, in some ways, the opposite of that. In other words, “if only you could build this, we know people will buy it”. It’s just an unsolved problem. Nobody really knows how to solve it. 

I previously worked at VMware, and that’s a great example of a company that took technical risk and built a $50 billion company. At VMware then, nobody believed that we could virtualize the x86, and of course we did. Hence, a very large outcome. At Google, nobody believed that you could build an in-page ranking algorithm to index at scale, an infinite number of web pages. Larry and Sergey built that, and hence we have Google.

So you could build great companies doing it, and I focus on entrepreneurs and problems like that, and I have a list of problems. I always invite people, great engineers, to come in and say, “Hey, here’s a list of problems. If you think you can solve this, I think you can build a great company.” And Moti [Rafalin] (vFunction’s CEO and founder) is one of those examples.

OW: So are we talking about the difference between identifying problems versus opportunities? 

AS: It’s not the difference between them–it’s finding where they both come together. In other words, it’s not just an opportunity which anyone could solve, it’s an opportunity which could only be solved if a hard technical problem was solved. It’s a subset of all the opportunities–not a superset–that exist in the work. 

Let me give you a trivial example: if I could build a battery that could give me a 1000-mile range on an electric car and could charge in five minutes, of course, that would be an amazing battery, and of course, there’s an opportunity for that. 

The problem is nobody knows how to do it. Nobody knows how to build a battery of that type. Right? So that’s a trivial example. Or, if I could snap a finger and solve disinformation on the internet, that would be a very interesting company to build, but nobody knows how to solve it technically. 

Now, those two are not interesting to me at Engineering Capital for various reasons, but there is another set of problems which are very interesting, which exist broadly speaking in the cloud software and infrastructure space, which I think is a very lucrative and interesting space for the next decade.

OW: So how does this philosophy help you determine the qualities in very early stage startups that you look for that give you the green light? You have a very impressive list of investments that have been acquired, such as SignalFx and Tubi TV, which I’m very familiar with. So how does this philosophy determine the way that you decide to invest in a start-up? 

AS: Yeah, that’s a really good question. So one way of thinking about me is I do everything that a classic VC does. So I look for all of the same attributes. Is he a great entrepreneur, is it a big market, is it capital efficient, are the customers attractive, etc. All of the classic attributes, plus that one additional thing, which I call a technical insight. Do they have some technical view on solving a problem in a new way that no one has thought of before? 

It has to be innovative, it has to be something clever, it is something which only an engineer would appreciate. The test for it is this: if I describe the problem to you and then go grab five or 10 great engineers from Google or Cisco or VMware or Facebook or any other great company, they wouldn’t know how to do it. They’ll say, “Hmm, that’s an interesting problem. We don’t know how to solve it.” If the answer is that they don’t know how to solve it, then it’s an interesting Engineering Capital opportunity.

OW: So it’s almost a litmus test? 

AS: I would say a litmus test sort of involves a binary decision. It turns out in real life, it’s a little bit more of a continuum. These things are not just black and white. You have to think, because there’s a class of problems which are obviously interesting but also obviously impossible to solve. So that’s not interesting. 

You have to get to that messy middle ground where it’s interesting yet feasible within the venture capital life cycle, which is very short. I mean, venture capital life cycles are very tight. I don’t take R&D risk, I’m not investing in a science project, I am not DARPA, investing in a science project or underwriting a professor who wants to publish an academic paper. I am underwriting the opportunity to create a piece of software which someone is going to buy within a year or two, that’s it. That’s all the time you have to actually build it and make someone buy it.

OW: From what I understand, you were one of the first people to discuss the concept of vFunction with our CEO and co-founder Moti Rafalin. In fact, he credits you with having the original idea– helping identify that tricky problem that engineers would find value in. What was that interaction like? 

AS: I’ve known Moti for several years. I used to work at VMware, as I mentioned, he was at EMC when they actually acquired us. And so I had met him all the way back when he was just a recent grad from Harvard Business School (HBS), and I was really impressed with him and stayed in touch. 

When I knew that he was thinking of starting a new company, I went and spoke with him and said, “Would you like to work together? Here are a set of ideas which I think could be the next billion, $5 billion, $10 billion company.” And so, being a good entrepreneur, he was a little skeptical initially, but we spent some time together and I told him: 

“Look, the cloud is not going away. In fact, the cloud is a better way to build applications. The cloud is going to become the dominant architecture for IT, yet all of this investment has been in software over the last five, 10, 15, 20 years is going to get stuck in the legacy enterprise, and that is an enormous challenge, which means that it is an enormous opportunity if we could solve it with a technical solution.”

So we brainstormed on this idea and came up with this notion of refactoring, which of course is what he has built now [along with co-founders] Amir [Rapson] and Ori [Saporta], the team that came together to solve an incredibly difficult technical problem. This is true rocket science. People don’t believe that you can do it when you describe it to them, which is the hallmark of a great company, a great technology, and a company that I’m proud of at Engineering Capital.

OW: That’s a very kind sentiment. Yeah, the skepticism is very deeply rooted because I believe that the concept of application modernization has been considered as a background element that is something “nice to have”, but not necessarily part of the primary strategy or business objective for a company. 

Let’s talk a little bit about application modernization, because this is what vFunction is really all about, and using AI and automation to make that actually humanly possible. Recently, IDG reported that application modernization jumped from number eight to number three [in priority for CIOs] in just the last 12 months. All of the same monolithic systems that we’re addressing today were around five years ago, but the sudden jump seems to be surprising to some. A lot of people put it down to the effect of the COVID pandemic on digital transformation and modernization initiatives as being the primary catalyst. Do you believe that this is actually the primary reason for a highly renewed focus on application modernization for legacy monoliths, or is there something else going on and things are kind of bubbling to the top together? 

AS: I don’t believe this has anything to do with COVID, the pandemic or anything like that. To me, and I believe to Moti, it was obvious five years ago that this was going to happen. It feels sudden right now because we are climbing an exponential curve, and exponential curves always feel sudden once you get to that knee in the curve when you start going up, and we’ve now hit that knee. 

So what is this curve that we are climbing? When the entire cloud ecosystem started–let’s credit Amazon with being the innovator here with AWS–it started as a developer ecosystem for startups, for new developers building new applications in a cloud native world. And that’s really where the initial traction was, so all new applications started migrating to that new architecture. That new architecture is more efficient, it’s more scalable, it gives you more elasticity, and there’s lots of benefits that people want.

OW: The business value is quite obvious for greenfield projects, right? 

AS: Exactly. For greenfield projects, it’s obvious, and so all of that started migrating there. However, those business values also exist for legacy projects, if and only if you can refactor them for a cloud-native architecture. If you just do a lift and shift, you’re not really getting anything for your money, you’re basically paying a tax being attached to Amazon or Microsoft or Google at that point. You may as well run the data center yourself, if you’re at scale and you’re a large company– and if you’re just going to lift and shift, you can argue there’s some marginal efficiency that they may bring to what you’re doing, but it’s really marginal at that point. And remember, they have to make a profit also. 

But if you refactor, if you make it a cloud-native application, then the benefits are enormous. So as the tide has moved for new applications moving into the cloud, it became more and more obvious that these legacy applications and projects would also benefit from that new architecture. And now, I think it’s just staring people in the face, it’s just obvious that you have to do it.

OW: The term “application modernization” is fairly broad. It sounds like to you, lift and shift is maybe part of an application modernization strategy, but it’s certainly not the entire thing. What does that entire process mean to you, especially when considering moving to the cloud? 

AS: Well, lift and shift is a trivial piece of application modernization. If you’re doing a lift and shift, what you’ve basically done is move from your existing on-premise or co-located data center application into the cloud, and now it’s being managed at the lowest layers. It’s being managed by Amazon or Microsoft for you. But because they are only managing the very lowest layers of the stack, you’re getting very little benefit. 

At the end of the day, you’re both running on an x86 chip, you’re both running on a TCP network, so how much benefit are you going to get if you just pick it up from here and put it over there? Not too much. However, the cloud offers many other advantages: there are obviously standards, de facto standards like Kubernetes and Docker, which have enabled capabilities like elasticity, the ability to auto-scale, capabilities like disaster recovery, capabilities where you can scale based on need, not based on a fixed estimate that you make and then you’re locked in for the next three years with some sort of a capital investment [in infrastructure].

So those types of benefits you can only get if you are running a cloud-native architecture and benefitting from all the capabilities that the cloud offers to you. The resiliency that is possible by being built into an Amazon CDN distributed across multiple global data centers is only possible if you are a cloud-native application. 

That is what vFunction enables, and the magic of vFunction is we do it automatically. You could do it manually, but those are multi-year, multi-million dollar projects for every little application. What Moti, Amir and Ori and team at vFunction have created is the silver bullet magic button that allows you to do it automatically.

OW: Ashmeet, thank you so much for this conversation, it was very pleasant to speak with you and I look forward to hearing more about your goings-on at Engineering Capital! Do you have any sort of final message you would like to give to our listeners, or a place that you’d like them to visit (aside from vFunction)?

AS: Visiting vfunction.com is a great place to start. If you’re interested in companies like vFunction, you can always come to my website, engineeringcapital.com, which has other examples, obviously not competitive or exactly the same as vFunction, but I focus entirely in this space, and I welcome all the listeners to come and explore how many opportunities there are. And finally, I would say, if anyone is a budding entrepreneur who wants to start the next billion dollar company and is looking for a problem to solve, give me a call, I have a list of problems.

Technology leaders can now evaluate the cost of technical debt, determine what to modernize first, and then take action – all in one platform.