Dekel Tankel, VMware

All right, well, here we are for another episode of Breaking Changes. I’m pretty excited today to have Dekel Tankel from VMware. He’s a founding member of Cloud Foundry and global field CTO at VMware. Welcome.

Thank you. Great to be here.

Yeah. A mutual friend connected us, and once I just started hearing you talk about API gateways and management, I was like, all right, I’ve got to do a show with this guy. So let’s start with the basics. What does VMware do?

So VMware is striving to make multi-cloud a reality, which means helping build the applications of tomorrow on any infrastructure. So the company is now evolving to anything: any infrastructure, any workload, any cloud. So “any” is the word.

Nice. And as I’m learning the VMware landscape, there are several dimensions, and to what you do and what you’ve done in your history, what is Cloud Foundry?

Yeah, so Cloud Foundry was originally started as an attempt to open source, or to open in general, this platform-as-a-service landscape, which was very integrated or closed with solutions like Heroku. We open sourced this on the same principles: developers should never care about the planning of the infrastructure and should be able to just push their code into any environment and be super productive. The idea behind Cloud Foundry, in the original launch, was this triangle where you can plug in any development framework, any services, and run it on any infrastructure. This was kind of the beginning of this open platforms era. But in a sense, it was a little bit early, because there wasn’t really a multi-cloud. It was kind of one game in town at that time. But I think we made a lot of headway, and how we reached the business growth that the company had is mostly around this developer experience and the fact that developers can really become 90% more productive by using this platform. They don’t care about anything else, and their operators can trust this because it has all the security features they need.

Nice. So one more question to zoom in and bring this even closer to APIs: what is Tanzu?

So, as you probably know, VMware acquired Pivotal. For me personally, it’s kind of a full circle, because Cloud Foundry was started at VMware, and then we spawned out Pivotal, had fun for five, six years, IPO’d, and have been very successful from a business standpoint. VMware acquired us along with a few other companies, on the infrastructure side with Heptio, on the observability side with Wavefront, and others. The goal, and that became Tanzu, which is kind of this brand name for all the technologies that sit on top of the infrastructure layer to make modern applications a reality. So it’s the developer experience, it’s the DevSecOps experience, and it’s the infrastructure experience of running Kubernetes. So in a nutshell, think about Tanzu as Cloud Foundry 2.0 on a Kubernetes infrastructure, with any cloud, on-prem, with everything that comes around it.

Nice. Well, we’ll dive into the details here in a little bit, but I usually like to get to know the person I’m interviewing a little bit more before we dive into the technical details. So what’s your story? How did you end up at VMware? You gave a little bit of it with the Pivotal jump here, but how did you end up at VMware?

So my career is kind of upside down. I spent the majority of the first decade of my career in small startups and the second decade in large enterprises. Usually it’s kind of the opposite. So I had to worry if I’m going to have a paycheck next Monday in the beginning, not at the end of my career. A bunch of different startups, originally from Israel, I moved to the US, also from a startup. Those startups were primarily on the infrastructure side, and then a little bit on the platform side. At some point I said, I’ve got to look for something bigger, so I joined Yahoo. From a small Israeli startup to Yahoo, that was kind of an interesting transition and an interesting learning curve. At Yahoo I helped make Hadoop accessible for developers. So that was kind of my first engagement with public APIs that developers can use to access a broad set of infrastructure. If you remember things like YDN, YQL, those were kind of, I helped do some damage there, and also around Hadoop user groups and so on. It was kind of an interesting experience. Yahoo at the time was a company that changed a lot, so, fun and less fun at the same time.

Yeah, yeah, it was great. Yahoo lit a fire under my API imagination, the developer network, the query language. So I think you probably had a little, you’re a little bit responsible for me getting into the API space. Thank you.

Well, guilty as charged. I think the YDN, the Yahoo Developer Network, was a really humbling lesson for me on what it means to have like this tiny little API that you access, but on the back end, millions and millions of things need to happen. So it was my first exposure to this enormous gap between the external interface and what happens underneath. And we’re going to speak about it, I believe, later, around internal APIs, which is kind of what makes me excited, because you have like four or five external APIs, but you have thousands of internal APIs. We were struggling with that even back then with YDN. There was no structure for these internal APIs. We didn’t even call them APIs. It was APIs for the external stuff, right? So I think today organizations realize it’s very different.

Yeah, we’ll definitely get into the details and nuance of all of that. So let’s start with gateways, because some of the things you said in our previous conversations about not just the technology of gateways but the business and politics of it, I found pretty interesting. So what’s the role of an API gateway within the enterprise, would you say, in 2021?

