The Futuriom Q&A: Mike Dvorkin

Dvorkin musicgear H

By: R. Scott Raynovich

Anybody who’s anybody in the cloud infrastructure and networking markets knows Mike Dvorkin, who is currently a Distinguished Engineer at Cisco. Dvorkin is not only considered a world-class engineer, but he has a rich history and network in Silicon Valley startups. Dvorkin’s work in the industry today focuses on policy abstraction models and "intent-based nonlinear automation methods applied to all aspects of infrastructure, applications, and operations." (Whoa!) To make sense of all that – he looks at interesting ways to automate the operation of clouds.

Mike was a co-founder and Chief Scientist of Insieme Networks (acquired by Cisco in 2013 for $860 million), where he was responsible for conceptualization of the policy layer that is now part of Cisco's ACI/APIC. He is a founder of the Noiro project at Cisco, focusing on bringing policy abstraction to open-source networking, containers, and storage. Before Insieme, Dvorkin was part of the early engineering team at Nuova Systems and spent time in senior technical positions at infrastructure startups.

Dvorkin is also a big music fan, an angel investor, a connoisseur and builder of high-end turntables, and a generally entertaining person who is not shy about sharing his opinion. He’s yet another top engineer to emerge out of the University of Illinois in Urbana/Champaign, from which he holds an engineering degree and where he was a contemporary of Marc Andreessen’s. (Andreessen, who is now a VC, is known for being a pioneer on the Web as the co-designer of the Mosaic Web browser and a founder of Netscape Communications.)

Dvorkin musicgear V

Futuriom: Welcome Mike. What kinds of things do you see happening in the cloud world in 2020?

Dvorkin: There are going to be a lot of interesting things with how enterprises are using the cloud and which technologies will be used. The last few years we have been focusing on the fundamentals -- which building blocks you need to put apps in the cloud. Now people are figuring out that all the building blocks are there and they need to figure out how to use them in a practical way. You can do it any way you want, but nobody knows what's the most effective way. I think there will be a lot of best practices and interesting patterns emerging.

I spend a lot of time talking to banks, and they are pretty far ahead in the adoption of cloud native, like Kubernetes and surrounding ecosystems. The way they use it is interesting. Most people think that you build one big platform and then people use Kubernetes as a service. It turns out that's not how people use it. It's owned by teams at lines of business and it's almost like they administer it themselves. There are procedures and scripts they use, but generally, they operate their own staff, they allocate a VPC [virtual private cloud, a network system within clouds] per server, and the VPC surrounds that service and you expose that service to an API [application programming interface] gateway and it becomes this unit.

2020 futuriom primo pro 300x600

This is the extreme use case of Conway's Law, which says that application architecture reflects the organizational structure. It's like a Layer 9 construct.

Futuriom: So, we know that a lot people are moving to public cloud, but what about private cloud? I know that you are a big proponent of public cloud.

Dvorkin: Public cloud is great. It's really easy to set up and get going, it doesn't require you to buy any infrastructure. It's seductively simple. Also, for groups that deploy software, it's very easy because of the number of things you can do. So, it's easy and simple but it comes at a price, obviously. At a certain scale, cloud is expensive. The Amazons and other public cloud providers hope that you're going to have so much data inside them that it's going to be cost ineffective to migrate it out. So that's vendor lock-in, in a way. I don't think we're ever going to see a cloud [approach] where you can run anywhere. It will be project by project. There is still a big use case for private environments. It depends on your requirements and your sophistication. In today's state of private infrastructure, it's still operationally expensive to have your own stuff. You need a lot of people, and that's on top of all the real estate prices -- power, cooling, and environmental stuff.

What I think is going to be interesting is there will an emergence of private infrastructure control companies that will basically do what we try to do with UCS [Unified Compute System, a project Dvorkin worked on at startup Nuova Systems] but in an open way. So, how do you run huge arrays of white boxes and get them to be self-administering? Then you don't have to have people to manage them. And how do you do that at very low cost? That's very exciting. There are a lot of leaders that talk about how do you do secure booting at scale and how do you have computers that are disposable and self-operating. It's the same principle as pets versus cattle that people were talking about when the cloud was in its early stages. ACI [Cisco's Application Centric Infrastructure] took some steps to providing this but in a highly controlled environment. It was designed to work with specific hardware, but it provides some of this in a quite nice package.

Futuriom: Yes, ACI. Brings me to a good question. A lot of people know you as the architect of ACI, from Insieme. Are you satisfied with what came out of Insieme and Cisco?

