The Journey to API Management on the Cloud – InfoQ.com
Live Webinar and Q&A: How To Build Payment Systems That Scale to Infinity (Live Webinar December 13, 2022) Save Your Seat
Facilitating the Spread of Knowledge and Innovation in Professional Software Development
In this article, we introduce the topic of code obfuscation, with emphasis on string obfuscation. Obfuscation is an important practice to protect source code by making it unintelligible. Obfuscation is often mistaken with encryption, but they are different concepts. In the article we will present a number of techniques and approaches used to obfuscate data in a program.
Susanne Kaiser is a software consultant working with teams on microservice adoption. Recently, she’s brought together Domain-Driven Design, Wardley Mapping, and Team Topologies into a conversation about helping teams adopt a fast flow of change. Today on the podcast, Wes Reisz speaks with Kaiser about why she feels these three approaches to dealing with software complexity are so complementary.
Roksolana Diachuk discusses how to use modern data pipelines for reporting and analytics as well as the case of historical data reprocessing in AdTech.
Audun Fauchald Strand, Truls Jørgensen describe how they have succeeded to align their teams by using: Internal tech radar increases communication between teams, and a weekly dive on a specific topic.
The need for high-quality DevOps personnel is skyrocketing, but it is harder than ever to find enough staff. It is possible to augment your DevOps organization using no-code and low-code tooling. Low-code and no-code tools can free up existing developers by reducing the time spent on integrating and administering DevOps toolsets.
Make the right decisions by uncovering how senior software developers at early adopter companies are adopting emerging trends. Register Now.
Adopt the right emerging trends to solve your complex engineering challenges. Register Now.
Your monthly guide to all the topics, technologies and techniques that every professional needs to know about. Subscribe for free.
InfoQ Homepage Presentations The Journey to API Management on the Cloud
The panelists explore how to build, integrate, and expose services as managed APIs in the cloud to follow best practices and manage large deployments.
Asanka Abeysinghe is Chief Technology Evangelist @WSO2. Matt Morgan is Senior Director, Software Engineering @PowerSchool. Viktor Gamov is Principal Developer Advocate @Kong. Kevin Swiber is API Lifecycle & Platform Specialist @Postman. Renato Losio is Principal Cloud Architect @funambol.
InfoQ Live is a virtual event designed for you, the modern software practitioner. Take part in facilitated sessions with world-class practitioners. Hear from software leaders at our optional InfoQ Roundtables.
Presented by: Tobi Knaup – co-founder and CEO, Dan Ciruli – VP of Product
Presented by: Alex Lunev – Director of Engineering, Keith McClellan – Director of Partner Solutions Engineering
Losio: Before going into the discussion, just a couple of words, what we mean by API management and API management on the cloud. We want to discuss basically, what are our best practices? How do we manage large deployments? What is the role of integrating software and API to connect application and data that is growing every day? How can we effectively do that on the cloud? How can we do API management on the cloud? How can we integrate existing services? How can I manage them as APIs?
My name is Renato Losio. I’m an editor here at InfoQ. I’m a cloud architect. We are joined by four industry experts on API management. I’d like to give each one of them an opportunity to introduce themselves and also to share about their own journey to API management, specifically on the cloud.
Gamov: I’m a developer advocate at Kong. I do all the things around cloud connectivity right here with Kong. That includes APIs that we expose to the outside world, but also APIs that we expose within the organization and how to provide tools, so developers can build APIs as well.
Swiber: I’m Kevin Swiber. I’m an API lifecycle and platform specialist at Postman. Postman is a developer productivity tool for producing and consuming APIs. My day-to-day consists of a lot of things, but among them is talking to folks about where they are in their API lifecycle and platform strategy, and how to improve that on a day-to-day basis. I’ve been in the API management space working in API vendors for the past 10 years. I am the Marketing Chair for the OpenAPI Initiative.
Morgan: I’m Matt Morgan. I’m Senior Director of Software Engineering with PowerSchool. I came into PowerSchool last year along with my product NaVi, as we were acquired from another company. I spend a lot of time working on integrations with other PowerSchool products. We’re a multi-tenant SaaS product. We’re integrating with other multi-tenant SaaS products. We’re integrating with single tenant on-premise products. Lots of API work. I like working with APIs because it allows developers to communicate without having to understand the underlying technologies. We run in AWS cloud, and we’ve heavily been leveraging serverless. Some of the other products we’re integrating with use a variety of different technologies and clouds, and basically, anything you can imagine.
Abeysinghe: I’m the Chief Evangelist at WSO2. I tell WSO2 story. In addition to that, providing strategic consulting for various customers, including API strategy. When it comes to WSO2, we provide API management products in open source, SaaS, as well as in private cloud. That’s how we are contributing. My experience goes a long way. Actually, in 2011, I wrote a blog about API management and then that’s how WSO2 started getting into API management. I have a close relationship with this subject.
Losio: I will actually start with you with the very first key question, because I’m definitely not an expert. What are the key differentiations between API management on the cloud and on-premises, whatever cloud provider, Matt mentioned AWS, but it can be Azure, it can be whatever else you like.
Abeysinghe: That’s where we need to be a little bit careful because I think lift and shift is a common pattern we see in the industry, people take the on-prem stuff, and just put as it is on the cloud. We see the same pattern happening in API management as well. That’s the first differentiator that we need to lift and shift gears as the first step, but then we have to optimize the workloads that we are running on the cloud, to utilize the cloud capabilities as well as to optimize the resource usage, because resource usage directly correlates with the cost factor. That’s the first difference that I see.
Then the second thing is the latency requirements. Because not everything is running on the cloud, there are certain components that might be running outside the cloud environment. We need to look at how we can optimize some of these interactions that we are doing with various data sources and systems and subsystems. We need to plan it properly, and utilize as much as the cloud capabilities provided by the underneath infrastructure provider is another thing that we need to consider when it comes to API management on the cloud.
Swiber: Of course, everything Asanka said was great. A little history here is that we used to see either/or. We used to see folks with an API management solution that was cloud hosted, or one that they had on-prem. These usually were fairly large deployments that took often outside traffic coming into their internal systems. Over time, and with the explosion of microservices, we really saw this movement into a multi-gateway world. Folks typically aren’t choosing between on-prem or cloud for every scenario now. It’s usually a case of we’ve got some cloud hosted stuff for our external traffic coming in. With the explosion of microservices internally, we have an internal on-prem solution for managing those as well.
Losio: Actually, here I already immediately jumped to a question that I know is going to be a bit controversial, but I throw the topic, is like, if you develop just in the cloud, if you’re coming from a cloud background, and you are leveraging your microservice inside a single provider, whatever that provider is, when is the point when you really feel like, do I need to have an external API management solution, a third party one? Why do I actually need it? When is the point where I need to do that step?
Morgan: When do we get into a third party to help manage our APIs?
Losio: Yes. I see the extra features or whatever. It often is, when I see something external, the first thing that comes to my mind is complexity, extra cost. It’s always balancing. I never really know when is the point where it’s too early or too late?
Morgan: Too early or too late to bring in a tool to help manage the APIs? I think there’s definitely a too early stage here. If you’re just in the inception phase, and you just have an idea for a product, I want to sell T-shirts on the internet or Facebook for pets or something like that. I don’t think I would start architecting that thinking about API management. I think I would start thinking about, what’s the user experience here? How can I get that to market? How can I get some feedback on that? Start trying to sell this and grow my company, or something like that. I think the API management can come in a little bit later than that. Then, are you using something that is a third party or something from a cloud vendor? I think that really comes down to, what is your cloud strategy, and what compliance you may be facing? How do you think of the competitive space? What managed services you want to leverage. I do think that there probably becomes a point where you reach a level of success where you say, ok, now I’m starting to have some technical debt. My developers can’t discover the APIs, or it’s difficult to understand what my system is offering. At that point whether it’s an open source product, or some vendor that comes to help, I think that’s the appropriate time.
Gamov: For me, it’s a very easy question, because we’re an infrastructure provider company, so we need to make sure that whoever use our tools, they will be successful regardless if it’s the cloud or on-prem, or if they want to run this in a heterogeneous space. Like Kevin mentioned this, that these days, it’s not a question about going into cloud, it’s a question more about how many clouds. Because what we see is that many customers actually run either as two hot deployments, and that want to have a unified communication between those systems, or they might be running this as one system as a backup. Even though it’s a backup, there needs to be a configuration that will replicate the status of the main production, all these things. In my world, those things are API management, API lifecycle management. Also goes together with configuration management, and together with automation. All things that we learn how to love in a DevOps world also comes together with API world. Things around the API Ops. Many things that we learn from the tools, and automation things that are available for delivering software API, it’s another software that we deliver through those tools.
Losio: Actually, you mentioned an interesting topic as well, Kevin, before about the multi-cloud, multi-policy. It’s hard now to find a large enterprise that is just one, either in-house or either one single provider or whatever. I was thinking, if I now have to choose something, if I need to change or start work in API management, I have two standard feeling, one is on the cloud. One is the cloud lock-in that I might be stuck, whatever is reasonable or not with that vendor that what I’m using from that specific cloud provider, whatever it is, AWS, might force me to stay or might make my transition to another cloud provider difficult. Or if I use a third party vendor, is there going to be something that I can change later on? I was wondering if anyone has any feedback about that, whatever we call it, vendor lock-in, or whatever you want to call it, tools risk, OpenAPI Initiative.
Swiber: I’ve been in the API space for 10 years. My opinion is probably going to be somewhat biased, but my life prior to that, I was in enterprise architecture for several businesses. This question becomes really important on vendor lock-in. I think my feelings have progressed on this throughout the years, as I’ve noticed that vendors aren’t really the only way you get lock-in. I can get lock-in to a frontend framework. How many folks have successfully migrated off of React after finding a solution that they thought might be better? Very few. You end up getting really stuck to this infrastructure that you put in place. When it comes to something like API management, yes, I think there is going to be a certain amount of vendor lock-in that happens when you make that decision. Some of the criteria around making that decision needs to be around the vendor itself. Is this someone who’s going to be a strategic partner for me as we continue to grow? Is this someone who’s going to help influence us as we can help influence the product and help them, and we can grow together? I think vendor lock-in feels very scary. The reality is that you are already locked in in several different ways. The truth is, how do you evolve with that reality going forward? It’s not an easy decision in a lot of places.
Abeysinghe: I completely agree with Kevin. There are some lock-in when it comes to the software development and running this stuff in different environments. Only one area that I would like to highlight, the gateways are becoming a commodity. That’s where the standards are becoming very important as well, as you mentioned, OpenAPI specifications, AsyncAPIs, GraphQL. Things are getting standardized. Even we are not building API Gateway anymore, it’s just Envoy, because that’s becoming a commodity. Then there are other parts associated with API management. That’s where the real vendor lock-in comes in, how you manage the lifecycle of the APIs, observability, and security. All these things are running in the control plane, so the data plane is getting more commoditized, but the state of the control plane is having some vendor specific components. Even we started something called API Federation specification some time back, but we didn’t get much support from the industry. I think we need to have more of those type of initiatives and get some of this stuff standardized. That way, we can provide a flexible environment for the end users to switch or do whatever that they would like to do. Because end of the day, if we provide a better product, they will stick. That’s how the experience economy market is running at the moment. That’s how I see this from a vendor point of view.
Gamov: It’s very difficult not to be triggered when everyone is saying, Envoy is all the things, but Nginx, and Kong is based on Nginx, was there, and still there, and still plenty of innovation happening in this space. I would not just dismiss this, again, also very biased, and that’s why I need to say this. Envoy is an incredible tool and many software tools that we built like service mesh, for example, that uses Envoy. However, it’s still a new technology and a technology that’s getting very wide adoption, however, still, roughly 80% of internet runs on Nginx. In this case, Envoy still needs to go a very long way to win hearts and minds. Speaking about Envoy, we got this very interesting roundtable on the recent ServiceMeshCon in Valencia, and everyone was actually complaining about the sidecars and having Envoy as another step of the infrastructure. It’s an interesting situation, interesting state, and depends on what vendor we’ll be talking about their tech. I’m totally completely transparent about this.
Losio: You made a good point that 80% is still running on Nginx. When we think about API management and adoption curve. Because when you go to a conference, you’re always a bit biased, because it’s like you always talk to guys that if I go to a conference, 100% of the company are running Kubernetes somehow. Even if I go out of there it’s a high number, but it’s not 100%. I was wondering as well, with API management, more so thinking about enterprise, because of course, as we said before, maybe a small company, someone started maybe, they might use it, but maybe it’s not there yet. How do you see API management, at the moment? Do you see it as an early adopter phase or already early majority, or even just few innovators? Where are we compared to a couple of years ago?
Morgan: Honestly, I haven’t seen a whole lot of change in that space. I think we’re building APIs with different tools. Ten years ago, we were pretty much all in data centers. Cloud was just getting started. Containers were starting to pop up. OpenAPI was there. Nginx was there. I think we have to build an integration. Yes, we built it, and then there’s not really any documentation or any follow-up from that. That was there. I think that’s still there, and it’s still something that we struggle with as an industry. I’m doing serverless, so I’m using Amazon API Gateway and EventBridge, and services like that to build APIs. That’s a change. The one thing that’s changing there, at least for me, is I’m thinking more about asynchronous APIs. I’m thinking more about like, what is the contract? There’s an AsyncAPI foundation out there too, to go along with OpenAPI. What is the contract of this asynchronous workflow? What do the payloads for that look like? What does it do? It tries to solve the same problem that OpenAPI does, so that we can communicate, what does that asynchronous workload look like, in a non-technology specific way?
Losio: Kevin, have you seen any change recently in that space?
Swiber: I think first of all when we talk about API management, it’s helpful to put some definition around that, because the definition of API management has really broadened over the last 10 years. It used to be APIs were an integration point. You would focus on things like protocol mediation, maybe some caching. Then folks started looking at APIs like a product, and then having things like a developer portal would be really interesting there, and making sure authentication was in the right place. We’re to a point now where instead of trying to convince folks, as an industry, like yes, we need APIs, we’re at a place where people have so many APIs it’s hard to manage. They’re talking about, do we have the right testing strategy? Do we have governance in place? Do we have discoverability of our APIs? If we go back to those initial origins of integration points, that stuff is probably moving over to late majority, perhaps laggards now. If you look at some of the newer stuff, API as a product thinking is still gaining traction and hasn’t peaked yet. The idea of developer portals, they’ve been out for a really long time, but they’re starting to really get some momentum on iterating, and changing even faster into this new world where we have an explosion of APIs that we need to manage. I don’t think it’s as simple as saying, like all of API management is on this maturity path. There are bits and pieces all over the place. I think we’ll continue to see that grow and change over the next few years.
Losio: Actually, what you mentioned really reminds me what actually Matt said as well on AWS, the API Gateway. Yes, it’s true. Many people are using it. I never saw so much excitement about a new feature for Lambda recently when they announced that you could call a Lambda through a URL, going around the API Gateway entirely. That brings its own problem, but it shows how many people actually were using API Gateway, because they had to do it. If they could avoid it, they would even avoid it. It’s not a straightforward answer.
Gamov: For your particular example, I think it’s more about the overall strategy that Amazon as a company start blowing out, because some of the products just exist, and some people do use them, some people don’t use them. That’s why smaller vendors like WSO2, Kong, and others, they have bigger ideas. They can innovate in the space because they have an overall bigger picture. For Amazon, it’s just another thing that they can sell. For us, we want to have an overall experience. I will double to what Kevin said when we were talking about the vendor lock-in. We don’t want to have vendor lock-in. We understand that our customers are smart enough to pick up a good solution for them. We want to be the best partners for them. That’s why for some companies like Google, like Amazon, the gateway is something that they will just throw for your discount, as a change for your EC2 instances or for your Lambdas. There is overall strategy around API management, API building, developer portals, collaborations around how to build those APIs, and overall approval process of using tools like GitHub, and GitOps, and things like that. This is the part where smaller vendors can innovate and can show actual value for the customer, and become a right partner for the customer, so they would see value of applying those tools. Not just, ok, so let’s go call the Lambda URL directly without rate limiting, without caching, and see how we continue swiping our credit card.
Losio: I was absolutely not recommending that. I was actually thinking that there are some scenarios where it could help, a very small link or whatever where you might not need the complexity of the gateway. I can see very bad uses of that. I was just using that as an example.
Gamov: If something is possible, it doesn’t mean you have to use it.
Abeysinghe: I think there are two sides of this story, as witnessed how the products are matured, and the capabilities are matured. I think collectively, all of us, we have contributed a lot, and then brought API management into a great state. There can be many standards coming in the future, and we will support it. From the user point of view, I think it’s a very geo sensitive thing. If you look at North America, it is more into late majority, but the rest of the world, it is early majority. That’s how I see, if you look at it from the user point of view.
Losio: You’re basically suggesting that it is not just between large companies and smaller company, but as well, really the area of the market where geographically it is more mature.
Abeysinghe: I think generally technology adoption happens like that. A lot of people watch what’s really happening in North America, and then sometimes Western Europe capture most of this stuff, and then it flows to rest of the world. That’s what we see as a pattern for a long time. I’m not telling the innovation doesn’t come, but innovation does come but that’s a common thing.
Gamov: I concur. Things like for example open banking standard, like quite mature in Asia-Pacific and Australia. We have some customers who invested a lot in open banking, and after Europe picking up, and America is not near close to the open banking initiative. In the banking space, you start seeing things like, finally banking allows you to use OAuth 2.0 to access APIs, because in the past, you need to enter login and password. Now, more banks allow to integrate the system. This innovation actually comes from the smaller companies, like Okta. The standards and the innovation comes from the small company, but I agree in terms of geography, it’s also important.
Losio: I know that none of you has a crystal ball, but where do you see the market going in 5, 10 years? Not just in terms of growing, hopefully.
Gamov: I hope it will grow, because last couple weeks the market was not in a fun place.
Losio: I was wondering, mainly, if we’re still going to talk about it, there is going to be that mature technology and part of pipeline.
Swiber: I work with tons of folks today on the challenges that they’re facing. A lot of folks are just really getting started trying to get some governance in place, consistency between APIs, some management around who’s producing APIs. Where are they going? We see terms coming out like shadow APIs, APIs that exist that you don’t even know were there. Zombie APIs, APIs that aren’t getting used anymore. I think this is only going to continue, as we try to get a handle on this over time. As Matt was saying, this definition of APIs, and what is an API is really expanding to include event driven systems. I think we’re just beginning to see AsyncAPI take off as a sister standard to OpenAPI, and this event based or message based protocol. I think we’ll see lots of innovation happen along the async path over the next few years as well.
Morgan: I agree. The thing that I see becoming more prevalent is more managed services, more things where you don’t have to rack hardware or things like that. All the clouds are doing that thing. You also have smaller vendors that are also getting into that space and are providing more managed services. Every day it seems like there’s a new web based SQL offering or something like that, where I can just make API calls to a SQL database that’s globally available. Those things I think are really amazing. If you don’t want to be in AWS or you don’t want to be in Google Cloud or something like that, but there are really great vendors out there that are doing some really interesting offerings. I think we’ll see more adoption of those. We’ll see more good options to build with. I think those kinds of services are really great for builders, because you can just get building and you don’t have to install MySQL, and configure all that. I think we’ll see more of that in the next 10 years.
Abeysinghe: I think it connects with what Jeff Lawson said about build versus buy. Buy the platform and build the innovation on top of it. Because then we can focus more on the innovation side, because if you talk to CIOs and CTOs, they are building platforms, and most of the development teams are even supporting platform engineering teams to get these things up and running in production environments. That’s the key challenge. If we get the correct platform, especially like a SaaS platform that provides the infrastructure and have the flexibility for the organization to configure it in the way that they want, then you can focus on the application development and focus on the customers. That’s how I see. I completely agree with Matt and Kevin on that.
Losio: That brings us back to the topic of how to sell it to a developer. I’m a developer. I’m working with my few services on AWS, try to build, mix and match. Probably, I’m using some API without even realizing, but suddenly, someone told me that I should focus on API management, or actually even worse, someone brought in something new that I have to work on it. How do I sell it to developers the main advantage of doing API management on the cloud? Where, as you said as well, Matt, the concept of the service is going to be managed, most likely I don’t have to run my own server. What’s the biggest benefit as a developer to introduce an API management system? If there is an advantage.
Swiber: It gets us back to that definition of what API management is. We’re taking a broad view of what API management is, and saying that it starts when you begin collaborating on an API. It includes the testing of your API, it includes designing what your API is going to look like. Then all that stuff comes in early. Folks, developers, if they’re not using any help for this, they’re already experiencing issues around collaboration and how to get that done. It could be as simple as saying actually, you probably need it right now. When we talk about the runtime components of that, we talk about things like authorization. There is a case to be made to a lot of folks that, A, again, these conversations should be happening early in your process, how are you securing your APIs? B, how do you want to manage the security of those APIs? Do you want that to be distributed across every team, or do you want some centralized management around that? Do you want some rules in place to help you do that? Do you want some guides? Do you want some infrastructure, some software to help you do that? I think folks get to the runtime side through authorization requirements, more often than not.
Losio: Does that depend usually just on the size of the company. Of course, I can see that if I have a development team of 3 people versus 300, probably I have different requirements in the sense of standardizing and centralizing. Do you see cases where I need actually to do the next step when I’m still in an early phase, or with a very small engineering team, or usually something that you do at a later stage on existing deployments?
Swiber: For me for even early stage folks, I’m seeing them move to API management solutions for this as well.
Gamov: You’re absolutely right. What I would just point out, it’s not about the size of the team. It’s more about the maturity, about engineering maturity, when the team is quite proficient on the things like 10x engineers. 10x engineers, they understand that, at some point, they need to grow, they need to collaborate, and especially if they’re in the world of microservices, this stuff will come with a price. There’s two approaches of how teams are taking this. One is a schema first. They use OpenAPI spec defined all this contract. That’s why it works for the teams where they have a dedicated team for backend and dedicated team for frontend and dedicated teams for mobile maybe. I don’t remember who mentioned this term, about the API as a product. Even it’s also internal because your API consumers are internal, you have teams who do frontend, teams who do mobile. It’s still a product. In this case, you need to have some sort of removing this roadblock so that people can start working on the frontend once the spec is there, even backend maybe it’s not ready yet.
Another approach is to use code first. The people develop APIs. Usually, this is like a legacy approach. The people already start building this, and all of a sudden, they understand they need to document this, they need to publish on the developer portal, because other people need to use it somehow. That’s why they use some generators to generate OpenAPI spec based on the running spec. This is where engineering maturity comes into play. Because if you’re following like a schema first, it requires some discipline and require a certain level of expectation, because many people will be involved, and there should be some process to establish it. In many cases, people cannot wait. They say, are we in the waterfall again? Why are we not agile anymore? That’s what I see happening.
It also somehow correlates to the sizes of the teams and the sizes of the companies. In the startup space, maybe it’s not so much important, because this stuff will be rewritten very soon, maybe after six months, or after a year. Because some of the iterations of the software in the startups, they can move faster, they can rewrite things faster, they can iterate and fail. If it’s a big organization that involves API as a product, everyone embraces microservices, and they’re ready to go and sell internally, like give the service for shipping code.
Abeysinghe: We can’t avoid the programming models and the design principles that are bound to APIs, so we had to accept it. That’s there. I think the responsibility of a developer, that’s the key thing. How much he or she is responsible about the API that they expose, because as an example, I found the situation that one API went down, and around 200 applications got affected, assume number of users who are getting affected from 200 applications. That’s the impact. I think the transactions are going through these APIs, and the business value that these APIs are carrying is really high. That is a thing that the developer should identify. That’s where the API management is coming, like how we can have proper versioning. How we can manage this API, use the standards and go through the organization standards that they have defined for the APIs, all these things matter. I think size of the organization doesn’t matter. The key thing is who’s consuming. If it is a shared API, I think that particular team should focus on API management. There’s a runtime component as well, like how healthy, and whether it’s providing the business benefits. How you can manage these APIs in that production environment, all these things matters. I think it’s a good thing to think but how complicated and what extent that this development team is stepping into, is depending on the maturity of the entire application that they are building.
Losio: Actually, Viktor raised an interesting point about saying that startups will have any way to rebuild everything. I was thinking, I start a new startup. I’m in a young and foolish and whatever, I’m working on this new cool idea, and here, I say I don’t have time to think about API or to think about doing things properly. I’m mainly thinking about go live as soon as possible. Then I think about that later, because I will need to redevelop it. Is that fair enough to say I shouldn’t care, or I should start in the cloud, I have an easy way to start already with API management? I have really no excuse not to do it.
Morgan: I don’t think you should get too hung up on the nuts and bolts when you have a great idea. I think you should drive ahead on that. If you have some expertise to use something like AWS Amplify, or Google’s Firebase, or one of these things where you can spin up an application very quickly, you don’t have to manage the database. It could be a third party. It could be FaunaDB, or MongoDB, or Vercel. There’s a whole bunch of products out there. If you have any expertise to use this, I would strongly recommend doing that. If all you know is Ruby on Rails, build your application that way, and find a server somewhere. I think there are a lot of great tools to build on. I don’t know if in the heat of the moment as you’re trying to launch your brilliant idea is the great time to learn serverless, or some of those other things. Those are good skills to have, and I would apply them if they’re available.
Swiber: I think it depends on what you’re doing. If you’re building just a single web application that you’re putting out there, maybe not. If you have been bitten by this API first bug, and you are building an API as a product, then API management should absolutely be something that you’re looking at to help launch that. Again, there’s a lot that comes with that, how are you going to reach your consumers, developer portals and things like that? Are you giving your developers the best experience? Because that’s going to determine success on top of the value that you’re providing. Is that experience good? What tools are going to help you get there? I know for me maybe it takes me a little bit longer than some folks to catch on to things, but I need to be hands-on with this stuff. I need to have some experience actually going through and playing with these tools and seeing how they work. There’s tons of free open source stuff out there, or trial tier. Would definitely recommend folks get their hands on that and play around with that if they have the time. Again, as Matt said, if you’re launching something, it’s got to be today, and you’ve got the expertise for something that wouldn’t require a whole set of infrastructure, then absolutely go that route, because your speed to market is going to be important.
Abeysinghe: I think Kevin and Viktor, we have a role here as well to simplify the tools, and then make it easy for the developers. As long as we do that thing, I think then anybody can start getting hooked to the API management cycle, and then get the benefit of it. We have done a lot, especially Postman, I think, very popular among the developers because of that simplicity, as well as how it is affecting the productivity of the developers.
Gamov: As well as Insomnia, also getting a lot of attention on collaboration aspect recently. We’re certain that the approach with a GitOps, and automation, and CI/CD things that help to simplify and maybe eliminate some errors, it’s very important. That’s why, like in Insomnia, which is also a great tool, we’re spending a lot of time to do the thing that Kevin mentioned. Like you’re a new guy joining the company, you want to discover what kinds of APIs are there, like are there zombie APIs that no one is using? Or, what are those APIs that are available? Having the ability to immediately pull up the repository of the things that are immediately available for you as a developer, and you can start building things. That’s incredible. Collaboration and automation, that’s the keys for success, regardless if you’re a startup or if you’re a smaller or you’re a bigger company.
Losio: I wanted to ask each one of you for a very quick advice. It’s like, I want to do something. I want to start to act in that direction, to think a bit more about API management that I never thought before. What should that be?
Morgan: I think the main thing to focus on is the developer experience, how your developer is going to interact with this tool. How are they going to receive this? I think that that’s a primary driver of success in any tech space is to really focus on bringing people to this, to express things in terms that they’ll understand, and provide a good path for learning and understanding the tools. Then being able to answer questions, how do I unit test this? How do I run this locally? How long does it take for me to deploy this? How can I interact with it once it is deployed right with other things?
Swiber: Take a look at your API lifecycle, how do you go from ideation to something that’s being launched? We take a look at this in a lot of different companies. It becomes really clear, really obvious, like, our testing is lackluster over here, or the way we do authorization really isn’t all that great. I would find a place to start, and then begin bubbling that stuff up earlier in the process. Talk about security earlier in the process. Talk about testing earlier in the process, and see how that process can change because it’s not just about tooling, or what vendors can provide. Oftentimes, it’s about the people and the processes involved within the organization as well.
Gamov: Learn how to love OpenAPI spec, learn the tools that allows you to generate some artifacts out of it, regardless of the language that you use, because there’s plenty of different generators available. Learn from the API that you love to use. I learned a lot before Twitter, or before GitHub was doing GraphQL API. I learned a lot from the REST API building from just looking to their APIs and how they build their API. Look at some other APIs that are available there. There’s a Wow by Owen Wilson, every time when you watch the movie with Owen Wilson, he says, “Wow.” There’s an API that can get you the particular moment in the movie. They have OpenAPI spec that allow me to play around with this API and build some of the clients in Java and start using this in my applications. Learn OpenAPI spec and learn from the best who already implement these APIs, and you like them.
Abeysinghe: I think my advice is connected to what Matt said some time back. Basically have an outside-in approach, look at it from the consumer or the application point of view, and then come to the APIs and find whether the APIs are available. Or if you have to build it, build something that is useful for the application developers. The second thing is the thing that I highlighted about the platform. Try to find the correct platform to increase your productivity, because APIs is one part of the entire digital experiences that you are building. You need integrations, you need services, and you need identities. Try to find the correct stack that provides all these capabilities, because these are the digital core components that you need to build great digital experiences.