Yeah, so I like to start answering this type of question with a quote from Jerry Seinfeld: people are the worst. So technology stuff is cool and fun, and we love it because we’re techies, but at the end of the day it’s the politics and the internal organization structure that either make it happen or kill it before it has any chance to happen. And APIs are no different. The traditional role of gateways, if we can use the term traditional, was an operations game. Developers, although the name has “application” in it aside from the acronym, it had nothing to do with the developers. They had no access to those giant centralized gateways. It was very gated and very closed, and it was an operational show, soup to nuts. I think we see a tremendous shift in that approach, and the roles of the gateways are following that change. That change is driven by, I think, two or three major shifts or pushes. So the first one is, how do you build microservices? When you have five of them, that’s awesome. When you have 500 of them, how do your teams collaborate? What’s the best way to actually build those complex business applications and have dozens or maybe hundreds of microservices underneath them? What is the right contract between those development teams to make them productive? And we see, for a couple of quarters now, maybe even years, that internal APIs are emerging as that standard. So the easiest and most convenient way for developers to collaborate between those different microservices that are being built is those internal APIs. So that’s one thing, and we’ll get to the challenges of that in a second.

The second thing is that the notion of, hey, let’s rewrite 15 million lines of Java code for our legacy apps and modernize that, that’s maybe lucrative for the global SIs of the world, but in reality it never happens. Too expensive, too hard to start, too much politics, and that’s not how modernization, to use another buzzword, is actually happening. I see that every day. I talk to hundreds of customers and prospects of Tanzu, and there is a different approach that proves more efficient. To use a term we use internally, it’s not approved by anyone, it’s not a marketing term, so just between us, brownfield APIs, which is, how do you use internal APIs to access or to make the old and the new work well together?

And the third aspect of all of that is that along the lines of cloud-native security, there is no way to say, hey, let’s create this gated environment where everything is secured and we’re just adding more stuff to our firewall. You’ve got to create a more dynamic and more elastic way of changing the networks to follow that development lifecycle. And service mesh is one of the things that we see out there, and how does that tie into APIs, we can also talk about that. So if you take all of that, in a nutshell it means that your API development and API delivery needs to be part of your software-defined lifecycle, and that’s not what happens in a lot of cases, with customers we talk to, specifically the ones that already adopted this massive centralized gateway. So they have this gigantic instance of Apigee or MuleSoft, and they have this set of operators that are guarding this with their lives. No developer can touch it, and now you expect a route change or an API change between two development teams to be part of it. So you get this nice CI/CD cycle that takes maybe hours, and then you wait three weeks for an API route to be modified. So not really part of your CI or your software-defined lifecycle. So does that resonate?

Yeah, that’s exactly where I wanted to go. In a lot of organizations I work with at Postman, and even before Postman, you go and talk to leadership, and I ask them what their gateways are, exactly what you say. They’ve got Apigee, they’ve got MuleSoft, they’ve got Mashery, Tibco, something in there, and I’m okay, great. And I go around and talk to teams, and I’m like, all right, how do you get things into the gateway? And similarly, the CI/CD, the technical flow works pretty well, but the people flow is a blocker. It’s a gateway, or a gate, not even a gateway, a gate. And then they’re like, well, we use Kong, or we use Tyk, or we use NGINX, or some other solution, and then when we have to, we publish up there. And because of acquisitions you’ll see other even more gateways. So it solely reflects what I’m seeing on the ground as well, the role of a gateway. But what caught my ear when you described it is you’re not just describing it in technical terms, you’re describing it in business and political terms as well, which makes the old-guard API gateway feel very much like the Oracle database of this next generation.

Yeah, that’s a great analogy. When we’re thinking about this, we’re actually thinking not in terms of gateways. Another internal term that I’ll deny if you repeat: API grid, right? So we’re looking at this problem that is much bigger than the gateway, because the gateway is one link in that chain. And the chain has to address, how do you make APIs a first-class citizen in your software-defined lifecycle, in your pipelines, in your change management, and how do you not take it out of the hands of operations? That’s not what I’m saying, there is room for that external gateway, but there’s got to be another set of solutions that addresses the fast-changing internal APIs and potentially also those few externals. But usually when I go and talk to a customer, they have four or five, maybe even one external API, and they have thousands of internal APIs. Now the one giant API has all the operations team hugging it like a tree and babysitting it like a pet, but the 5,000 internal APIs are cattle on the loose. Right? It’s not even cattle, it’s herding cats. And so that has to change, because it means developers cannot collaborate. We talk to many developers who tell us they don’t want to touch an API gateway ever again, because the experience of making those changes with the tickets and fighting with IT, and what time zone are you going to broadcast this, let’s say Japan Olympics, buy a sake to anyone in the organization to get ahead of the line, right? It doesn’t work. So the gateway is one piece.

