devopsy.kinsta.cloud

Tag: APIs

  • Sometimes, You Should Fix What Isn’t Broken

    Sometimes, You Should Fix What Isn’t Broken

    DevOps has been with us long enough now that there is a lot of legacy DevOps stuff running in all of the places I have eyes into. Ignoring items that are not actually working; those pieces that pose a serious security threat because they house vulnerabilities that have been fixed—there is a lot of “It just works,” piping in place and even a bit of “We’ve always done it that way.”

    Considering DevOps is still often pushed as “the inevitable new hotness” by marketers, I find this interesting; the fact that DevOps is now the de facto standard across enterprises is a topic for another day. I want to talk about the stuff running quietly, relieving you of the need or desire to think about it while focusing on issues that do need you to think about them.

    But that type of thing is exactly what created the need for DevOps in the first place. DevOps came in like a wrecking ball and forced you to look at the unnecessary steps that had built up around the items in the organization/culture/infrastructure, often around these very “This is just how we do it,” or “That ain’t broke, let’s look at this other thing, instead,” attitudes.

    At Ingrained Tech, we have scripts that run our backups to the cloud. They are part of a fully automated process; we designed them to make sure our system of what gets backed up and when highly adaptable. The system runs like a champ every night unless we tell it not to.

    Our cloud storage provider has come a long way since we first used their API to get the data up there and wrote those scripts. In fact, customers like us are the reason the provider keeps backward compatibility with those APIs. Which means it is time for us to revisit, use the newest APIs and see which of the many, many new features we want to take advantage of. “Good enough” is just that. The system isn’t broken—we get viable backups out of it (which we needed not too many months ago, so we know we get good backups), but we’re not getting maximum value out of it; we had to do a bit of hoop-jumping to get the data set back up the way we wanted.

    Our simple backup routines are nothing compared to similar “good enough” arrangements I’ve seen in larger companies. “Good enough” arrangements that are creating larger and larger speed bumps that sometimes resemble the exact environment that made the huge gains of early DevOps implementations inevitable.

    Take a look at your infrastructure and toolchains with a critical eye. Look for low-hanging fruit, and knock out some of the baggage that has built up. Schedule some process renewal days, where a team member or two specifically looks at everything in the environment with a critical eye, and see what they propose.

    And keep rocking it. Speed bumps or not, you’re making the apps and infrastructure that keeps the entire company running. Remember that, and keep a smile on your face while you’re solving recurring problems.

     

  • Survey Finds Widespread Adoption of DevOps in Mainframe Sites

    Survey Finds Widespread Adoption of DevOps in Mainframe Sites

    A survey of IT leaders by the market research firm Global Surveyz found a full 100% of respondents are modernizing their mainframe applications, but the reasons behind and approaches to achieving that goal vary widely.

    The research was conducted on behalf of Model9, a provider of tools for migrating mainframe data, and polled 100 companies that have more than 1,500 employees or more and use mainframes. Nearly three-quarters of respondents (73%) are embracing DevOps best practices to manage mainframe infrastructure, with 61% modernizing their mainframe applications. Just under half (46%) also noted they were outsourcing the management of those operations.

    However, the survey also found that unlocking the business value of stored data and accelerating innovation are among the top 2022 objectives for 42% and 36% of respondents, respectively. Data protection (89%), cybersecurity and resilience (76%) and cost optimization (52%) are the top priorities.

    Tamar Milstein, chief marketing officer for Model9, said that the continued focus on block-and-tackle mainframe management issues suggests there may be a disconnect between IT teams managing these platforms and senior business executives that are looking to drive digital business transformation initiatives.

    Nevertheless, a full 91% of respondents said the mainframe still holds the most critical applications for their business, with 62% reporting more than half of their core business applications on these platforms. The use of cloud computing platforms alongside mainframes is also widespread. A total of 61% have a hybrid multi-cloud computing environment already in place. Only slightly over one-third (35%) are using a single cloud to augment their mainframe. Nearly half (48%) are replicating data to the cloud. However, just over half (51%) are storing more than 50% of their data off the cloud.

    Model9 is making a case for modernizing these environments by making it easier for mainframe applications to access data stored on less expensive platforms to house data. That approach provides all the benefits of the cloud without having to incur the risks and costs of attempting to migrate an entire mainframe application to the cloud, said Milstein.

    Regardless of the approach organizations take toward application modernization, the survey made it apparent just how widespread the adoption of DevOps best practices in mainframe environments is. Many of those organizations are using DevOps practices to add application programming interfaces (APIs) to legacy mainframe applications to make the data residing in those applications more accessible. That approach reduces the technical debt that organizations might otherwise incur as they build and deploy applications on other platforms that might provide similar capabilities to an existing mainframe application.

    While there are plenty of organizations that have migrated away from mainframes, there remains a large base of IT teams still running applications on these platforms. Achieving the same level of transaction processing capabilities enabled by a mainframe in a cloud computing environment isn’t yet feasible. There are, of course, organizations that decided they would no longer like to operate a data center at all, but there’s still a substantial number of organizations that will continue to operate mainframes well into the rest of this century.

  • Graph CDN for GraphQL APIs

    Graph CDN for GraphQL APIs

    Alan Shimel talks with Max Stoiber from GraphCDN, the CDN for GraphQL APIs. GraphCDN is now available to everyone with edge caching, query analytics, error tracking and protection from malicious queries for your GraphQL APIs. A video is below followed by a transcript of the conversation.

    Announcer: This is Digital Anarchist.

    Alan Shimel: Hey, everyone. Thanks for joining us on another Tech Strong TV segment. My guest for this segment is Max Stoiber—and if I mispronounced that, Max, I apologize. I did my best, but why don’t you say it correctly?

    Max Stoiber: Stoiber, but it doesn’t really matter. I’m really excited to be here—thank you for having me.

    Shimel: Oh, it’s our pleasure to have you on. But you know what, it does matter—names matter, right? My mom taught me that and somewhere, your mom or dad or both, their name and—they deserve to have it pronounced right, as well.

    But anyway, Max, thanks for joining us. Maybe more important than your name is the name of your company, so why don’t you start off with sharing that with our audience?

    Stoiber: Absolutely. So, I am the Co-founder of GraphCDN, which we just recently announced is now publicly available for everybody. And so, that’s sort of the reason I’m here is to tell you a little bit about that journey and how we got here.

    Shimel: Absolutely. So, GraphCDN—I mean, we’ve seen so much news coming out of kinda graph databases and graph data, and it really gives us a new way of looking at, I guess it’s part of nature, right? Things get more complex and bigger as we go on, and so you need new technologies to help you get your arms wrapped around it. And certainly, graph technology is a real up and comer, if you will, in terms of helping us wrap our heads around stuff like this.

    So, you know, why don’t we start with a little bit of background? Like, what does the company do, what’s the problem you’re solving—that kind of thing.

    Stoiber: Absolutely. So, GraphCDN is a GraphQL CDN. And GraphQL is a technology, in case you’re not familiar with it, that was invented by Facebook back in, I want to say 2014, maybe ’15. It’s been a while. And they use it—it’s basically like an API framework that lets people build very strongly typed APIs to communicate between their servers and their clients. And Facebook invented that, and open sourced it. And a lot of other companies started adopting it, because it feels very nice to use for developers.

    And so, we provide, similar to how other CDNs provide features for websites to make them faster, more secure, think, like, Fastly cloud there, we do the same thing for GraphQL APIs. And we do that for everybody, not just Facebook who has technology like this internally, of course, we do it for all the other companies that aren’t Facebook and don’t really have the time to build all this technology themselves.

    And we came to that whole thing because when we built our last status, me and my Co-founder Tim, we were using GraphQL and we had huge scaling problems. We were growing like mad, but we couldn’t just cache our GraphQL API, for example, because none of the existing CDNs support GraphQL. They can’t cache any of the data that goes through it.

    And so, we struggled with this and we built terrible solutions internally at our past companies, trying to solve this as best as we can. And then now, we got together and we said, “Hey, we just gotta solve this,” right? It’s almost, excuse my language, stupid that nobody’s done this, because it’s such a clear need.

    And so, we sat down, and it turns out it’s quite hard to solve, which is why it took us a while, but we finally got there and now we’ve got GraphCDN, and it does a lot of things for people that have GraphQL APIs. That’s sort of the broad strokes overview, I would say.

    Shimel: Absolutely. Max, you know what, you mentioned a little bit here and there, but let’s talk about your background and your history.

    Stoiber: Absolutely. So, I am, I would say, most widely known in the engineering community for having invented a bunch of open source projects, particularly in the front-end web development space. About 1 to 1.5 percent of all websites on the planet are powered by technologies that I invented, mainly by styled-components, which is one of the biggest ones.

    And so, I’ve sort of amassed a large following of engineers and designers and other tech people following me for my open source work. And then, I’ve previously co-founded a startup with two friends from California where we were building sort of a modern forum, in a way, sort of a mixture between WhatsApp and traditional, you know, the forums of the past where we used to hang out and have friends.

    That was then acquired by GitHub, and turned into GitHub Discussions so that the engineers on GitHub can then sort of hang out. And then I had a stint at GatsbyJS, another startup, that was building a JavaScript framework, or is still building a JavaScript framework, and I left that at the beginning of this year to focus on GraphCDN and really build that out with Tim. And sort of, that’s my background.

    Shimel: Very cool, and congratulations. Very, very impressive.

    Stoiber: Thank you.

    Shimel: Thank you. You know, look, I’ve worked with enough engineers and software developers to know that nothing is ever truly done, right? There’s always more we could do, right? Why GA now, why kind of emerge from Stealth, if you will—you know, why now?

    Stoiber: That’s a great question. It’s funny, because we debated this for a long time internally, because we felt like we were GA ready two or three months ago, right? We sort of had the basic set of features where we thought we could cover common needs, almost all of the common needs that we wanted to cover. We were ready or people, but also, GraphCDN, because it is a CDN, is critical infrastructure. If we’re down, our customers are down. And we take that responsibility incredibly seriously.

    Now, we’re based on Fastly’s edge computing technology. So, the infrastructure underlying GraphCDN is actually very solid. But we wanted to make sure that our part of that infrastructure was as solid as it could be. And so, we gradually on boarded early access customers, including the biggest rugby site in Australia and a bunch of others, to make sure that our infrastructure could really handle the load. And after we proved that out for the last two, three months, we said, “Okay, we are confident in our systems, we’ve found all the bugs we’ll find before with GA.” Of course, you can never find all of them. That would be—I think any engineer that says that is lying. But we found most of them, the ones that really mattered, and then we said, “Okay, it’s good enough, let’s have people sign up and really get this into people’s hands.”

    Shimel: Excellent. And let’s talk about the model for the company. I mean, with your open source background, I’m gonna assume, is there an open source graph?

    Stoiber: There actually isn’t.

    Shimel: No?

    Stoiber: The open source part of it is the GraphQL part, the framework that Facebook open sourced. But our infrastructure is fully proprietary. There’s actually—there’s sort of two schools of thought, right? You have companies like Sentry doing all of their core work in the open source and then providing hosting or other services on top. And I think that model can work quite well, but for us, because we’re critical infrastructure, we knew that we needed to be in people’s critical path and we knew we needed to be reliable, and that just takes a team, right? There’s no way that you can just run this on the side, you know, have it running in the background and not worry about it. It needs to be maintained. Somebody needs to sit there 24/7 on call and pay attention that this thing keeps running, just to make sure nothing goes wrong.

    And so, open source just didn’t feel like the right fit for that, because honestly, we’re gonna sit there 24/7 and make sure that our infrastructure stays up and doesn’t have any down time. And so, we did not go open source and instead have—we have a very generous fee plan, but beyond that, believe it or not, people pay us for the thing we provide. Which, of course, sounds ridiculous, because that’s what businesses do, but as an open source developer, that’s actually less natural to me than you might think. But it feels very nice, I have to say. We’re very appreciative of our customers for helping them scale and secure their GraphQL APIs. And so far, over the past months that we’ve had customers, everybody has been very happy that they have us and that’s very gratifying to see from our side, of course.

    Shimel: Agreed, agreed. When you say GA, I’m assuming GA, people can go buy and use this right now.

    Stoiber: Correct. Absolutely.

    Shimel: But is there a free trial, is there—

    Stoiber: Yes.

    Shimel: You know, because you know how software is consumed today, right? You gotta get it in people’s hands and deliver delight, right?

    Stoiber: Absolutely.

    Shimel: And if it’s good and they like it, they buy it.

    Stoiber: Absolutely. That’s the exact model we follow. We have a very, I would say, generous free plan. You can use us for free for up to, I think, 5,000,000 requests per month, which covers a lot of early stage startups, we’ve realized, maybe even more than we would’ve liked. It’s definitely a very generous free plan, is what we’ve learned, which is a good thing, because we wanna provide that value, particularly to those growing companies. And then eventually, when they hit the scale where they have more than 5,000,000 requests, it starts costing $10.00 per 1,000,000 requests. And so, it’s sort of, the pricing scales with your usage.

    In theory, you can throw as many requests as you want at us, since we’re based on Fastly and they handle a lot of traffic, I’m not very worried about not being able to handle scale. And we have—it was actually funny, after we GA’d and we announced that this is now available to everybody, of course, people signed up and then suddenly started deploying this thing to production and our traffic just 10X’d overnight, and we didn’t even notice. Like, we just looked at our graph, like, we woke up the next morning, we looked at our graphs, at our internal dashboards and we realized, “Hey, a site just enabled us overnight and 10X’d our traffic, and we didn’t even realize,” right? And they’re just—they were just like, “Yeah, this works, we’ll use it—perfectly fine.” And that just kind of keeps happening and it’s very, very interesting to see. I love it, I have to say.

    Shimel: You know, that’s one of the—so, I’ve been in the Internet business since ’96, ’95, and that truly is one of the remarkable things about the Internet is yeah, people, you know, if you put your shop out there, you put yourself out there, people come by. And they could be from anywhere, whether they’re from Australia, Japan, Korea, you know, Amsterdam, London, or next door, it makes no difference, they’re on the Internet. And all of a sudden—boom, you know, it lights up and it’s like, “My goodness, you know? We were hoping for this, but who”—you know, you never know. That’s fantastic.

    So, what are plans going forward? Have you guys announced fundraising, is that in the works, or—you know, where’s the continuing journey, here?

    Stoiber: We raised a round of funding a couple months ago from some well-known industry people, mostly friends of ours, like Guillaume ________, the CEO of Versel; Tom Preston-Warner, one of the Founders of GitHub; Jason Warner, the current CTO of GitHub. A bunch of friends that we knew from the industry that we also knew loved GraphQL and that they knew what it was about and they immediately got what we were working on.

    And so, we raised enough funding to sustain us for a couple years, and now we’re gonna use that funding to build a small team to help us maintain this, because right now, it’s just me and Tim—or has been just me and Tim for the past months, and now we’re starting to hire and on board the first people to help us really take this to the next level. Because it’s a lot of work, it turns out. [Laughter]

    Shimel: Yeah, I know, yeah.

    Stoiber: Building a great product is a lot of work.

    Shimel: Well, you know what they say, Max, if it was easy, everyone would do it.

    Stoiber: Exactly right. [Laughter] Absolutely.

    Shimel: But it’s fun work, right? There are people who really work for a living versus people who love what they do.

    Stoiber: Yeah, absolutely.

    Shimel: You know what we didn’t do, though, Max, we never gave anyone, like, the URL, where could they get more information, where can they download it? Where can they go?

    Stoiber: The URL and the home page is at GraphCDN.io, and it just has—as any website, it has a massive sign up button that you can click, and then you’ll be redirected to GitHub and you can sign up and just try it out. You don’t even need a GraphQL API, we have this sort of flow where we’ll give you a demographical API, just so you can get a feel for what it does and how it works. So, yeah, go to GraphCDN.io and try it out.

    Shimel: That sounds like a plan. Hey, man, you gotta come back and keep us posted of progress here, okay?

    Stoiber: I will absolutely do that. Thank you so much for having me.

    Shimel: Oh, it’s our pleasure. Max Stoiber, Co-founder, GraphCDN, it’s at GraphCDN.io—right, Max?

    Stoiber: That’s it. That’s the one.

    Shimel: Yeah. Go check it out. Seems pretty cool. This is Alan Shimel for Tech Strong TV, we’re gonna take a break and we’ll be right back with our next guest.

    [End of Audio]

  • Kong Enterprise 2.7 Simplifies API Management

    Kong Enterprise 2.7 Simplifies API Management

    Kong Inc. this week advanced its service connectivity platform strategy with an update to Kong Enterprise that makes it simpler to collectively manage groups of application programming interfaces (APIs).

    Michael Heap, director of developer experience for Kong, Inc., said that capability will make it simpler to, for example, assign rate limits to different tiers of APIs.

    In addition, Kong Enterprise version 2.7 adds support for real-time and event-based use cases involving the open source Kafka streaming platform and webhooks. Usage of event-driven architectures is rising as more organizations embrace digital business transformation initiatives that require near-real-time processing versus relying on traditional batch-oriented applications, noted Heap.

    Finally, IT teams can now also securely store secrets such as user names/passwords, API tokens, database credentials and private keys that might be used to access Kong Gateway. An improved user interface for Kong Manager UI makes it simpler to configure the Kong OpenID Connect (OIDC) Plugin for the Kong Gateway.

    Overall, Heap said, the latest update also provides 25% increased throughput and improved latency. In tests run by GigaOM, a third-party research firm, Kong Enterprise 2.7 achieved 52,250 transactions per second (TPS) maximum throughput with a 100% success rate.

    Kong is making a case for a service connectivity platform that enables an IT team to manage APIs at a higher level of abstraction by integrating all Layer 4 through Layer 7 services for both monolithic and microservices-based applications. Rather than having to manage an array of networking services and associated services in isolated silos, that layer of abstraction makes it simpler to manage distributed applications that have dependencies on a wide range of APIs.

    In general, the number of APIs that organizations are using both internally and externally has expanded tremendously over the last several years. The challenge now is finding a way to not only manage and secure all those APIs but also retire them as new services come online. Many APIs are created and simply forgotten about because their developer neglected to inform IT operations of their existence. Those so-called “zombie APIs” then become a cybersecurity liability when cybercriminals discover they can surreptitiously exfiltrate data via those APIs.

    APIs are, of course, an integral element of any software supply chain. But as high-profile security breaches put software supply chain security in the spotlight, it’s only a matter of time before IT teams look for more efficient ways to manage and secure APIs at scale.

    Inevitably, that also means organizations will need to decide how much they want to rely on proxy software, API gateways and service meshes to achieve that goal within the context of a larger service connectivity platform.

    In the meantime, the days when APIs were managed in isolation from the rest of the IT organization are coming to an end. The only thing left to determine is how involved API developers need to be in their ongoing life cycle management.

  • Techstrong Research DevOps Radar Report 2022

    Techstrong Research DevOps Radar Report 2022

    You can’t control the pace of change; instead, consider that we are in a process of reinvention—both with regard to the way organizations use technology and how vendors position their offerings. At the same time, it’s never been more important for IT organizations to have complete visibility into the way technology is used from both a security and operations perspective. 

    This need to embrace reinvention while continuing to have broad and deep insight across all technology platforms led me to create a 2022 DevOps Radar Report. In this article, I highlight three near-term priorities that must be on every technology team’s radar. In addition, I’ll point out some long-range radar trends that should be on your agenda.

    Collision Warning! Your Current Radar View

    API Security

    APIs are the lifeblood of the cloud-native and app-based economies. Increasingly, poor API security across a variety of applications and systems puts your organization at risk. A compromised API or the use of unsupported or outdated APIs can prove to be an easy attack vector for cybercriminals. In addition, API vulnerabilities are calling into question how organizations approach application security and the usefulness of web application firewalls (WAF) and encryption protocols. Therefore, API security is rapidly becoming a top security priority for enterprise security teams and software professionals. 

    Failing to adequately manage the security of APIs creates a host of new challenges and questions that you must consider. For example, who is using which APIs? Are your APIs updated? Did your DevOps team evaluate the security of your APIs during their selection process? Have you formalized the way your organization is evaluating API security?

    It is increasingly clear that an API breach can lead to the downfall of your entire digital software strategy—but it doesn’t have to be this way.

    At Techstrong Research, we segment the market into “pure-play” API security vendors and larger security vendors with specific API security offerings. Our team will be publishing a Market Vista report on the API security landscape soon, so if you want to share your opinion or thoughts, please reach out.

    Below is a brief list of some of the vendors we are tracking in the API security market. Of course, expect consolidation—some of these pure-play vendors will likely be acquired in 2022.

    Pure-play API security vendors we’re tracking include:

    General security vendors with API security offerings that we’re tracking:

    Observability is Evolving to AIOps

    Modern applications are composed of containers and APIs that your organization can’t control, and into which visibility is difficult. Monitoring and application performance management (APM) solutions aren’t new; for many years log vendors built their businesses on collecting log files and sending alerts … so what’s changed?

    First, logs without context are meaningless. You need to understand upstream and downstream dependencies. Additionally, speaking for myself, I’m a mere mortal—if your teams are also made up of mere mortals, there is no way they can ingest, correlate and understand the tsunami of incoming DevOps log data quickly enough to take proactive measures.

    Besides the need to understand context, we are dealing with multiple cloud and on-premises platforms that each have their own logging protocols. Ultimately, the goal of observability and AIOps is to understand what’s happening across and among all these environments and technologies so you can detect and resolve issues as quickly as possible to keep your systems efficient and reliable and your customers happy. 

    Humans are the Biggest Security Vulnerability

    As an industry analyst, I see our clients pouring resources into cybersecurity efforts to prevent zero-day attacks and sophisticated advanced persistent threats (APTs). These threats, while real enough, are mostly external and may not pose as great a threat as many organizations believe. In fact, the vast majority of security vulnerabilities are caused by:

    • Well-meaning employees making innocent mistakes, including:
      • Falling victim to phishing attacks
      • Poor corporate password policies
      • Cloud misconfigurations and open ports
    • Technical debt—relying on older software and hardware that was never designed for a 100% mobile workforce, for example

    The first step in combating this problem is improving security awareness and building a cybersecurity culture. That starts with everyone in your organization understanding that security is a team sport and that it is a 24/7/365 responsibility. Even if you work from home; even when you’re cooking dinner while checking email on your phone, you need to have your “corporate security/Is it safe?” hat on.

    At the same time, machine learning, AI and automation have a role to play. There are emerging offerings that help enforce DevSecOps best practices and help security teams reduce the constant noise so they can focus on the most vital threats.

    Longview Radar: Plan Your Strategy Now

    To support emerging business models, what do DevOps leadership teams need to be thinking about from a long-term perspective?

    • Web3/Web 3.0 and the potential for change to the internet business model. But there is still a ton of opportunity with Web 2.0.
    • How will you support low-code/no-code? As a business model, vendors are selling directly to business units—it’s likely that your IT team has an existing solution to solve the business pain point(s).
    • Packaged software offerings that include blockchain, NFTs and other digital ledger technologies.
    • How to upskill teams, both from a technical perspective and a business perspective.
    • Providing developer teams with the tools they need while establishing guardrails to enforce governance and compliance requirements.
    • How to manage cloud costs in a predictable way no matter how many cloud vendors your organization uses.

    Conclusion: You Can’t Put the Brakes on Change

    Attempting to control change and the speed of reinvention is futile. You need to get comfortable riding the waves of industry change, or you’ll be swept away! Every IT leader needs to learn how to roll with and manage the ebb and flow of business, IT and personnel change.

    The best place to start is by building a successful culture within your organization. Although we often talk about technology-focused solutions to business problems, the first step on this journey doesn’t involve tech at all; it involves helping IT and business teams understand each other’s pain points and learn how they can each support a continual reinvention process.

    I will be tracking these incoming radar targets and other associated trends throughout the year and I look forward to your input. Do you think I missed something? Have a question or want to share what your organization is doing to support the need for continual reinvention? 

    Feel free to engage with me – @DDKirsch, LinkedIn or, of course, email. 

  • Front-End Frameworks Enable Better Dev Collaboration

    Front-End Frameworks Enable Better Dev Collaboration

    The general public often thinks about software development in terms of a lone software developer hacking away tirelessly at their keyboard. Of course, that is an anachronism, at best. What is true is that collaboration among software engineers, especially with their colleagues in IT operations which evolved into DevOps, has become the norm for rolling out better code faster.

    We are on the cusp of the next big evolution as software development becomes more of a ‘team sport’ than ever before. Now, collaboration is extending beyond IT (developers and operations) to cross-functional areas across various business teams. Product development, marketing and others also are providing input and feedback into the software development process and, most significantly, becoming part of the process.

    Front-End Frameworks are Driving Collaboration

    Historically, software programming, including front-end programming, happened in local IDEs. However, the rise of modern front-end web frameworks has led to an entire class of developer tools that speed up the build process and allow applications to be deployed more quickly.

    There are a number of front-end frameworks that do this: Netlify, Vercel and Appsmith, an open source internal app builder, are three examples. These tools are getting widespread adoption, because, in a world where front ends are becoming more complex, they make things like hosting, deployment, authentication and serverless functions much simpler. The other reason for adoption is also because many of these tools are built on top of popular open source frameworks such as React, which already has a vast user base.

    This is enabling a new kind of collaboration that is unlocking a lot of value for all the stakeholders involved. Inspired by how Figma reshaped the design process by allowing real-time commenting back in 2016 or how Google’s suite allowed real-time editing, there is a similar phenomenon taking place over the last year in software engineering.

    Visual, Real-Time and On the App

    The most obviously striking feature is that collaboration is happening on the app (or the app prototype) and is becoming increasingly visual. Writing or editing code in the command line is great, but it doesn’t necessarily help the developer to visualize what is happening. Vercel’s Next.js Live, for example, allows teams to chat, draw and edit.

    collaboration

    This also means that collaboration is happening on the app instead of through tools like email, Slack and Jira, leading to targeted feedback without having to toggle between multiple tools.

    Collaboration and Feedback Loops Become More Inclusive

    While developers often collaborate at the code level, non-developers’ feedback is often given at the design level. This is more often the case for internal tools (or apps), which typically account for anywhere from 20% to 40% of engineering bandwidth in organizations.

    For example, Appsmith today has thousands of developers self-hosting and deploying internal applications for users who are often business or operational teams like support, sales and/or finance, for example. Often, these business users don’t even know who has built the application. Real-time commenting via front-end frameworks facilitates collaboration between software engineering teams and their business counterparts who can now communicate directly, provide feedback and collaborate with their engineering peers. This close collaboration empowers all parties, increases efficiency and saves significant time while improving the overall quality of the software and ensuring that it meets expectations.

    AppSmith

    In addition, non-engineers don’t need to familiarize themselves with a new tool like GitHub or go through a painful replication issue on Jira involving a variety of screenshots or screen recordings. Sharing feedback can be done much more easily.

    Better Version Control and Feedback

    For developers, having the ability to visualize a particular branch of an application and give detailed feedback on it and then track it on GitHub or GitLab speeds up the development cycle. Netlify, for example, pioneered this when it launched Deploy Previews earlier this year. Netlify takes this feedback and integrates it into project management tools like Jira, Trello and many others in addition to GitHub and GitLab.

    collaboration version control

    We are seeing other companies, like Sturdy, building on this much-needed trend of real-time collaboration in app development.

    Collaboration is the Trend

    Great software is the story of teams expanding collaboration beyond developers and there is a lot of good tooling available to help achieve that. This trend should continue to gain traction in the years to come because it taps into a number of other underlying trends in the software development space.

    First, the explosion of alternatives in the backend-as-a-service space, in which Heroku and Firebase were early pioneers, means BaaS is embraced by many more organizations for a variety of use cases. This trend speeds up development because they present a much more tightly integrated ecosystem of services and organizations don’t have to worry about deployment, hosting, content delivery network (CDN) and/or authentication themselves, for instance.

    Second, the proliferation of APIs is driving the emergence of more complex applications built on a variety of data sources. Everything is connected to everything. Of course, this also means that a lot more data is available to support decision-making, and this leads to many different kinds of applications being created both for external as well as internal purposes.

    And finally, the larger low-code/no-code movement is creating millions of new citizen developers and blurring the boundaries between who is and isn’t a developer.

    Summary

    DevOps marked the start of the evolution of software development into a team sport, and collaboration is now accelerating beyond the boundaries of IT. Like DevOps, the result of this collaboration in the software development process will be better software that propels businesses forward created faster than ever before.

  • Trends in the API Industry

    Trends in the API Industry

    The application programming interface (API) economy is chugging along full steam ahead. The API management market alone is expected to expand 35% by 2025, supported by the sheer number of web APIs coming to market. APIs have become ubiquitous across microservices architectures, public product initiatives, SaaS platform offerings, IoT and partner-partner integrations.

    The industry has proliferated and continues to change, introducing new API use cases across all industries. This ubiquity creates a heightened need for an API program to maintain a quality developer experience and remain competitive. There are also different styles and specification options on the market, meaning designing the right API strategy is a moving target. And, amid peaking cyberattacks, developers now have a strong imperative to retain high security and reliability for these integration points.

    I recently met with the CEO at Stoplight, Steve Rodda, to discuss the above trends and other forces pushing the API industry forward in 2022. Below, we’ll dive into these trends to see how they affect API strategies and what developers need to know to stay on top of their applications.

    Non-Software Companies Embrace APIs

    As software eats the world, more companies are becoming software companies. And, an API strategy is part and parcel of this digital transformation. A big trend that Rodda recognizes is increased API strategies among traditionally non-software companies.

    For example, Rodda explained how a large beverage manufacturer evolved to adopt APIs company-wide to better use and scale their data. Standardizing the API development and design process helped avoid the “rat’s nest” of custom code, said Rodda. “APIs are no longer a byproduct; they’re a design artifact,” he said.

    APIs are no longer reserved for startup cloud-native unicorns like Stripe or Twilio, either. We now see many industries and sectors like supply chain management, health care, shipping, built environments and mainframe modernization adopting API approaches. The financial services sector is especially keen to open up APIs as open banking is being driven by regional regulation or market pressures.

    A Rise in Internal API-First Adoption

    ProgrammableWeb, the most comprehensive API directory, lists over 24,000 APIs at the time of writing. There’s no doubt that public-facing APIs are very well documented. But this is only a sliver of total API adoption.

    The 2021 Postman State of API report found that only 15% of APIs are publicly available. Most APIs are either partner-facing (27%) or private (58%), according to the report. In fact, the most popular use case for APIs is integration between internal applications, programs or systems. Along with the growth of internal API use, API-first thinking is gaining mind share. Postman defined API-first as “defining and designing APIs and underlying schema before developing dependent APIs, applications or integrations.”

    Internal use cases are less frequently discussed but are pervasive for large enterprises, said Rodda. Whereas in the past, development teams paid less attention to style guides and documentation for internal services, he now notices that these practices are shifting. The zero-trust approach is influencing teams to take more care in defining and standardizing internal APIs as if they’re external-facing. This also eases consumption. “You need to take care of the folks next door to you and treat them with just as much respect,” said Rodda.

    The Growing Need for Robust API Security

    APIs have a security problem. Many don’t handle authorization correctly and expose far too much information. A hacker can often escalate their privileges or simply swap a different user ID into an API call to return loads of sensitive data or even make changes to the data. Many HTTP API endpoints that are intended to be private really aren’t. As a result, OWASP lists broken object-level authorization as a top API vulnerability.

    In recent years, we’ve seen what can happen when APIs are improperly configured. For example, a Facebook API lacked an authorization check for unlisted posts, allowing a client to post on any user’s behalf. A similar authorization hiccup occurred with Peleton that allowed hackers to alter any user’s back-end account. APIs constantly work with sensitive data and must carefully navigate the various data privacy regulations around the globe.

    According to Rodda, a design-first mindset is vital to ward off security woes early in the API life cycle. This means deciding on a structure with a common design and choosing appropriate style guides well before coding. “Good documentation, good design guides and good discipline around building something with a cross-functional nature will increase security and scalability,” said Rodda. When you know what’s going on, you have more control and things are inherently more secure, he added.

    OpenAPI Carries The Day

    The OpenAPI specification, formerly known as Swagger, is an industry-standard specification for describing REST web APIs. OpenAPI can help direct your API’s design and development. OpenAPI tooling can also help generate useful documentation, sandboxes and SDKs, making it a valuable specification for creating interoperability between partners.

    “OpenAPI is going to carry the day for a while,” said Rodda. The OpenAPI Initiative has gotten the support of big names in the tech industry. Yet, Rodda estimated only 40% of companies have adopted OpenAPI in production. Rodda said he believes tooling will make it easier for more groups to maintain OpenAPI adoption across their organization, reducing the redundancy of writing “yet another YAML file.”

    REST is still by far the most-adopted API design style—59.7% of developers use REST for production APIs, according to RapidAPI’s State of APIs Developer Survey 2021 report. Yet, asynchronous event-driven communication protocols are gaining traction, and those protocols tend to prefer alternative description formats like AsyncAPI. Websockets, gRPC and GraphQL are other options consistently used by a significant percentage of API developers.

    Developer Experience Matches User Experience

    Another major trend is the rising importance of developer experience (DX). DX is akin to user experience but is all about increasing usability for developer consumers and improving their ongoing relationship with software-as-a-service. “DX is as big a deal as UI/UX these days, if not bigger,” explained Rodda. “Developer experience directly translates into efficiency and reusability.”

    In the context of APIs, increased consideration of developer experience means reducing the onboarding effort and maintaining more reliable connections. For example, users will likely look to other solutions if a third-party API has poor uptime and routinely introduces a breaking change. Better DX likely will also equate to increased abstraction layers and more code generation. Rodda pointed to GitHub’s CoPilot as an example of the use of AI and automation in the developer-of-tomorrow’s workflow.

    “We’ve evolved as a developer society,” said Rodda. Just as consumers expect high-quality real-time applications, developers expect highly performant APIs. To help get there, one increasingly popular philosophy is the API-as-a-product perspective. “If you treat it all as a product, you’re building it with the same standards and quality that you would share externally,” he explains. “Then, there’s no attention to detail that goes missing.”

    Final Thoughts: The Design-First Mentality

    More industries are utilizing APIs than ever before, and APIs are seeping into traditionally non-technical companies to aid their internal integration efforts. But data privacy is a pressing concern when opening up data, requiring careful measures. Taking a design-first approach with standards like OpenAPI could help organizations stay alert and ensure consistency across their portfolio of services.

    There are other trends at work in the API economy, too. For example, one interesting Web3 initiative is an attempt to combine the world of blockchain and APIs by enabling on-chain smart contracts to interact with traditional HTTP APIs. There is also a lot of development activity around GraphQL, which could act as a command line for consuming multiple APIs, thus making integration easier.

    Rodda said the biggest takeaway is that APIs should no longer be treated as byproducts. He compared it to a construction project: When building a house, you must start with a blueprint before installing the foundation, wall, roof or electrical system. Similarly, APIs require solid forethought to ensure stability and scalability.

  • How Are API Management and Service Mesh Different?

    How Are API Management and Service Mesh Different?

    The use of APIs and microservices is increasing—a recent study from F5 estimated that the industry is approaching 200 million total APIs. As organizations expand their use of APIs and microservices, they inevitably require some form of service management architecture. There are primarily two major design options for implementing this: An API management system or a service mesh.

    The key distinction between API management and service mesh can be framed using the four cardinal directions. API management is typically adopted for REST services that face external developers—referred to as north-south traffic. On the other hand, service mesh is more commonly used by internal suites of microservices to help control lateral, or east-west, communication. There are more nuances between each, as we’ll cover below, but this is essentially how they’re adopted in practice.

    However, this binary is becoming blurred as collections of enterprise digital applications expand and access to cross-company business domains begins to look and feel more like consuming a third-party SaaS. Furthermore, some suggest that with the right controls, service mesh can cater to external users in the same way API management does. What’s more, service mesh and API management are complementary—they can coexist within the same organization and even be deployed in the same projects.

    I recently chatted with Mark Cheshire, director of product at Red Hat, about the emergence of both API management and service mesh. According to Cheshire, both approaches accomplished similar goals but evolved very differently. Below, we’ll revisit why these two paradigms emerged and compare and contrast them. In a separate article, we’ll consider when it’s best to integrate them both.

    What is API Management?

    API management is most often associated with north-south traffic. By exposing your API to the outside world, you enable other developers to connect it to their systems and leverage your data and functionality like building blocks.

    API management arose in response to the rise of web APIs. API management is a broad concept encompassing many functions required to expose an API endpoint to the outside world. This can include authentication, authorization, request routing, documentation, rate limiting, monitoring, logging, monetization and life cycle management. A key goal is to make integration easier for the developer consumer. Architecturally, API management follows a gateway pattern. Consumers issue requests to the gateway which then performs routing to the underlying services.

    For APIs, the big catalyst was the emergence of Web 2.0, Cheshire explained. Numerous startups began consuming RESTful APIs to connect their web properties and partner ecosystems. Companies also found REST APIs to be a much more straightforward integration approach than SOAP and SOA. They also saw the ease-of-use benefits and adopted API-first designs within their internal infrastructure.

    As of 2021, over 70% of APIs are built for internal use. So, do all these services need API management? It depends. “If you communicate externally, you need API management,” explained Cheshire. But, it’s a grey area for services within an enterprise, he says, though inter-domain traffic often could benefit from API management.

    A diagram of API management capabilities, from 3scale
    A diagram of API management capabilities, from 3scale

    Strengths

    • Can enable north-south traffic
    • Protects the boundary of an application
    • Designed to ease external developer consumption
    • Potential for monetization, subscription plans
    • Typically plug-and-play; easier to support
    • Many solutions on the market
    • Developer experience and docs
    • Analytics and reporting

    Weaknesses

    • May be heavier than service mesh
    • Fewer open source options; vendor lock-in
    • Analysis paralysis in comparing solutions

    What is Service Mesh?

    Service mesh is most often associated with controlling east-west communication between internal services. Service meshes like Linkerd, Istio and Kuma make it easier to reimplement similar logic—such as networking, observability, traffic management, security policies and routing—across many microservices from a single control plane.

    Service mesh was born to address slightly different challenges than API management. “The transition from monolithic to microservices is all about east-west traffic,” Cheshire said. Companies found it slower to innovate monolithic applications and thus broke them up into microservices that communicate via APIs. But these microservices all needed similar operational capabilities, which would be cumbersome to repeat over and over for each service.

    “For one monolithic app blown into microservices, you may not even need a service mesh,” said Cheshire. “However, when you have hundreds or thousands, that’s when applying service mesh becomes critical.”

    Istio service mesh architecture
    Istio service mesh architecture

    Architecturally, service mesh is typically divided into a data plane and a control plane. The service mesh deploys a sidecar proxy that sits alongside each individual service. Istio, for example, utilizes the Envoy proxy. Other meshes like Linkerd use their own proxy.

    Strengths

    • Fits the microservices architecture paradigm well
    • Good for traffic routing; improving resiliency
    • NIST-recommended architecture for achieving zero-trust
    • Many open source options
    • Fits large microservices deployments

    Weaknesses

    • Requires a more hands-on approach
    • Potentially more maintenance to support
    • Unnecessary for a single service
    • Requires filter chain add-ons for north-south abilities

    Comparing API Management and Service Mesh

    API management is predominantly aligned with externalizing APIs to partners. When you do so, maintaining the contract with a consumer is more important to meet SLAs. Thus, API management commonly delivers life cycle management abilities, such as versioning. API management is necessary even if you are exposing a single API, as this service needs to be adequately documented and secured. That being said, these tenants can also be relevant to developers reusing software within an organization—there’s something to be said for adopting a product mindset when dealing with internal APIs.

    On the other hand, service mesh is more aligned with controlling internal networks. Microservices are rarely deployed alone; typically, multiple microservices make up an application. And, many more might exist throughout an organization for unique purposes. Service mesh thus helps maintain consistency throughout large networks of decoupled microservices. Service mesh is also a rapidly growing field, experiencing an explosion of new development and production use. A Cloud Native Computing Foundation (CNCF) report found that service mesh use rose in production by 50% in 2020 alone.

    To put the comparison another way, William Morgan, CEO, Buoyant described how API management is more about business logic, whereas service mesh handles intra-cluster operations:

    “API gateways typically handle ingress concerns, not intra-cluster concerns, and often deal with a certain amount of business logic, e.g. ‘User X is only allowed to make 30 requests a day’. By contrast, a service mesh like Linkerd is focused on operational concerns (e.g. instrument these calls and report their success rate; secure this communication between these pods) and purposefully avoids the mixing of business and operational logic; and focuses on communication between the services on the cluster.”

    Though service mesh and API management achieve slightly different aims, both layers make it easier to reuse web-based services. And, they certainly can be used in conjunction. For example, you could build API-first microservices with service mesh and simultaneously use API management to expose certain domains. In another article, we’ll consider when it’s best to integrate the two technologies.

  • Step Aside, Monoliths: Meet the Composable Enterprise

    Step Aside, Monoliths: Meet the Composable Enterprise

    A composable enterprise, defined by Gartner as “an organization that delivers business outcomes and adapts to the pace of business change”, relies on the assembly of interchangeable application building blocks. This architectural overhaul has largely been driven by a demand for more configurable application experiences, and the need to evolve existing application portfolios that are often too risky and costly to replace.

    New business opportunities require agility from application portfolios; however, many enterprises are still limited in their ability to adapt. Why? They rely on monolithic ERP systems and cumbersome legacy applications with static processes and haphazard structures. A modular setup can enable a business to rearrange as required depending on external or internal factors, such as shifts in consumer attitudes or sudden supply chain disruptions. Organizations are experiencing these shifts now and require a new approach to enterprise applications to be able to adapt. 

    Bridge the CX Gap with Greater Composability

    A composability approach is the best way to capture all the advantages of modern enterprise software. According to a recent Boomi report, by 2023 organizations that have adopted a composable approach will outpace the competition by 80% in the speed of new feature implementation. This shift requires enterprises to rethink how they architect their operations, harness a combination of packaged functions and technologies and successfully deliver seamless moments of service to their customers.

    There are three key ways that businesses can make the composability shift:

    • Adopting a service mindset
    • Scaling the delivery of microservices
    • Packaging business capabilities using Application Programming Interfaces (APIs). 

    1. Designing for Service: Compete on Outcomes, not on Products 

    A composable enterprise whose portfolio is made up of heterogeneous applications from a palette of best-of-breed solutions allows organizations to address key inflection points throughout every customer, product or service lifecycle.

    As more consumers demand continuous value and reliability throughout an asset’s lifetime, businesses must shift to selling outcomes and experiences instead of products to meet these new expectations for quality service. This requires each part of an operation to align, not around immediate sales or revenue, but around delivering a quality Moment of Service™ — the inflection point where everything comes together to create better value and outcomes for customers. 

    Moving to a servitized model requires a composable stack to deliver services to order. At a systems level, this transformation requires organizations to adapt applications dynamically and deliver positive customer experiences with effective quality management, customer support, and access to complete information about the service offering. Unlike traditional enterprise software, this involves connecting data and applications that have often sat in separate silos. A composable enterprise can provide a service-orientated architecture, that enables businesses to become outcome-based and ready to quickly adapt to future disruptions. 

    2. Scale Component-based Architecture with Microservices

    If applications are built as loosely coupled services, then companies can employ a composable architecture to capitalize on independently deployable modules that are organized around business capabilities. This allows organizations to swap modules in and out, to suit emergent needs and build a well-structured best-fit solution for their unique business. 

    In contrast to a monolithic architecture, businesses can easily add resources to the most needed microservice rather than having to scale the entire application as demand for an application increases. In practice, this allows businesses to simplify customizable workflows and optimize business processes while leveraging and applying tools such as robotic process automation, artificial intelligence, or the plethora of hyper-automation capabilities available today.

    3. Embrace Open-ended APIs to Maximize Data-sharing Capabilities

    Packaged business capabilities (PBC) assembled using APIs are the foundation of every composable enterprise. They are used by businesses to secure data across cloud services, business systems and mobile applications. Historically, APIs have been used in monolithic applications to exchange data between the entire application and external applications and services. In composable software, APIs exchange data from individual modules to external applications and within the application — from module to module. This has significant implications for how systems are designed and built.

    APIs can provide a controlled and consumable method for connecting and sharing consumer and business data by creating experiences tailored to individual needs. For instance, an API-centric model can secure and manage data access to help businesses with faster decision-making and deliver relevant new services adaptable to market changes. In the future, there will be more automated continuous process improvements as machine learning models recommend, or even proactively make, process changes to improve outcomes for the business and end customer.

    Opt-in to the Composability Evolution

    To overcome the limitations of monolithic applications, businesses must rethink their approach to enterprise applications — starting with the business architecture and technology stack. A composable software architecture enables organizations to address the internal and external pressures that send shockwaves throughout the value chain. 

    As a composable enterprise, organizations can re-engineer their businesses to ensure customer touchpoints and stages come together for better moments of service, but companies must be certain that processes are optimized across each of these inflection points to mitigate issues and fuel growth. An IT architecture built on a foundation of composability will be essential to the successful delivery of a software-powered business development strategy that can provide continual value to customers and the business itself. 

  • Best of 2021 – How to Revoke JSON Web Tokens (JWTs)

    Best of 2021 – How to Revoke JSON Web Tokens (JWTs)

    As we close out 2021, we at devopsy.kinsta.cloud wanted to highlight the most popular articles of the year. Following is the seventeenth in our series of the Best of 2021.

    One of the most common questions about JSON Web Tokens (JWTs): Once they’re issued, how can they be revoked?

    What Are JWTs?

    JSON Web Tokens are portable, industry-standard identity tokens. They are issued after a login request by a central identity server and used to identify and credential a user and grant access to resources. They can be presented by clients such as browsers and external programs. Applications and APIs can examine them to ensure the caller is properly authenticated and authorized.

    The Challenges Involved

    One of the most common questions is how to revoke them. The problem is that once they are issued, no further communication is needed with the identity server. That’s one major benefit of JWTs decentralization.

    Let’s say you use RSA public/private key signing for secure data transmission. After the IdP signs a JWT using the private key, any service that has the public key can verify the integrity of the token.

    Let’s use the Todo-Backend API as an example. The architecture might look something like this:

    Todo API

    Now, Todo-Backend can use JWT and the public key to verify the user’s ID and other attributes, and then use that ID to perform operations on that user’s data. Once the JWT has been issued, Todo-Backend doesn’t communicate with the identity provider at all. As a result, if an administrator has locked or deleted that user’s account in the identity provider, Todo-Backend won’t know about it.

    Managing Revocations Using a Distributed Event System

    The most common way to revoke access to resources protected by a JWT involves setting its duration to a short period of time and revoking the refresh token so that the user can’t generate a new token. This does not revoke the JWT per se; it does solve the root issue, which is to limit access.

    In other words, you can set the JWT’s expiration duration to a short period (e.g., anywhere from a few seconds to, say, ten minutes) and set the refresh token’s expiration duration to a longer period (e.g., a two-week or two-month window).

    During the normal flow, the Todo API would accept the JWT until it expires, at which time access would be denied. At that time the client could present the refresh token to the identity provider, which would send a new JWT to the client. That new JWT would be valid for another ten minutes.

    An administrator can, at the identity provider, revoke the refresh token at any time. Any subsequent request for a new JWT by a client holding that refresh token would fail and access to the Todo API would be lost.

    However, while ten minutes isn’t long, this timeframe still comes with risks.

    One strategic way to handle this challenge is to set up a distributed event system that notifies services when refresh tokens have been revoked. Upon receiving this event broadcast, backends/services would update a local cache that lists users with revoked refresh tokens. After a JWT is verified, this cache would then be checked to determine whether or not access should be revoked.

    This distributed event method truly revokes the JWT, rather than simply waiting for it to expire, as mentioned above.

    An Example of Revoking JWTs

    Here’s a sample solution that provides support for events and webhooks that can be used to implement this revocation strategy. In this example, when a user logs out or has their refresh token otherwise revoked, a jwt.refresh-token.revoke event is emitted. This includes the user ID and the application for which the revocation occurred. It also includes the JWT lifespan for this application (in the below case, 600 seconds). Any JWT for this user that was issued before 600 seconds from the point in time when this event was received is thus revoked.

    For example:

    • User logs in, and JWT ‘abc’ is issued at 1:11pm. JWT is good until 1:21
    • User logs out at 1:15. Entry is added stating that any JWT for this application and user expiring before 1:25 is revoked.
    • Application tries to use JWT ‘abc’ at 1:16. Todo-Backend does not deliver data because this JWT is on the denylist.
    • User logs in, and a new JWT ‘def’ is issued at 1:18. JWT is good until 1:28.
    • Application tries to use JWT ‘def’ at 1:19. Todo-Backend delivers data because this JWT is good until 1:28 and is therefore not on the denylist.

    JWT Revoke

    What you need to do is write a simple webhook that will receive this event and inform JWTManager that the refresh token for applicationId for this user has been revoked.

    JWT webhook

    JWTManager maintains a list of user IDs whose JWTs are revoked. You could also use JWT IDs (the `jti` claim), which, in some cases, might be simpler. JWTManager also launches a thread to clean up the cache to remove expired users and avoid running out of memory.

    Is valid

    For each API call, in addition to all the other checks that should be performed against a JWT (verifying the signature, expiration, issuer and so on), the backend needs to check validity with JWTManager.

    configure webhook

    As a final step, configure the webhook:

    JWT webhook

    The Revocation Process, Simplified

    Using the process described above, you can revoke a user’s refresh token and broadcast the event using a webhook. The webhook receivers then update JWTManager, which will render JWTs for that user unusable.

    The good news is that you can use a webhook and event system to build this feature into your application quickly. You can also write JWTManager implementations into Java, Node and other client libraries for future use. Other languages, such as Ruby, have denylist implementations already written.

    Ultimately, all that’s required are the use of refresh tokens, an API that enables revocation of refresh tokens and a system for distributing the revocation event. This solution should work well with most systems, even large systems with numerous backends.