Dvorkin: Am I satisfied? Mostly, yes. Some things I wanted to be different, some things could have been done better. But overall, I'm proud of what we have achieved. We had to rethink the way network is consumed. There was a lot of resistance because we were working with a lot of people that were traditional networking people. People are generally resistant to change. Describing networks in terms of how applications look at it -- initially people looked at us like, "Why?" Now all cloud-native network is built around similar principles. Nobody is thinking about VLANs [virtual LANs] -- they are thinking about various clusters and how they interact with each other, what applications need from each other, and what kinds of dependencies we have. ACI captured that quite nicely. A lot of these modern concepts were not in existence back when we were writing it. If we were to write it now we could rely on first-order principles of how people build distributed applications, but that technology was not available.

Futuriom: How are you still involved with Cisco and ACI?

Dvorkin: I look at ACI and think about what are the next steps as far as ecosystems. What is the role of ACI in cloud native? What kinds of things can we provide that's a broader scope than data center and behind simple networking. What is the role of ACI in API gateways and service meshes, for example. How do those things tie together to provide a coherent experience. I look at what companies to partner with and what technologies to rely on. That's pretty exciting.

Futuriom: You see a lot of startups and open-source projects. What's interesting to you right now?

Dvorkin: The interesting things are all around service meshes and API gateways. Service mesh became hot when Google announced Istio and everybody was talking about them, but they did not see quite as much adoption despite the usefulness. A lot of this comes from reported complexity. You have to manage a lot of policies.

What is popular instead is an adjacent concept called an API gateway. If I have my own application and I run it in a VPC, it's self-contained. I can front it with an API gateway because everything is APIs these days. I expose it and some people use it as if it's a SaaS [software as a service] offering in the cloud, even though it's owned by the same company. Logically it could be a different company -- I wouldn't care. It's up to me how I control the authorization and authentication and distribution of trust. That model works very nicely.

Service meshes provide you with more ways that services and microservices can constitute a broader application and interact with each other. That's pretty cool and very powerful, but it's early days and it doesn't come for free. If you look at developers, they are always trying to do less. With service meshes you have to do a lot for this stuff to work well.

Futuriom: What about the debate about how much information about the underlay -- infrastructure -- is needed to supply cloud applications? There are too many things that happen to ignore the infrastructure.

Dvorkin: There is a service-mesh concept and there is a network service-mesh concept. What they are trying to do is build not an underlay, but an "overlayish" underlay. Service mesh concerns itself with Layer 7 stuff or things above layer 4. The network service mesh looks at Layer 4 and below. It's like taking network functions virtualization -- NFV -- and applying it to the world of microservices.

I'm a big believer in service mesh and API gateways and solving things at Layer 7. I think for many of the use cases that is sufficient. But there are many use cases, especially like edge computing, where constructs like a network service mesh can be useful.

Futuriom: Do you mean for something like real-time video conferencing, where the network connection might not be that good?

Dvorkin: Well sure, the underlay network needs to work. The question is how much awareness the network should have. There is one school of thought that the network should know everything [about applications], but then you have to populate gobs of data everywhere -- layer 7 functions. It's not scalable. There has to be some information about what kind of quality you are [getting] from the network. Whether it's in the underlay or overlay construct, I'm not sure it really matters.

For the majority of applications, the network knows how to route and switch packets. It's good enough. For all the interesting stuff, at least in the cloud, it's going to be done at Layer 7. Developers don't always understand network stuff. But they understand Layer 7. It's HTTP [Hypertext Transfer Protocol] and API calls. I can make policies based on traffic.

People overestimate their need for bandwidth and capacity in general. What purports to be high performance, people overspend on that stuff by like 5X. It's crazy. They overscale, they buy instances they don't need. They buy storage they don't need. It's human nature to want more. One of the interesting things about private infrastructure is that there is a limit to how much you can configure. In the cloud it's unlimited and people get shocked by the bill.

Futuriom: It's like taking photos on the iPhone. You can take as many as you want, there is no film!

Dvorkin: Yes exactly. I'm on Android and everything gets backed up to Google Cloud. I'm not thinking about it. I take seven pictures of the same thing. And then I prune them.

Futuriom: Tell us about your startups -- I understand you do angel investing.

Dvorkin: I do a little bit. I don't focus on infrastructure much anymore. I like things like farming and fintech [financial technology]. For the infrastructure things, I try not to replicate functionality that the cloud providers will have.