So here’s how I think we address this, and the feedback is phenomenal. We see a lot of excitement from prospects talking about it, and I think it also can benefit the Postman community tremendously, because at the end of the day, all of us are successful when developers love APIs and developers don’t hate the notion of building APIs in secret until they’re ready to be this one stable giant thing. And I love your Oracle analogy, because it’s like we are shadowing things, small databases, until we are ready to expose the schema to our DBA, and we kind of go, hey, can you please look at what I did here? So in that analogy, the small tables would be the internal APIs and the giant Oracle would be the centralized gateway. Does that make sense?

Yeah. So what are the biggest areas of friction for developers when it comes to these API gatekeepers? We’re not going to call them gateways, because gateway would assume things are allowed through the gate, and it feels like APIs aren’t making it out the door. They would have value, partners would use them, the applications would use them, they would probably benefit, but they’re either not tested, secure, or don’t have the right policies. What are the things that are keeping developers, in a DevOps, DevSecOps way, from getting through these gatekeepers?

Yeah, so the first thing is, the fact that those internal APIs don’t get exposed is not because the IT people are bad, right? It’s because they are really not up to par with any standards. Like you said, they’re not secure, they don’t follow any best practices. And it starts with, so what I mentioned, the API grid, is much more than a gateway. You alluded to point number one: how do I get developers to build and design APIs that are up to the standard of my organization, whether that be a security standard, what kind of grouping I’m using, what kind of domain model I’m using, what is a good best practice when I’m doing a destructive operation versus a read-only operation? We are engaging in a pilot right now with a large global bank that told us pretty much between 85 and 90% of their internal APIs are not up to any standards that their architecture set. Just think about it. And they have hundreds of them. The reason this is happening is because there is no easy path for developers to start from a boilerplate. If you look at the Spring community, there is something called start.spring.io. It’s a super popular starting point for Spring developers, with millions of projects starting every month. The reason it’s so popular is it gives you this easy experience of dealing with the dependencies and getting your scaffold code up and running. We push something similar for the API world that allows developers to start very quickly, but on curated designs, so they can get to those blessed architectures or blessed API structures from the get-go. They don’t just copy-paste the first example they found on Google, which happens to be the easiest but also the furthest away from any corporate standards. So that’s one thing: how you actually get started in the right way.

The second thing is that if we follow this notion of continuous delivery, we all understand now that you cannot just push code into production and expect it to compile with something from Docker Hub or from any open source library. There’s got to be adult supervision of how you build stuff, how you turn your source into an image. There is nothing like that in an API. There is no equivalent of a buildpack, to take the concepts from Cloud Foundry that Tanzu is also adopting with cloud-native buildpacks that are super popular, this curated template or recipe for changing code into a runtime environment. There is nothing equivalent like a buildpack for APIs. That second item: how do you actually make the API, “compiling” away, it’s not really compilation, but how do you deal with all the calls that it’s making, the performance, how do you even test it in the right way, how do you make developers discover it? So it’s not just about testing, it’s about, am I using the right API in the right way, do I have a portal where I can go and dynamically find what I need, and it’s not based on documentation? You actually have the gateway generating the OpenAPI doc for you dynamically. So it’s also a service, there is no human that you rely on to make those changes. Does that make sense so far? The starting experience, the build experience, if you will, of the delivery experience.

Yeah, and I think where we see the most amount of disruption is in the role of the gateway itself, and now I’m finally getting to your question. None of this can work if every little change has to go to this giant gateway. Again, it’s not because the change management is bad or because IT people, you know, it’s their life mission to slow developers down. It’s all about blast radius. If you have one giant gateway, every little change can affect, and massively affect, the rest of your organization. The same gateway handles five internal APIs that a team somewhere is building, the same as our massive API entry point for our business. They’re going to meet the same standards. So the massive big API, okay, the small little one, he’s suffering because he’s going through all that change management. So there’s got to be a different way of architecting this. And what we’re suggesting is much more of a federated approach. So you think about not one gateway but dozens of gateways. There was this term “micro gateway” that’s sometimes being used. I kind of felt it was used in a different context that is a little bit archaic, but for lack of a better word, let’s call it a micro gateway or an app-friendly gateway. And you have many of these. Coming back to that large bank that I was referring to, they want to set up a gateway or a micro gateway for every business application. So it’s the proxy in front of your microservices. So think about a business application that has five, six, ten microservices behind it. It has a small gateway, and that gateway is where the collaboration starts. That gateway feeds a hub, that gateway handles all the internal communication between those micro APIs, and that gateway can also be the point where you start thinking about brownfield, how that business application is accessing external services. And by external I mean third party, not necessarily public services. You may still have one or two giant ones for the public APIs, but you’re really separating nicely between your public-facing APIs and your internal APIs, and you’re doing it in a federated mode.

