What is App modernization and it need for API management
Today, we'll be discussing a topic that is very popular today. And we'll have an opportunity to do a Q&A at the end of the webcast. So let me introduce myself. My name's Nagarjoon. I'm the customer engineer for cloud now technologies, which is a part of Google Cloud. So today, we'll actually be discussing a couple of items. And really it's about how organizations are actually embarking on a journey and transition from a traditionally on-premise to a hybrid IT architecture and some of those challenges that are faced in that journey itself. We'll also present how Cloudnow technologies can help de-risk, in some cases accelerate application modernization and migration by introducing an API management layer to broker transactions between legacy back-end systems and Cloud Services. So join us as we share how we can help you make that move to the cloud.
So before we get down into the details itself, interestingly enough, Google itself conducts a survey with our customers and our customers' CIOs. Some of the biggest questions are, are they currently using a multi-cloud strategy? And based on our survey, the response has been very eye-opening. Based on the survey itself, 96% of the CIOs and the customers that we actually talk to today have actually either deployed or are working on deploying or are thinking seriously about a multi-cloud strategy. And the reasons for this are a number of key points, really. It's really about empowering the organization to mix and match solutions and to be able to leverage innovative technologies from the different cloud providers themselves. Every single one of our customers has some unique requirements, which they need to then tailor their solutions based on those requirements. And additionally, it's really to increase redundancy and avoid downtime, and to ensure that their business is highly available and also scalable. And we see this a lot in our financial services customers and also our health care customers as well. So as our customers are actually embarking on this journey to the cloud, there are multiple ways of migration. It's not a single path to the cloud. And when we have a look at it, when they start with legacy on-premise, there are actually a number of options that they can take.
They can modernize on-premise, where they could start taking some of those applications that are monolith applications, whether they're commercially off-the-shelf applications or something that they've built in-house, and start breaking down into smaller microservices and taking that microservices architecture approach. When they do that, they also have the ability to, then, take those modernized applications, microservices, and whatnot and then move to the cloud. Now, not every single application can be broken down into microservices. So one of the strategies that our customers take is the lift and shift, where they take existing monolith applications and then move them into the cloud itself. Now, that doesn't necessarily bring all the advantages of the cloud, naturally. But it does reduce operational overhead. It does reduce the cost of having to procure new hardware. It does reduce the need to keep up with upgrade cycles, patching up the OS, and whatnot. So there are some advantages of just doing a lift and shift. And interestingly enough, it's never just one way which is nicer, on-prem and then moves to cloud or lift and shift and then move to the cloud and then modernize. It's usually somewhere in between, where within the same company, even within the same organization, they actually do both, where they start modernizing on-prem and also start lifting and shifting certain workloads into the cloud.
For folks that aren't familiar with Cloud now technologies, Cloud now technologies is an API management platform that provides the ability for you to create API proxies and facades, which sit in front of your back-end systems, such as cloud applications, legacy on-premise applications, commercially off-the-shelf applications that have been traditionally deployed on-premise. Now, when we create that facade through Apigee, you get a number of capabilities, such as security, analytics, and visibility into who is actually now calling into those APIs and back-end systems. You have the ability to publish those APIs to develop a portal for internal and external consumption, thereby creating an additional channel for consumption for your business. Now, the benefit of being able to do this is your applications that consume your APIs do not need to know where those APIs are actually implemented, whether they're on premise, in the cloud, application A, application B, or even versions of those same applications itself. This is very powerful as it helps our customers create an ability to then plan what they want to move and modernize into the cloud itself. So let's take a look at an example of this. Today you might start off with an on-premise data center where you have existing workloads itself. You can now leverage Google Cloud platform to either build new greenfield applications or even to even experiment, right? You can start with non-production workloads or even start looking at things like cloud bursting, where you use Google Cloud to supplement your on-premise resources.
As you get comfortable with Google Cloud Platform, we can then start doing things like lift and shit, as we saw in the previous slides, where we take those existing on-premise applications and then deploy them onto Google Cloud itself, using something like Google Compute Engine. The other strategy, which was to modernize in place, so breaking down existing applications into my core services and leveraging things like Kubernetes on-premise, where you have now created these microservices which can then be deployed into Kubernetes, which can then be scaled automatically through Kubernetes. So with those modernized microservices that have been deployed or developed on Kubernetes itself, we can then easily migrate them to Google Cloud Platform, and more specifically into Google Kubernetes Engine, GKE. So at the end of the day, all these efforts are really for the applications at the front end, consuming the APIs themselves. So where we see API management helping is sitting between the two infrastructures, whether it's on-premise or in the cloud, which then provides that facade and protects the consumers from needing to know specifically where they need to consume the APIs from.
So with that, what are some of the challenges that our customers are actually experiencing when they think about modernization and migration to the cloud itself? They think about business continuity, right? As they move applications to the cloud, they should not cause any outage or disruption to their existing customers. And this can be customers from internal and could be customers from an external point of view. They also need to consider security, because data inherently will live in multiple places and be accessed in multiple places as well. You don't want to be compromised or leave APIs open for consumption without any control or visibility, which brings us to visibility. Without an API management layer, it becomes very difficult to understand who your consumers are, be able to control which applications are actually consuming those APIs, and understand are they consuming them in a fashion that you actually want them to-- and then interoperability as well. As you lift and shift certain applications, you want to maintain applications that are traditionally more familiar with things like SOAP web services and continue to be able to offer those things up in an easy and consumable fashion itself. And lastly, you want to be able to handle unmanaged services. Traditionally, as you build out microservices or applications themselves, how do you actually understand those consumptions of those services themself? Without some sort of visibility, without some sort of API management layer, it becomes very difficult as you scale out.
So how can Cloud now technologies help? So in terms of service connectivity and helping business continuity, we can create that abstraction layer between GCP and also on-premise itself. We can create an abstraction layer between the legacy applications and modernized applications themselves. We hide the complexity of the application migration because your consumers no longer need to know where those new services or legacy services live. They can continue to consume the way that they're used to. With APIs management, you now have the ability to also enforce security consistently across all your APIs. You can also use Cloud now technologies to facilitate things like mediation between security protocols. And that's something that we'll discuss with a particular customer use case in a couple more minutes. We get great visibility. Because now our traffic is being proxied through Apigee itself, we capture every aspect of that API transaction, where the API transaction has been called from, which application, how often they're actually consuming the APIs, and what sort of performance and error rates they're actually seeing. This gives you great visibility into understanding your API program and also be able to improve, extend your API program itself. We give you API facades, where you can modernize legacy SOAP applications, turn them into new RESTful APIs, and also give you consistency across the board. And lastly, service management across all your microservices or even your traditional legacy applications, where you now have a single platform where you can enforce policies across the board, across all those different services, and then be able to manage it in a single pane of glass.
One of the solution benefits in terms of being able to leverage Apigee, in this particular use case, is that you're reducing the risk of that migration and modernization by creating an API facade. You have the ability to provide a consistent API across the board for both modernized services and legacy services itself. At the same time, you can then start leveraging innovative technologies in the cloud, so start innovating on GCP by leveraging things like GKE, AI, and now et cetera. Where those services sit shouldn't matter to the API consumers themselves or the applications. Apigee will now mediate and make sure that it is routed to the appropriate endpoints. So with that, I would like to start talking about a specific customer use case. And Sarthak was actually involved with a particular customer as he embarked on this particular journey. So with that, Sarthak, do you want to introduce the actual use case itself? Yeah, absolutely. So this is something I think I worked on maybe a year or so ago, maybe a little bit more than that at this stage when we started first working on this. So this is a retail customer who has, as you can imagine, a very standard legacy on-prem data center. And like many other customers who are looking at that stage, how can they modernize their stack? How can they be more cloud-friendly, take care of capabilities like cloud bursting and horizontal scalability and things like that? So when we first started talking to them, this is what a major portion of the stack looked like. So they had this whole huge legacy, on-prem, e-commerce software, which was a huge monolith, which had all the capabilities from the customer management system to surge to shopping cart, everything built-in. And then there were-- as part of the same solution, they had a bunch of applications like web apps, mobile apps, and whatnot, which would then consume those services on the back end via APIs. Keep in mind here, both the front end and the back end were part of the same solution suite. So this was the current stage from where we started our conversation from. And what were the challenges the customer was facing? And what were they trying to solve, I guess, from this state itself?
So I think there were two challenges. One was, I, think that's the pain point which they had for a long time, which was the front end and the back end was very tightly coupled. And so the thing was like the front end, they have a very different pace of innovation. They have a very different technology stack. There's a very different mindset of the developers who are working on an iOS app versus someone who is working on the shopping carts, e-commerce system. So there was a friction for a long time about all of that.
The front end guys, were not able to work faster, fixing bugs faster. They did not have enough flexibility. And there was a constant tension across those different teams which had been brewing for many, many years, right? But I don't think that was kind of their tipping point. Their tipping point was for various reasons. A few years back, they started-- a couple of years back, I think-- they started seriously considering cloud. And they wanted to go to the cloud because things like they want to do horizontal scalability for the peak days, like Black Fridays and whatnot, and not over provision capacity for long. So once they started looking at that, then this very tightly coupled monolithic architecture became a real problem, that I think that was as far as that tipping point that, hey, we need to do something about this architecture if we have to actually embark on this cloud journey.
So in effect, there were two parts of it, right? One was the agility and to be able to innovate quickly. And that was being Because it was based on an old architecture, it was becoming very difficult for the applications to do so. Right. And I think the second one that you mentioned was around the scalability, right? Scalability, as well as all the other benefits which cloud provides. Once they wanted to take advantage of that, then this became a problem. Scalability, the horizontal scalability, so that no more provisioning, on-demand scalability, all the other security which they get in cloud, all those things became a problem.
So how did they actually begin their journey? So one of the first things they did was they inserted Cloud now technologies in between that client and the back end. So Cloud now technologies is a facade, as Joey mentioned previously. So their idea was that we already have so those APIs. How to decouple them? Insert Apigee to create this facade, and now suddenly there is an abstraction between what the clients are consuming, the client applications are consuming, and what a back end is producing. So now what are they going to do is they can change the back end. And then inside the Apigee layer, they can transform the pillars, the security protocols, the error codes, and all those things to match what the client applications actually are looking for. So it becomes the flexibility of the agility layer, if you may, using this to decouple that front-end application where the back end is huge monolith. Awesome. And then what other things did Apigee provide? Seeing as we're now proxying the traffic between the application and the system, was analytics something that was important?
Yeah, exactly, right? So because once you insert Apigee in and once you start having all those API calls, well, the first thing they did was they looked at the Analytics. As a lot of Apigee customers do because using Analytics, they could first-- for the first time, they could see which one of the services, which of the APIs are getting called at what frequency. What can be considered as a load-time downtime to move something over? Which APIs have the most problem in terms of which is taking the most highest latency? Which has the error rates being higher? All those kinds of metrics. And based on that, they decided their whole business journey that which of those services can be migrated when. And so essentially that journey started from a deep look at Analytics. And it took many, many weeks where they created many customer reports and looked at many of the standard reports, which Apigee provides, to understand all those aspects from error rates, latency, traffic patterns. How does it vary by geography? How is it varying by different clients, like how is it varying by Android versus iOS versus web. All those things, as they looked at it, that's what helped them decide how they can migrate something to cloud. JOEY WONG: So even just by simply putting Apigee as the side layer, as the proxy between the API requests, the customer was able to get deep Analytics insight and then use that to help them plan their path to cloud.
The next step, obviously, was then to start breaking down some of those capabilities. S Yeah, and that was the whole idea, right? So what they wanted to do is they wanted to refactor this monolith. They wanted to get out of the monolith and take some of those individual services and put them in GCP, in Google Cloud Platform. So in this case, you can see that they have done that with search. But we would say that search is also on-prem because in this stage, I'm showing the scenario when they were just in the middle of transitioning, right? So they have, let's say, refactored the whole service. They're running that on GCP, a brand new service. But the latency service is still running on-prem Now they are using Apigee to first and foremost facilitate almost like a blue-green deployment, so that they route some traffic to GCP, some traffic to on prem. And then, at some stage when they're confident that their cloud service, their refactored service is good enough, that's when they migrate. Or that's where they route all those APIs calls to GCP instead of routing them on-prem. But also you can see the other beauty is now they can break out an individual service out of the monolith. And the client applications, they don't see the impact. And that's the biggest benefit.
So the client applications, the guys who are writing, who specialize in AngularJS and writing those web apps, he doesn't see all these changes happening behind the scenes. For him, those clients, this is completely transparent. Now, as they move to GCP and they build this thing in Google Kubernetes Engine, all microservices, they are writing new standards of the APIs. So everything is JSON over REST and new security standards. And then Apigee is transforming all of that to the legacy or to the-- what is the standard with the client applications expect to see? So that's the biggest advantage that as you start moving, Apigee acts as a blue-green deployment, a facilitator, if you may. And then it provides all that flexibility and basically brings together the legacy interface and the modern interface together. JOEY WONG: Awesome. So as they progress, they would then start deprecating certain things on-premise so by removing, say, search from their on-premise and then start looking, again, using things like Analytics to understand what would be a good candidate to move into cloud?
Yeah, exactly. And I mean, now, in this case, we can see that in this scenario, they had couple of services in the Cloud and some services on-prem. But the front-end applications, don't see all that movement happening behind the scenes. And the beauty is what we actually saw-- since now the front-end developers, they had more flexibility, instead of actually slowing down, they can actually went ahead and they created new apps on the front end. Because now they know that, oh, this is my API definition, and this is the API definition against which I'm building everything. And this API definition is not going to change every time some small thing changes on the back-end. Previously, that was a big challenge. If they do an upgrade of any of the services, or of that e-commerce platform, or they did anything, there was a big probability that the front-end apps will break. And that's where the front-end developers spent a lot of time to make sure when all the back-end things changes, their things did not break.
So by creating an API-first strategy, that gave the customer an ability to innovate and create new APIs and services and then be able to implement them using whatever technology they choose to. And in new apps. I mean, they were kind of stuck at having those Android and iOS apps at a pretty legacy technology for a while because they just did not have time other than firefighting, other than to comply with the back end because it is the same engine, at the end of the day, which is supporting their stores as well as their e-commerce engine. So there were requirements from all sides, which will shape that back end, which the front-end guys had no control on. They were always with their reactionary mode so that left their mobile apps and their web apps in a pretty dire state. It was pretty legacy technology. They did not have a native Android app. And there was a need for a couple of other modern applications, like for their B2B scenarios and things like that. So finally, while all this back-end mayhem, if you may, is going on, that's when they were able to roll up their sleeves and build some new applications and improve and modernize their existing applications.
All those things are cacheable. And Cloud now technologies has a very powerful caching layer with level one and level two cache built-in. Wherever that was possible, they actually used the Cloud now technologies cache, and that actually reduced their latency quite drastically. Now, in some other cases, which cannot be cached, which are real-time, for example, like your shopping cart or, let's say, recommendation, because recommendations constantly change, those things, whether there was a latency add-- yeah, maybe. But keep in mind, in those cases, we're looking at APIs which are taking a few seconds from the app to the back end to do all the stuff and go back. And then Cloud now technologies latency add was, like, a single digit in milliseconds or double-digit milliseconds, so like 20, 30 milliseconds-- in that range. And given the number of benefits, which we are getting, a 30-millisecond bump compared to a three-second was not considered much. And obviously, there are a huge set of APIs, a huge set of services for which there was a huge, huge performance bump wherever they could use the caching policy, which is built in. One other thing I might add is although it might not look obvious, as you are going through the journey, we started off with a lot of heavy APIs, which were SOAP, which was XMLA.
As we are going through the journey, the APIs were a lot lighter. We are liking lightweight microservices. So as part of the overall journey, the latency of the APIs Actually became better. became a lot better than what it was previously. And then I can imagine as well with the caching, that's an interesting use case because now if you're returning a response from the cache closer to the application that's consuming the APIs, you could potentially be servicing more transactions because you're not necessarily hitting the back-end system. So yeah, that's actually a great point. So one of the challenges they had was-- so the back end, when the e-commerce engine was built and that whole infrastructure was built, that was built thinking of the world with a browser-first approach, web word. Which was like, oh, this can have, let's say, whatever, x number of calls simultaneously, 10x number of calls a day, or whatnot. They did not think inherently about the mobile-first approach and the scale which mobile brings in. And they had severe problems with a lot of outages at various different times, slow performance, and things like that, especially during peak hours. They had all of that. So as they were able to cache in Cloud now technologies using the L1 and L2 layer, a lot of those performance worries, at least for some of those services like shopping-- sorry, like product catalogs and all, those were drastically reduced. Yeah, I can imagine in today's world even with Google Assistant, at Google Homes, yeah, that's another avenue, another channel that's flowing up. Exactly. No one thought of those avenues five years back.Yeah. So in this particular diagram in the final state, there's an interesting thing here where you actually-- the customers actually operating in both Google Cloud and in their own traditional data center. so what happened is, at the end of the day, they decided that they will migrat and rewrite and whatnot most of the applications in the cloud, but they were not going to rewrite shopping cart. Shopping cart, they are going to maintain in the existing e-commerce solution on-prem because it is a very complex piece of software. And they did not see any business value by rewriting it.
So as they were migrating-- and we talked about in the previous slides-- Cloud now technologies was the layer behind which they migrated. But not only that, Cloud now technologies was the layer that created the hybrid and the final state, when-- so their final steady-state will be they have their shopping cart application on prem and they have all the other applications as microservices and whatnot in GCP. And then Cloud now technologies sits in front, which then routes traffic to either GCP or to the shopping cart based on different logics put inside Apigee. So this is actually Cloud now technologies helping in creating a hybrid state, built-in on prem and Cloud, using an API-first approach. So normally when you think of hybrid, customers start thinking in terms of, oh, I need to do-- I need to set up a VPN. I need to set up a VPC. I need to set up an interconnect and all of that kinds of things to do hybrid. Yes, that would be true in some scenarios. In other scenarios, if you do an API-first paradigm, if you do an API-first design for applications, you can do it at a hybrid like this. And this is something we actually see customers do quite often, not only just in one scenario. We have many, many customers who are doing this kind of hybrid deployment.
All right, so we're just going to wait a couple more minutes as the questions come flowing through. I can already see a couple-- everybody comes through. So just give me a minute. OK, so we have a question here. In this particular case, is Cloud now technologies running on GCP or on-premise for this particular customer? In this one, it was actually running on GCP, and we are managing it as a service for our customers themselves. Naturally, Cloud now technologies is also available as on-premise deployment so that you can actually choose to deploy it into your own data center or into your own private cloud as well. We have another question. How do you see and suggest to users of Cloud now technologies in a multi-cloud environment? So I'm going to try and interpret this one a little bit. So I guess the question is, how would you deploy Cloud now technologies in a multi-cloud environment? Again, you can either choose to use Cloud now technologies as a service where Cloud now technologies Google would actually then provision you an instance, and then we would then manage and operate that instance for you. Now, you also have the ability to then also choose to use the on-premise deployment to deploy into your own data center or into your own private cloud and then have that manage your API calls and mediate and broker it between the two environments or multiple environments itself. The questions are flowing in very fast, so hopefully, I can get through a lot of them. So will this be available post-event? Yes, it will be. We will follow up with some emails around that itself. So we do have some repeat questions. So another one here is where is the API manager sitting when we use Cloud and on-premise? I believe that's been answered. In this particular case, we are hosting the API platform itself. So we have another question here. And the question here is, customer database seems to be a common hybrid component but complicated with firewall issues in data residency. How have you solved this? So it's a number of factors. So some of those things might be an issue with moving to the Cloud. So they might actually have to sit on-premise. So if you recall back into the actual presentation itself, our customer actually left one of their components in the data center, which was a shopping cart, which is actually handling the credit card payments themselves. Now, with a customer database, that can also be the same case where the database itself would need to live on-premise. But you would expose an API that we would then manage as part of the API management platform in Cloud now technologies to then provide security and control over who uses that particular API itself.
We have another question here. How do you secure the connection between the on-premise applications and Cloud now technologies? So if you're using our managed services itself, we have two options, and some customers choose to use one or the other, or some customers use both. And typically, what they do is they use IP whitelisting where we can provide you a range of IPs. And they also use neutral TLS where the certificates are provisioned to ensure that only Apigee gateways could talk to your data centers themselves. We have another question. For Google Cloud, does Cloud now technologies provide adaptive hooking into Google Kubernetes Engine? So I don't believe we have specific adapters for GKE today. But we have actually something called Extensions, which has now started being leveraged to connect to GCP services. So things like Pub/Sub, BigQuery, AIML are becoming extensions that are becoming available. And as we create more of these extensions and connectors, our cloud customers can then leverage them to further integrate with and extend their applications using GCP. OK, we do have another question.
Can we do monetization using Cloud now technologies? Yes, we can. Monetization is a module that sits as part of the platform. So we do have customers that are leveraging monetization today to be able to open up a new digital revenue channel and then leverage that capability itself to do things like reporting all the way up to actually charging the customers that actually want to leverage their APIs. Can you talk about the internal usage of Apigee between internal applications and/or services? Great question. So internal usage and external usage are different. But at the same time, it is actually quite similar in that developers, whether they're internal or external, want to have similar sort of experiences between-- in actually accessing API. So if you have a look at what's available out in the market today, there's always a developer.company.com where APIs are published for people to discover and understand and subsequently also be able to test with those APIs immediately. They also want to be able to do things like self-service where they can request full access to the APIs and have it automatically generate you an API key for, say, a sandbox environment itself. Is there an Cloud now technologies certification program? If you head over to our Documentation page, we do have the on-premise documentation, which talks about setting up Apigee on-premise. In this particular case, it was a cloud-managed service. And it becomes more of a configuration rather than a complete set up itself. Do we have integration with Kubernetes and Istio? Great question. So for folks that don't know, Kubernetes is an orchestration engine. And recently, there was a new project that has come out called Istio. Istio is what we call a service mesh tool, which helps you manage your microservices within something like the Kubernetes infrastructure.
Now, Cloud now technologies itself has integration with Istio where, as you can imagine, you have tons of these microservices within your Kubernetes infrastructure. But you also want to be able to then manage some of these services as APIs. So as part of the Istio expansion capabilities, we have built an adaptor between Istio and Apigee where you can take some of those microservices and actually manage them through the management platform within Cloud now technologies itself. For more details, just do a-- go to our Cloud now technologies Documentation site. And there is an Istio section specific to that as well. How to monetize products? So Cloud now technologies is a complete API management platform, and as part of that, we do have a monetization module. So you can actually create what we call different rate plans against different API products. These products can then be something that you make publicly available or you push towards specific consumers. They can be defined as simple as a bucket where a consumer would need to pay a monthly charge. Or you can come up with more exotic sort of plans where perhaps it's tiered, where the first tier they would pay x amount. And then once they exceeded an amount of calls, they would then be charged less or more, depending on what type of model that you're trying to do.
The question is this specific to just retail organizations, or is this something you are seeing across all industries and verticals? That is a great question, and it is across all industries and verticals. Retail is something that we see a lot happening. But naturally, across financial and health services as well, they are getting more and more comfortable with cloud. And therefore, they're actually starting to leverage Cloud now technologies as the platform to help them move and modernize into the cloud. And before-- just something else I was told to actually push-- I kind of forgot-- is as part of today's webcast, we are actually selecting three webcast attendees and actually giving them NEXT passes. So NEXT is Google Cloud's annual three-day conference. It's going to be hosted in San Francisco and takes place from April the 9th to the 11th this year. So our team itself will be contacting three of our lucky winners by early next week and giving them the passes. So keep an eye out on your emails itself. How does this help in traffic management? So Cloud now technologies, as a complete API management platform, has a number of policies that actually help you with traffic management. So things like quota are available and also where you can actually define things like x number of calls per month, per day, per minute. It's up to you what you want to define. We also do have things like SpikeArrest, which helps you smooth out your traffic. So think of it as a way to prevent DDoS calls into your platform. We also have things that can actually improve performance.
So things like caching are available as part of the policies to actually allow you to define what your keys are. And then if a request comes in with the same request, same key, Apigee itself can serve the traffic out into-- back into the API consumer itself, thereby avoiding having to go all the way back up to the back-end system to retrieve. Do you normally need a service mesh like Istio if your microservices are on PCF? No. So Istio is a new way of managing microservices in a mesh. We have a ton of customers that have built microservices on PCF. And actually, PCF, or Pivotal, is a partner of ours. And we have built integrations between our platforms to ensure that, as you're building out microservices and deploying them onto PCF, you can also leverage Apigee to provision what we call a micro gateway or even use their full-blown edge proxy to secure those microservices itself. Check out our Documentation page for more details. All right, so we do have a question here. Do we have Qwiklabs to try out some concepts and labs on Istio, GKE, and more? We actually run these API Jams quite often. So keep your eye out on the Events page for the next API Jam, which also can include these components as well. From there, you can actually play with it for free.
Can Cloud now technologies help in versioning off the API?
Absolutely. So there are different ways of versioning APIs. The one that we see most common is actually through putting the V1 or V2 in the URL, or URI, I should say. And that gives you the ability to, again, deploy multiple versions of the same API as well.
Do you have customers moving to a service mesh? So we certainly have customers that are leveraging things like Kubernetes. And then naturally, they're looking at Istio as well. There is a smaller subset of our customers that are using Istio in production. But they are somewhat more limited because at the rate-- at the current stage, Istio is fairly new. But what every one of our customers is doing, especially if they're Kubernetes adopters, is they're actually now experimenting and making sure that they are keeping in sync with what's happening with Istio, what's happening with Istio and Apigee, and service meshes in general. I think we are going to be coming up to the end of this session itself. So with that, I would like to thank you all for attending today's event. We will answer your questions in the chat channel. But let me just promote our next event itself. So we run these events bi-monthly. So our next event is going to be around understanding how developers are today kingmakers.
And we have from Cloud now technologies who will be delivering the devops services in usa on how this trend is not only growing but how to actually create an ecosystem around your developers with an API-centric mindset, thereby encouraging more and more of your developers to actually leverage the power of APIs itself. And then lastly, if you are not a current Cloud now technologies customer, or if you're just exploring the market itself, please feel free to actually sign up for a free trial on our platform. We offer a ton of documentation. We offer a ton of our videos as well on YouTube for you to be able to understand how you can actually leverage Cloud now technologies to manage your API program itself. And then with that, thank you very much, and have a good day.Cloudnow technologies is one of the leading cloud devops consulting services in USA. In the recent survey cloudnow technologies ranked as top devops services company in usa.