Futuriom: So you think the large public cloud players are going to win most things?

Dvorkin: The Amazons and the Microsofts and Googles of the world will always do well with fundamental building blocks [for cloud apps]. They don't provide tools that help you operate your app. How do you stitch applications together? How do you have various processes? How do you make things easier? How do you help drive security processes, for example? Those will be taken care of by the service providers. I'd rather focus on human behaviors rather than the underlying technology. How do you help people do repetitive stuff with the cloud?

Futuriom: Can you give us an example?

Dvorkin: How do you build process pipelines for application scanning? You need to make sure your binaries are sane and not compromised. There are commercial scanners available, but you need to figure out how to use them.

Another example is there is all this AI [artificial intelligence] stuff. Given an application, how do I figure out how to run it, how do I get features from the cloud, and how do I configure those features? How do I use it optimally so I don't waste money? Amazon will provide you all the functions but they won't help you optimize that. Their goal is for you to not optimize it and spend as much money as you can.

Futuriom: So It's a bit like your cattle project. Tell us about that. [Earlier, Dvorkin had explained he's advising an image-recognition company called CattleCare to help automate the care of cattle.]

Dvorkin: Yes, it turns out that cows are easily identifiable. They have unique spot patterns. Their behaviors are simple too. For example, if a cow is pacing around, you know it's ovulating. And you know how much milk a given cow is producing and you can figure out which cows should be in a hurry to reproduce and which ones not. That's stuff I never thought about before but I find this exciting. A cow, for example, might want to eat from a specific spot. It can get very frustrated. It costs a lot of money to move the feed, so moving it is a big deal. It can be automated.

Futuriom: Cows aren't geniuses, you are saying.

Dvorkin: Yes. And there are problems with getting waste out of the farm.

Futuriom: I don't think we have to go into any more detail.

Dvorkin: Yes, that's too much.

Futuriom: Give us another example of a startup you find interesting.

Dvorkin: I like xCloud Networks. Look at what Cisco did with the white boxes and getting behind SONiC -- the open operating system intended for the service providers and the MSPs. Taking open chips and building systems out of them. The next step is self-operating infrastructure.
xCloud is trying to solve this -- they are coming up with the missing layer to provide services to the applications.

Futuriom: Is this for public or private clouds?

Dvorkin: The current thing is for private environments. Companies are trying to migrate from public cloud to private cloud without hiring a gazillion people.

Futuriom: There are a lot of people who will argue that's never going to happen, that private networks will disappear.

Dvorkin: Up to a certain scale, public cloud is fantastic. But after a certain scale, people are actually moving out [of public cloud]. There are a lot of startups in the Valley that actually have their own infrastructure. Everybody starts in Amazon. If you are a startup, there is no reason to have your own servers. But a few years later, after you start getting scale, it makes economic sense to build your own infrastructure.

Futuriom: What clouds for companies outside of Silicon Valley? Like a bank in the Midwest?

Dvorkin: Yes, especially for banking, we are going in an interesting direction. The applications are mostly going to be on top of Kubernetes. It's going to be the API. The ease with which you deploy applications will be everywhere whether you are in a public or a private cloud. It's going to be one API. The remaining include how physical things to be self-managed. The equipment will be inexpensive and the management software will be there. The cost of running it will be a lot more inexpensive.

Futuriom: That reminds me of bad technology predictions from the past -- like when somebody from IBM said we wouldn't all have PCs in our houses -- maybe we'll all have a cloud in our house?

Dvorkin: Maybe. A lot of enterprises have branches. You have to have computing and networking there. The effect of all the white boxes is going to be very interesting. I think what can happen is like Meraki [a wireless networking company that Cisco bought]. You manage stuff out of the cloud and you plug stuff in and it just works. That can happen. That's going to take awhile. Whoever figures out the operating system for that will be doing very well, and it's super early.

Futuriom: Who are the early players there.

Dvorkin: xCloud Networks, as I mentioned. Also Jessie Frazelle. She's a well-known figure in the Kubernetes space. She is doing some interesting things on how to run secure, private infrastructure.

Futuriom: You are an audiophile. Tell us what you do with turntables.

Dvorkin: Oh my god. I hoard them. They are like cattle to me. I think I have seventeen turntables. I buy bashed-up, mostly Scottish turntables. I replace the parts with something else. Some of them are custom ordered or after-market. I build out these contraptions.

[Shows a few of his turntables -- you can see the pictures above].

Futuriom: That's amazing. Thanks Mike.

Dvorkin: Thank you.