And why is federated important? Because you have to do two things for this to work. You have to make it super developer-friendly, so developers can just change a route, and within a millisecond that route updates in the gateway. It cannot go through any kind of manual processes. But at the same time you want to keep this secure, because it’s true that there is a statement that an internal API you build can become an external API tomorrow morning. I agree with that. You cannot just say the internal APIs are internal quality forever. So the way we found this could work well is if you separate the lifecycle of the gateways from the route change. And that’s the third thing we offer in that API grid. It means that your DevSecOps or your DevOps team can manage the instances of the gateways separately from how developers are checking in routes. It’s two very separate items. You can think about developers changing a YAML file which defines the route, and then there is a separate mapping into a gateway, or many gateway instances, that applies those routes. And that allows you to do, let’s say, security updates to the gateway itself in a separate lifecycle than changing the routes. You can think about routes as part of your code base, and the gateway is more part of your application infrastructure, and you can separate those two lifecycles and even have maybe two separate pipelines for them. So does that make sense? Starting building a federated approach that is very developer-friendly, and at the same time separation of concerns between the gateway lifecycle, or the micro gateway lifecycles, and the route lifecycle.

So as a developer, I don’t have to be burdened with the cognitive load of everything a gateway does when it comes to policies, security, all of that, with every iteration that I need to make on my API. And you mentioned buildkit earlier. So for an individual API, how I build an API, how it gets discovered, how it gets tested, but are there buildkits for the gateway? Say a new line of business or new team gets stood up, can they rapidly set up a new gateway in a whole new process really fast and efficiently?

Yes. So when I mentioned many micro gateways, inherently that means there’s got to be an easy way to install them, standard ways to control them, and a very clean separation between what the gateway does and what the developer needs to worry about. So none of that can be a reality if it takes you a week to install a gateway for every instance. We spend a lot of work at Tanzu taking the Spring Cloud Gateway open source project, which is a very popular Spring project, and making it commercial grade, of course, but also very easy to install on either Cloud Foundry or Kubernetes. So essentially, within a few CRDs you’ve got the gateway up and running. It’s nothing more than a Spring Boot app running in the back end, and the engineers are going to kill me, it’s a lot more than a Spring Boot app running in the back end, but from a simplicity point of view, it’s really super easy to do. Even me, I can run many gateways on different environments in minutes. It’s very, very easy. And you can also achieve high availability very simply, just increase the instance count and the gateway takes care of the rest. So the install is greatly simplified.

But the second thing that gateway does is it really abstracts the developers to worry only about the things they need. So with Spring Cloud Gateway, which by the way the name, don’t get me started, naming it has nothing to do with Spring, it can support any language as long as it speaks HTTP, right? It’s fully multi-language. We have many customers in production already using a front end in Node, a Java back end, .NET. It really doesn’t matter. That’s one of the beauties of this API world: it abstracts the implementation beautifully. But back to the separation for developers, with Spring Cloud Gateway developers don’t even worry about SSO. That’s a killer feature everywhere we go. The only thing a developer needs to do is add a tag in their YAML file or their JSON file that says “SSO true” on a route. That’s it, true or false, zero things beyond that from a developer point of view, as simple as it can get. And tying this back to our starting example, we actually make it so that they don’t even have to say “true,” because we’re creating these boilerplate YAMLs for them, where if it’s a destructive or disruptive operation, let’s say it has to be SSO protected, and you can validate that. So even that decision can be ignored. But let’s assume at the very least the developer will say this route, true or false, protected. What happens behind the scenes is quite interesting. The gateway is responsible for knowing that this route is true, then it goes and looks for an SSO secret and does whatever it needs to do to have the OpenID connection working. And if it’s in the Tanzu Application Service environment, you can have a dedicated SSO plan for your organization. If it’s not, any OpenID Connect protocol will work. But neither the secret nor the definition of that flow has anything to do with the developers. That’s part of the DevOps responsibility when they’re setting up the gateway. So there is a very clean separation. There is nothing in the developer routes, that potentially are going to be part of your code repo, that has anything to do with SSO, aside from that SSO tag. So very clean separation, very encouraging for developer productivity. And there are other examples like this, like token relay, same story. Filters: if a developer wants to do rate limiting, it’s a very simple filter they apply in their route files. They don’t worry about the implementation of that at all. They don’t care about how the gateway is deployed, if it’s one instance, many instances. They only interface with the route file. So we make this super easy for developers, we maintain that policy and security on the DevOps side, but even then we are not talking about one giant centralized gateway. We’re talking about a federated approach of many gateways potentially fronting every business app you have.

And so each individual gateway has, I’m assuming, a standard set of policies. How does that work from a governance standpoint? Does it then get managed by a central governance group that sets all those policies and defines them all across the gateways?

Yeah, so it’s really up to the organization to decide how they want to run it. We see a spectrum of examples. There are the ones that think about it from a starting experience, which means that every gateway that is generated in this organization is going to be generated with the exact same policies. It’s not even up to the DevOps persona to decide what the different artifacts of the gateway are. So all gateways are kind of the same in a sense of policies. And then there are other types of organizations that say the DevOps persona has the freedom to decide how and what to configure in the gateway. The way you manage all these different instances, you can look at them, for example, the gateway emits an endpoint for metrics and performance, and you can consume that with Tanzu Observability or any APM tool. You can think about it as just an app, right? Like I said, it’s really just an app. So the way you manage 50 different Boot apps is similar to the way you would manage the gateway. Something that is pretty popular that is coming up right now is that we have integration into Tanzu Observability, or Wavefront, which follows the actuator endpoint from the gateway, and you can aggregate all the gateways into one group or many groups, let’s say this is line of business A, line of business B, and you have those gateways behind them, and you can look at your route performance. So it really makes it up to you how to manage it, but it’s as simple as managing a collection of apps.

So federated gateways allow for federated governance or centralized governance? It’s flexible enough?

Correct. So you can absolutely say I have a federated gateway deployment but I have a centralized management. You can say, for example, that all the gateways are emitting the route definition into the same API portal, so you have one portal, you can see all the gateways, and then you have different policies of who can access what. Or you can say I want an API portal per line of business, line of business B cannot access APIs of line of business A. But in that case, I think it will be wise to worry about how you can collaborate. Maybe they cannot access directly the APIs, but you want to maybe treat line of business B like brownfield, so it’s an external API from line of business A’s point of view, but they can still collaborate. It’s very flexible. It’s not dictated by us on how you should do it. And I can tell you, from most of the conversations I’m having, when the customer understands that the gateway is not one thing that is sacred and controlled by ops but something that is much closer to the application and controlled by DevOps, they also buy in much easier into this federated management alongside federated deployment.

Yeah, and it load balances the organizational decision-making down to the line of business or the DevOps, because I think that’s the part that some people are missing with DevOps. It’s not just the technical, it’s the decision-making, it’s the policies. You want to give teams the ability to make those decisions, but you sometimes still want to centralize how those policies get set and encourage that collaboration, maybe a center of excellence or something where everyone comes together to define those. But this sounds like it trickles down observability all the way down to the developers. So when it comes to observability, can I as a developer see traffic, see and have all that awareness around my routes and understand what’s happening?

Absolutely. You can access the routes that you applied into the gateway and see exactly how they perform. There are different slices and views on how you can see that. You can actually say, because the apply is nothing more than putting a YAML into the Kubernetes environment and updating a CRD object, you can say, hey, I’m applying these routes, I can see immediately the effect and come back and update, and I can do that in my inner loop, or local dev environment, and not affect the other live traffic on the gateway between teams. So you can have even different levels of access within the internal APIs, like my inner-loop APIs that I’m just testing, and then before I expose them to other developers, to your point. But I want to build on something you said which I think is super important: the policy problem. There is no magic solution, in my opinion, once you centralize everything into one gateway, and gateway is just an example, you said Oracle database, there are many examples like that. Once everything is in one place, you have to slice it and dice it in a very ridiculous, manual way, because the blast radius is huge. Once you separate this, and essentially you have different instances of API routes, in that case the policies become much simpler, and you can think about the deployment of these gateways as part of your policy. Who can access what is defined at deployment time of the gateway, and it makes your life super easy.

Which brings us into this notion of brownfield. You want to be able to have developers access third-party APIs, or maybe APIs from another line of business, as if it was the Spring Boot app next door. From a developer point of view, you never want them to worry about networking and access and service mesh and all that. And there is something pretty interesting that I think is valuable sometimes: that combination between the gateway, the portal, and the service mesh. What I mean by that is that you can create these policies behind the scenes. There is a notion called global namespaces, you may have heard about this, a GNS, this is something we promote a lot from Tanzu Service Mesh, but I think it’s much bigger than just Tanzu. It’s like, how do I make the cross-cluster Kubernetes world not a service mess but a service mesh, right? It’s so hard today, and it’s definitely not developers, I would say it’s almost even not DevOps, you’ve got to be a very experienced SRE with a lot of K8s knowledge to actually make that happen. And it’s not even just about K8s. What happens if you have VMs and containers running side by side? You have a lot of legacy stuff running on VMs, you have new apps running on containers, you’ve got to manage this better from a load-balancing point of view. So there’s a set of assets that I think we bring to the table without promoting too much, I’m the furthest you can see from a sales guy, probably, but you have things like NSX load balancer, you have the Tanzu Service Mesh itself, you have the integration into the gateway and the fact that the portal can get access to that immediately on the OpenAPI. And all of that means that there is a lot of technical mumbo jumbo behind the scenes, so the developer will just see it as if it was the Spring Boot next door. From his or her point of view it’s the same experience, but of course you have the strictest policies that you want to streak that access. And that’s the balance that I think customers would love to strike between productivity and control. Does that make sense?

Yeah, it makes a lot of sense. First of all, I’m going to talk to your VP of marketing leadership, because you need to be in the game, they need to use you to name things, because you’ve got some of the best names for things.

Well, I’m good friends with her, so maybe I’ll get out of it.

API federation, gateway federation at the level you described, as far as the delivery and building of APIs, it’s really flexible, and it fits with domain-driven design and really carving up the organization in meaningful groups and chunks so that you can deliver the most meaningful services and APIs. But what I’m also seeing from the front end, I’m doing a lot of healthcare and finance APIs and standardization when it comes to different countries, so you’ve got data sovereignty, you’ve got EU regulation when it comes to PSD2, you’ve got US regulations coming, or that just happened, around the FHIR specification in healthcare. So this type of federation and policies can really speak to how you carve up your global business in a way that you can serve up external or partner services in a way that is all coherently policy-driven as well. That’s pretty powerful.

Yeah, that’s totally true. We talked a lot about internal APIs, but everything we said on the federated approach, like you just mentioned, applies for things you expose externally based on whatever policies you have externally and what data or access you want to expose. Another example I’m working with right now in Europe, it’s around a utility company that wants to have third parties use their APIs to build IoT apps or smart apps for energy consumption, but they don’t have a clean way of exposing certain APIs to those third parties. So the only option they have is to rebuild these APIs at the engineering level to only access the data they need, instead of reusing the internal APIs they already have just with the federated, sliced approach. And the reason is because they only have one giant gateway, and that’s the only way to expose those APIs. So that flexibility also, in some cases, prevents the need to rebuild APIs if they’re already good enough for your standards and you just have an access challenge.

Yeah, and what you’re exposing in Germany versus what you’re exposing in France, the policies can deal with the regulation, how the data is stored, what’s available, what’s not. And I just did an episode with Ford about their fleet management of vehicles, and what it’s like to manage the data around an IoT device with wheels, when it’s rolling down the road and it’s connected. He was talking about the velocity they need to deliver new APIs to take that data, but again, because of regulation, the rules around what data can be collected, what can’t, who has access to that, moves just as fast as the technology. So having a federated gateway approach to all of that, by country, by region, by line of business, by whatever the bounded context that makes sense, and having policies for that. And what you said about the gateway management and the policy management and the buildkit for not just the individual APIs but the actual gateway, that’s kind of like Legos. Rather than having a big box of Legos, you have the kits to build the Millennium Falcon or build the different things, and it’s ready to go. Because most engineers I know really aren’t engineers, they’re just reverse engineers, meaning they only program what they’re taught or what they’re shown. So having buildkits at all levels sounds like a pretty powerful approach to this.

Yeah, that actually goes, I mentioned the starting experience, internally it’s called App Accelerator, the power or the effectiveness of these curated templates. It always, well, it surprised me, but it doesn’t surprise me, because I was a developer myself. Like 95% of the developers we talk to, they just apply the first example they see in Google, or they take the code that was built by their friend next door and reuse it. And that’s a bad thing, but it’s also a good thing, in the sense that if you create the templates easy enough to access, so it’s not an architectural committee, I used to run the architectural committee at Yahoo, so I guess I was one of the most hated folks there, but you don’t have those gates of manual approvals. This is actually not from me, but from a client I spoke to the other day, it’s like, oh, I get it, you’re giving us CaaS. And I’m like, what are you talking about? I just spent two hours talking to you about Spring and apps, and you’re talking to me about cars and containers? He said, no, not container-as-a-service, curation-as-a-service. Because he understood that this app acceleration gives his architects a power they never had up until now. The only way for them to control was to publish a 40-page white paper and hope developers will read it, which they never do, or gate everything on an architectural committee you’ve got to schedule six months in advance because everybody’s trying to get the time of those few architects. What if the output of those architectural committees is already this app acceleration template that every developer can just go into a website, complete SaaS experience, and get those boilerplate code for them? This was actually in the context of a Spring app, but the exact same principle will apply to what is a good route definition, what is a good way of getting started with a clean way of routing it. And to your example about Europe, even the routes themselves, sometimes you can expose something in the route signature and sometimes you can’t, and you can have the exact same API for different countries but it has to look different because it doesn’t have the word “customer” in it or something. So even those little things are super hard when everything is locked down and the change management is like changing a database schema, not applying the source change in Git.

Yeah, but these templates, for developers, so rather than having to go get approval and it takes six months to do something, they can take this, it saves them time, energy, and headache, because everything’s there. They can take it, run it locally, see how it all works, run it in a container, deploy it, play with it. And you could have different templates depending on line of business or depending on country or region, and then all the learning and education is built into the template. So the developers learn. They’re never going to read that white paper you put out on how to do everything, no one’s going to read that, a few people will, but most developers won’t. But if they can get hands-on and play with the template and see how it works, you’re teaching them good design, good development practices, you’re teaching them all in that one template.

Yeah, and it’s self-service, so it’s even faster than searching in Google, and it’s not ending up as trash code. It’s not just that they’re never going to read the document, it forces the organization to learn later, down the application lifecycle, to apply all these manual gates, because you cannot trust the developers that these APIs are ever going to be meeting standards. So now you have another gate of, hey, we have 5,000 internal APIs here, we’ve got to invest an effort now to realize, are they up to code, are they best practices, are they doing what they’re supposed to do? So it solves a bunch of problems ahead of time.

So this show is designed for leadership, business leadership. We do get down into the technical details, as we’ve shown, but how do you convince leadership, VPs, CXOs, to go all in on APIs and a federated API approach? How do you convince them?

Yeah, that’s a great question. The fun in my job is I can talk in the same day to a C-level and then to a hands-on developer, and it’s going to be one Zoom after another. So it forces me to think about the high-level pitch, the low-level pitch, all the time. Usually what I tell executives is that the world of building modern apps or modern microservices is changing, whether you like it or not. The APIs are becoming a de facto standard of how your teams are going to collaborate, and it’s not going to be UML-type diagrams, that’s the modern contract, and you’ve got to learn to manage it. It’s not enough for you to manage and control the few externals that you have, if any. You have to be able to manage those APIs internally. And by manage, it means have control, but don’t kill the productivity, because it’s very easy to put these gateways and just say make them a hardcore gateway, where everything is manually approved, but it’s a very slippery slope from that to completely killing your innovation. So as an executive you’ve got to think about this middle ground, this happy path of, how do I keep my developers productive and still help them collaborate and use those APIs as a way to save time, save bugs, because they can use stuff other people already built, and manage it in a way that meets my standards? And the thing about federated is, federated looks very scary until you understand the blast radius concept. So even with an executive I tell them, just think about it this way, we’re not suggesting put everything in one basket but make the basket less secure. We’re suggesting start separating the basket into mini baskets, and the separation of concerns takes a lot of the headache out of controlling it. And when you couple it with a better starting experience, or a curated starting experience, that looks much less scary.

And then, the challenge I think as an industry, and James Watters talks about it a lot, if you interview him sometime, is in a sense the API industry got everything backwards. We started from the operational experience and gated everything and completely forgot about the developers. So now when you go, and it’s even hard to have an API conversation without DevOps, that’s crazy, right? Usually when you talk about API platforms you find on the other side of the Zoom the VP of ops. “What do you care about APIs?” “Oh, because I’m responsible, nobody touches my Apigee, I’ll kill you if you touch my Apigee.” “How many developers are actually changing APIs here?” “Well, I don’t know, they’re probably too scared of me to even think about it.” So that’s the hard part of the conversation, about the perception of APIs as an app-dev thing and not as an ops thing. So those are the challenges we see out there.

Yeah, this really reflects, so I just went through the Gartner Magic Quadrant process, and Postman, we have 15 million developers, we’re an HTTP client, an API client, that’s where we’ve made developers’ lives easier, but over the last few years we’ve become a full-lifecycle API management solution, to use Gartner terms, but we consider ourselves an API platform. And our relationship with the developer is what you just described, but we really strongly believe in both sides of the relationship. And I really feel like that’s the area where Gartner needs to spend more time. I don’t know if it’s been Apigee and Mashery and MuleSoft wagging Gartner or vice versa, but they’re very provider-focused. It’s API gateways, management, and then they have one section where they go, what sort of stuff do you do, they ask just one section about developers, but it’s a big long document about everything API providers. So it’s a very one-sided view. I feel like the last decade coming out of the service-oriented architecture world has gotten better, because it’s APIs and using more of the web, but it’s still very provider-heavy, whereas, as you said, the developers and the DevOps and the agency and autonomy and them being able to move fast, this is why APIs happen, in my opinion. Service-oriented architecture, the enterprise laboratory, APIs kind of jumped out of the petri dish and started growing, because it allowed tech companies to move faster and do things quicker when it comes to mobile. So I think your description of that relationship and how it’s got to evolve at the gateway level in a federated way is pretty important.

Yeah, and I totally agree with you. This frustrates me every time I read these reports. And I won’t get into the why, I can guess that your guess is very accurate, but let’s leave it at that. It’s not only provider-focused, it’s infrastructure-up focused. So what I would tell Gartner is, hey guys, why would an app-dev lead ever read your API report? Doesn’t that sound a bit dumb to you? We’re talking about APIs here, you have “application” in the freaking acronym, but I don’t think anyone in app dev will spend the time reading this document, because it talks all about how you stand up the mechanics of APIs that he or she shouldn’t care about at all. So it’s all backwards. But that’s what gives you and me some fun stuff to do. I think we can change it. There is a big disruption going on, and we haven’t even started talking about app modernization. I think that’s the early but biggest wave, when more and more organizations realize the rewrite approach doesn’t work and there’s got to be a way to keep the lights on for all the old stuff and a smarter way of connecting the new experience. What app modernization is really about is creating new experiences, greenfield, connecting to existing back-end systems with a brownfield API, not rewriting those back-end systems.

So this is how we make brownfield development more attractive and sexy, so people aren’t just focusing on the greenfield. Well, I would argue there is no such thing as greenfield development in an enterprise. There is no way to build a real enterprise app without touching some of your back-end systems. Otherwise you go work at a startup, build something on AWS, you don’t have to. Where’s the value for an enterprise? You’ve got to connect to something that already exists in the majority of the cases. The question is how you do that effectively. And we already see patterns that come from the external API world, like rate limiting. I’m working with a customer now that adopted this brownfield API approach to one of their legacy environments, and they put an API proxy in front of it, and that was all great, and they were proud of themselves, but it turns out the clients are bringing down the legacy J2EE app four times a week because the request rate is too high. So, hey, you’re using Spring Cloud Gateway already, you have a route file, just use the rate limit route. And it turns out that’s all they had to do. It had zero effect on the app, because the app never got to that request rate that they actually consumed, it was more about the number of clients accessing it. And then you know, it turned out, from hey, we’ve got to hire Accenture for an emergency six-month project to rewrite this J2EE monolith, to 34 seconds of adding rate limits in the API realm. It’s just an anecdotal example, but you can think about these patterns. When you start thinking about the modernization of an enterprise environment, and you agree you need a better approach than rewrites, then that could be interesting.

A lot of folks are afraid of public APIs and everything that goes with them, because if they’re public it’s very risky and scary. But do you feel like adoption of some of these practices from public APIs, but bringing them internally, would help us make our APIs more mature and ready to be public?

Yeah, I think the more, when we talked about internal APIs can become external at any second, the idea behind it is that if you dramatically improve the way you start, control, and deploy internal APIs and the way you make your developers more productive, because similar to the fact that the IT ops guys are not bad people for gating everything, developers are not bad people for taking the first example they see in Google whether it’s secure or not, because they want to be productive, they’re sick of waiting for these architectural committees, so both sides have good intentions but the process kills it on both ends. So if you give developers a much easier starting experience, get things curated and built in a much more automated way, your internal APIs are guaranteed to become much higher quality, almost in a way that you can reduce, not take off, but reduce the scare factor of exposing things externally. Because the nice thing about the federated approach is, conceptually the gateway doesn’t care if it’s external or internal, it’s just what kind of ingress do you add to it. So if it works well on the internal API, conceptually, again, I’m not saying put an NGINX now on every gateway and boom, but conceptually, if the internal APIs are up to code and up to standard and much more in control, the switch to exposing some of them externally is going to be much simpler than it is today.

Yeah, wow. We could go on forever, but I think we’re hitting the hour here. I kind of feel like I’m going to have to have you back to explore some of these other topics.

Well, and I’d love to do a demo for you at some point for your audience, this API grid demo I’m running with customers, showing some of the Tanzu concepts and how that becomes easier. We can do that.

Yeah, your audience are, I think, the reason we’re, it’s almost like I need to apologize to your audience for what we’ve done with APIs so far, we as well. I want to keep pushing. I’m going to get other API management providers, I’m going to get MuleSoft folks and Apigee folks and Kong and other folks to step up to the table and answer some of the same questions that we discussed. So I would love to start figuring out some other sessions that involve, all right, show what’s different about API management today. And then I don’t think, as you said, we didn’t spend enough time talking about the modernization and digital transformation and what’s coming next, so I would love to get you back for more of that, but we’ve just got to figure out the right format.

Well, thank you. I appreciate your time today. This has been great. A very, very exciting conversation, and I look forward to talking more in the future.

Awesome. Glad you enjoyed it, and I’ve got to go. Thanks to my dogs for not barking. So that wasn’t surprising, I hope they are okay, because it’s not a usual thing with them.

I understand, my dog’s laying here right next to me, but she’s sound, she doesn’t care, so you’ve got to teach me here.

Yeah, she hears this all day, every day, API blah blah blah, so she’s pretty used to it. But anyways, have a good day, Dekel. Thank you.

Thank you very much.