devopsy.kinsta.cloud

Tag: APIs

  • Hasura Unfurls Data Delivery Network Based on GraphQL

    Hasura Unfurls Data Delivery Network Based on GraphQL

    At its HasuraCon 2023 conference today, Hasura launched a Data Delivery Network (DDN) based on a set of GraphQL application programming interfaces (APIs) that makes it simpler to integrate distributed sources of data.

    In addition, Hasura is adding Hasura Schema Registry to streamline API governance using graph technology, a MongoDB connector, a Native Data Collector (NDC) for REST APIs and support for the Open Domain Data Specification (OpenDDS), an open framework for modeling APIs originally developed for the travel industry.

    Finally, Hasura is adding support for Native Queries and Logical Models capabilities that convert SQL requests into API calls.

    The Hasura DDN leverages the GraphQL API to enable sub-second integrations across a network that, in concept, is similar to how a content delivery network (CDN) is constructed.

    Hasura CEO Tanmai Gopal said the goal is to enable sub-second integration of data at a global scale across a network with more than 100 regions. Developers can integrate their APIs in less than a second regardless of the number of data models connected. Metadata changes can also be used to create builds that can be independently tested and applied to projects to enable API version control and collaboration among development teams.

    The Hasura DDN is accessed via Hasura Cloud, an instance of a data integration platform that can be deployed on multiple clouds, including Microsoft Azure, and will soon be made available for private clouds managed by internal IT teams.

    GraphQL is gaining traction as an alternative to REST APIs for integrating data, but it’s more complex to implement and manage. The Hasura DDN extends the reach of a Hasura Cloud platform that provides a simpler method for adding GraphQL capabilities to an IT environment in a way the also conserves network bandwidth, noted Gopal.

    GraphQL is a query language for APIs and a runtime for fulfilling queries that provides a complete and digestible description of the data in an API. It can also be used to pull data from multiple sources because it uses a schema that defines the different types of data available. REST APIs, in contrast, can only fetch data from a single source. As such, many organizations that are trying to drive adoption of reusable digital services are relying on GraphQL.

    It’s not always clear who within an organization is assuming responsibility for managing the APIs that developers create, but as the number of APIs increases, DevOps teams, in many cases, are moving to centralize API management. In fact, the more data an organization creates, the greater the corresponding use of APIs to programmatically access that data becomes.

    Hasura is betting that as organizations reach a critical mass of API integration requirements, it will make more economic sense to rely on a purpose-built data integration platform accessed as a cloud service versus relying on a set of tools and platforms they need to configure and manage. Regardless of approach, the one thing that is certain is the number and types of APIs that need to be managed are rapidly exceeding the ability of IT teams to keep pace.

  • The API Life Cycle Mixer’s Manual: What Goes Into a Single Source of Truth?

    The API Life Cycle Mixer’s Manual: What Goes Into a Single Source of Truth?

    In bartending, the mixer’s manual is a trusted source of information. These books can contain hundreds of recipes for classic cocktails, some of which might be 100 years old, while others might be for drinks that only recently arrived on the scene. Mixer’s manuals also can be great sources of inspiration for new, yet-to-be-tested recipes for exciting additions to a bar’s or restaurant’s offerings. This balancing act of preserving the old while encouraging exploration into the new can provide a valuable lesson for API development in the software world. An API’s “single source of truth” is, in many ways, the software organization’s own mixer’s manual. This is especially true when the right approach is taken to ensure that software remains functional and performant and serves up experiences that delight customers and keep them coming back for more.

    The Rise of APIs and Mixology

    While we might think of mixology and the mixologists who practice this craft as relatively new terms, the first recorded use of the word “mixologist” dates back to 1852 and “mixology” followed shortly after.

    Just how similar are the work, mindsets and passions of mixologists and API developers and designers? Check out this definition of a mixologist and count the similarities for yourself:

    “The term ‘mixologist’ refers to someone who studies the history of mixed drinks, has a rich appreciation of the ingredients and techniques used and regularly creates new and innovative mixed drinks … their job title implies that they do a significant portion of their job behind the scenes, creating new craft cocktails and putting their signature twist on existing favorites.”

    The best API developers, designers and architects of the world should recognize a lot of the above in their own work. They have deep respect for their craft and are always honing it further. They seek to understand the tastes and palates of their consumers. They factor in other stakeholders’ inputs, they test, iterate and test their creations again before “serving” those APIs to production.

    Like mixologists and bartenders (if you see them as two different roles), every professional along the API life cycle should understand the needs of consumers, customers and the business–and then design and develop their APIs accordingly. An essential part of this process is continuous validation and adaptation to market requirements.

    Maintaining Confidence in Ever-Changing Recipes

    Changes to APIs, even minor ones, can have significant downstream effects. And the same can be said for tweaks made to an age-old cocktail recipe, where adding or removing a single dash of this or that can completely change the flavor of a drink … as well as people’s interest in it.

    While there’s no “standard” rate of change to APIs to plan for, you can expect changes to be needed with each new software release. This could mean changes are being made (and need to be tested against and validated) every few weeks, every month or even every day, depending on your release cadence. There also can be as-needed, ad-hoc changes.

    What’s crucial for teams to ensure is that these changes do not disrupt an API’s functionality or performance. To make this possible, teams are increasingly leveraging API contract testing to provide a safety net of sorts. This comes in the form of testing that validates changes against a “contract” that details an API’s original, agreed upon and, therefore, required functionality.

    The ability to foresee the impacts of changes to APIs can depend on the maturity of an engineering team and its ability to collaborate across departments, time zones and varying levels of technical expertise. Tools and guidelines that promote standardization and collaboration can prevent mishaps from overlooking or being blind to negative downstream effects.

    Documentation is Key

    Whether we’re talking about being able to trust a single source of truth for the most up-to-date version of a published API or the latest edition of a mixer’s manual for tried-and-true drink recipes, clear and concise documentation is key. But it’s also not enough for this documentation to simply exist.

    It seems like common sense—although you’ve probably worked somewhere where it wasn’t—that your API documentation also needs to be easily accessible, understandable and usable. Ensuring all of these things leads to smoother onboarding and a positive developer experience and, ultimately, to wider adoption of a functional, performant API that meets or even exceeds expectations.

    API documentation is often the first point of contact a developer has with an API. It serves as a guide, walking developers through the API’s features, endpoints, request/response models and error messages. It also provides insight into the underlying business logic and unique characteristics of an API.

    Good API documentation follows the principle of a single source of truth, meaning that it should be comprehensive, up-to-date, and consistent. It should always mirror the actual behavior of the API, reducing the guesswork for developers and minimizing the potential for misunderstandings and errors.

    Just as a mixologist relies on a detailed and accurate cocktail recipe to deliver a pleasing experience to a patron, API developers depend on good documentation to create and deliver useful, value-add APIs and powerful applications.

    Continuous Improvement = Continuous Education

    Like a mixologist who meticulously adjusts the ingredients of a cocktail or who creates new cocktails to meet the evolving tastes of customers, developers must constantly adapt their APIs to meet changing market demands, business needs and industry standards.

    This is achieved through a potent blend of market research, collaboration, adherence to standards and governance and meticulous testing. However, as software development, testing and deployment technologies and processes continue to evolve, the tech industry must continue educating itself and refining its practices.

    With a mindset focused on constant learning and continuous improvement and a dependable single source of truth as their guide, development teams can confidently serve up exceptional API experiences in every release. In the end, the aim is to create APIs that are reliable and easy to consume and that meet the unique needs of the moment–much like a mixologist’s perfect beverage.

  • The Role of SBOMs in Software Supply Chain Security

    The Role of SBOMs in Software Supply Chain Security

    The software supply chain has become increasingly complex and dynamic with the rise of cloud computing, open source software and third-party software components and APIs. Widespread damage can occur if third-party APIs, cloud services, SDKs and open source software have security flaws. As a result, software supply chain security has emerged as a critical concern for organizations across industries. Supply chain attacks have become more frequent, sophisticated and devastating, as evidenced by high-profile incidents such as SUNBURST, Kaseya and Apache Log4j.

    To address the growing challenge of software supply chain security, organizations have turned to leveraging software bills of materials (SBOMs). SBOMs are a standardized inventory of software components used in a particular product or system, including their versions, dependencies and sources. SBOMs provide transparency and visibility into the software supply chain. They can be an effective approach for identifying and mitigating security risks, compliance issues and operational challenges – assuming organizations have the right tools to fully benefit from SBOMs, including runtime discovery, in place.

    SBOMs are not a new concept, but their adoption has accelerated in recent years due to a number of important factors, including the following.

    First, regulatory agencies, such as the U.S. National Institute of Standards and Technology (NIST) and the Cybersecurity and Infrastructure Security Agency (CISA), have been advocating for SBOMs as a best practice for software supply chain security. NIST has released a draft guidance document on SBOMs, and CISA has mandated SBOMs for federal contractors and subcontractors.

    Second, industry initiatives, such as the Open Source Security Foundation (OpenSSF) and the Software Assurance Forum for Excellence in Code (SAFECode), have promoted SBOMs as a key element of software security. OpenSSF has launched a working group on SBOMs and published the Open Source Software Security Mobilization Plan to improve the resiliency and security of open source software (OSS), including guidelines for SBOM management; SAFECode published a whitepaper on SBOMs.

    Third, supply chain attacks have highlighted the need for SBOMs as a proactive and preventive measure. SBOMs can help organizations detect and respond to vulnerabilities, malicious code and unauthorized changes in the software supply chain. SBOMs can also support incident response and recovery efforts by providing accurate and comprehensive information about the affected software components.

    Fourth, customer demands and market pressures have influenced the adoption of SBOMs. Customers are increasingly aware of software supply chain risks and are asking for SBOMs as part of their procurement and evaluation processes. Some industries, such as health care and automotive, have mandated SBOMs for safety and liability reasons. SBOMs can also enhance brand reputation, customer trust and competitive advantage for software vendors.

    Fifth, technological advancements have facilitated the creation and consumption of SBOMs. The emergence of open standards, such as CycloneDX and SPDX, has enabled interoperability and integration of SBOMs across different tools and platforms. The development of automated tools, such as software composition analysis (SCA) and vulnerability scanners, has enabled the generation and validation of SBOMs in a timely and accurate manner. The integration of SBOMs with other security measures, such as identity and access management (IAM) and security information and event management (SIEM), has enabled an effective view of software supply chain security.

    However, SBOMs are not a silver bullet for software supply chain security. They are only as good as the data they contain, and the quality of data can vary depending on the source and the method of collection, particularly around the application software stack of APIs, cloud services and SDKs. SBOM inventory is constantly changing, and being able to leverage their up-to-date data requires more than a snapshot from traditional source code static analysis approaches, but rather continuous runtime analysis and dynamic inventory.

    For example, common vendor management and software composition analysis (SCA) approaches often lack source code access for mobile, web, cloud and commercial-off-the-shelf (COTS) software, as well as third-party API services.

    For a more effective approach, organizations can benefit from a full-stack attack surface management (ASM) software supply chain solution that delivers continuous third-party application asset discovery and dynamic tracking of third-party vendors. These newer approaches automatically categorize assets under known vendors, allow customers to add additional new vendors, curate individual assets under any vendor, and alert on increases in policy violations and high embed rates of third-party vendors within key applications. These automated capabilities allow vendor management teams to remedy supply chain security problems more quickly and easily and much more accurately than older approaches.

    It is important to note that SBOMs also require collaboration and communication among multiple stakeholders, including software vendors, suppliers, customers and regulators. They may also pose some privacy and intellectual property concerns since they can reveal information about the software components and their relationships.

    Overall, organizations need to adopt a comprehensive and risk-based approach to software supply chain security, of which SBOMs and tools to best leverage their information are an important component. Organizations should establish policies and procedures for SBOM creation, management and sharing, as well as for validation and verification. Organizations should also integrate SBOMs with other security measures and practices, such as threat modeling, penetration testing and code review to best ensure the security of their software supply chains.

  • 4 Risk Factors Devs Should Consider for ChatGPT Integrations

    4 Risk Factors Devs Should Consider for ChatGPT Integrations

    It’s only been a couple of months since OpenAI introduced its latest low-cost API for developers to leverage ChatGPT in their applications and already many engineering teams have jumped headlong into new integrations. But developers experimenting with the possibilities of how ChatGPT can boost their software should temper that with some risk analysis and threat modeling before deployment. So say a range of cybersecurity and risk experts, who warn organizations that leverage the ChatGPT API in their software that they’ll need to navigate a minefield of privacy, data governance, and security operational risks.

    “I use ChatGPT Pro and think it’s an exciting tool for holiday cards, poems for my kid, writing inspiration, first drafts and search,” says Patrick Hall, data scientist and co-founder of BNH.AI, a boutique law firm focused on minimizing legal and technical risks of AI. He’s also the author of the upcoming book Machine Learning for High-Risk Applications. “I get concerned about generative AI used as a consumer product in high-risk domains, such as consumer finance or the law.”

    With that framing in mind, the following are a few of the areas that experts like Hall suggest that developers, DevOps teams and CTOs start thinking about to avoid some potentially costly unintended consequences of ChatGPT integration in their software.

    Data Privacy and Governance Concerns

    One of the most immediate and obvious risk concerns IT leadership, DevOps teams and privacy experts are worried about is what happens to sensitive data when users enter it into a ChatGPT-backed prompt—whether directly or through an app using the API. Be it a customer entering personally identifiable information (PII) into an external-facing app or an employee entering proprietary company information in an internal tool using ChatGPT’s API, these use patterns open up a world of data exposure and regulatory compliance concerns. The good news is that OpenAI does not use data submitted through the API to train its models, but this shouldn’t automatically give devs peace of mind. They’ll need to be sure that using generative AI in an app truly aligns with their company’s privacy policies and with any local, federal or international data privacy laws their firm is beholden to, said Hall.

    “Although OpenAI appears to maintain a robust security and privacy program and there are steps you can take on your own to limit data sharing, some people are still worried,” said Walter Haydock, founder and CEO of StackAware.

    Among Haydock’s side projects, he is currently developing a tool for sanitizing data before sending it to OpenAI. Called GPT-Guard, it’s still in beta and it would need to be run on a local machine or in the cloud to sanitize data before sending it via API. But it provides some rapid prototyping of the kind of methods and tools developers may need to think about as they design their applications to interact with ChatGPT.

    Intellectual Property Infringement

    Developers should also be thinking through intellectual property infringement concerns when it comes to the responses generated by an app tapping into ChatGPT, Hall said.

    “Devs need to consider whether a generative AI system may be coughing up other people’s licensed or copyrighted intellectual property as responses,” he said.

    This is likely going to be a tricky situation that will likely be tested by the courts in the coming years. For example, will applications using ChatGPT be required to compensate licensed copyright holders for certain kinds of responses using their material? These are the kinds of questions that developers and the organizations they work for should be asking themselves, said Frank Huerta, CEO of Curtail Security and a longtime DevOps expert.

    “For example, what’s the mechanism for resolving IP and copyright disputes?” he asked. “Is ChatGPT going to have its own IP? Is it going to generate it—and will it put that in the public domain? Who owns the copyright to a generated response? None of that has been considered yet, and it’s going to come up fast.”

    Adding New Cybersecurity Threat Vectors

    In addition to all of the concerns about the data, developers integrating ChatGPT into their applications also need to consider what that does to the software’s attack surface. ‘Never trust user input’ has always been a good rule of thumb for developers, and that advice is just as true for large language model (LLM) prompts as anything else.

    A recent example scenario laid out by a data scientist on Twitter showed one of the myriad ways that malicious actors could carry out prompt injections in the same way they’d carry out a SQL injection. In that scenario, if a recruiter used ChatGPT to crawl LinkedIn profiles for a certain keyword and send an email to the people whose profiles included that keyword, it’d be possible to add text to a profile that sends an email chiding the recruiter for using an automated tool to send out emails. That’s a fairly low-stakes example, but it shows the possibility for injection attacks, said Andy Patel, a security researcher for WithSecure who has been digging into AI risks.

    “So, if you are integrating it, you should think about things like that. You should think about the fact that people will determine that you are using a large language model to do something, to automate something, and then they’ll essentially SQL injection attack it,” he said.

    Problems With Bias

    Finally, developers and software design teams should be cognizant of the potential problems that AI bias can introduce into their software if they lean on the generated output from ChatGPT to trigger actions or to inform the user.

    “Generative AI systems continue to make wrong, offensive or otherwise problematic content. Being wrong can give rise to negligence issues and biased content can lead to discrimination issues,” Hall warned. “Don’t embarrass yourself, offend others or run afoul of the law by not testing and further protect yourself by screening the heck out of generated content.”

  • State of Developer Experience Report Finds Growing API Reliance

    State of Developer Experience Report Finds Growing API Reliance

    Web APIs continue to grow in interest among developer users. APIs can empower new customer experiences and help engineers avoid rebuilding common functions. The technology is also powering microservices and headless architectures that we’ve seen gain more traction in recent years as enterprises become more composable.

    On the provider side, a web API strategy can enable co-creation in partner ecosystems and even open new revenue opportunities for the business. Yet, like any software-as-a-service (SaaS), APIs require great developer experiences to create quick onboarding journeys and easy ongoing maintenance.

    Nylas recently released its inaugural State of Developer Experience Report, detailing the key trends, technologies and priorities that are molding the modern developer experience. The study found increasing reliance on APIs and hopes to increase investment in API-driven technologies. I also met with Isaac Nassimi, SVP of product, Nylas, to explore the reasons behind some of these findings and to get his perspective on the API economy at large.

    Rising Importance of APIs

    As I’ve covered before, the number of APIs in the market has ballooned as more development teams have come to rely upon APIs to power new application functions. The largest companies, those with 10,000 or more employees, have more than 250 internal APIs, according to Rapid’s 2022 State of APIs report.

    Similarly, the Nylas study underlined the growing reliance on APIs. A full 98% of developers said they view APIs as a key contributor to helping them and their team get their work done. And 86% of developers said they expected their use of APIs to increase in 2023.

    According to Nassimi, APIs are something that’s become more and more prevalent over time. For example, in 1998, setting up a web server was pretty cumbersome. But nowadays, a junior developer can accomplish the task (and much more) with a few lines of code, he said. APIs abstract complexity and help leverage external infrastructure so you aren’t constantly reinventing the wheel. “They add more functionality and help outsource labor, thought and cognitive load,” explained Nassimi.

    APIs Bring Developer Experience Benefits

    Another possible reason to shift toward APIs is to handle escalating tool usage. Almost half (48%) of developers said they are either always or often overwhelmed by the number of tools they use daily. Simultaneously, 98% of developers said APIs would lessen the number of workplace tools they use daily. The study indicates that investment in APIs can increase automation and reduce the manual headaches of crafting new features by hand.

    For example, Nassimi describes creating a video transcoding service from scratch in a previous company. The entire engineering team had to dedicate months and months to the process, using muscles they hadn’t ever exercised. After much effort, they ditched their work and ended up just using an API. “It was a really good feeling to delete 200 lines of code,” said Nassimi. “If you do that five times, you reduce all these esoteric things you have to learn how to do in your company by an order of magnitude.”

    In addition to reducing headaches, APIs can also enable speed. For example, it can take over a year for three senior engineers to build an email or calendar integration without the help of an API, the report found. With an API, this integration timeline can be minuscule, said Nassimi. As a result, 95% of all respondents said they would like to see their company invest more heavily in APIs within the next year.

    Developer Experience Improvements

    Developers find speed to be the number one benefit when working with APIs. And to grant this speed, API providers must create a streamlined developer experience (DX). The speed of implementation can make the difference between a good DX and one that is not so good, and a significant contributor to this speed is familiarity. One DX hangup is that the API you use must function like the code you use in your own environment, said Nassimi.

    Although solid documentation and naming conventions should exist in the background, Nassimi shared that forcing developers to learn terminology about the thing the technology is abstracting is a lousy developer experience. Instead, installing SDKs in the unique language of choice, like TypeScript bindings, and using autocompletes to understand the SDK can grant a much better experience.

    Workflow automation and AI can also enhance developer experience, as it frees up time for engineers to be more productive. In fact, two out of three developers would like their company to invest in AI for workflow automation and to curate better user and customer experiences. And 72% of developers said they or their organization are currently using AI for data analytics and making sense of their data.

    However, when it comes to generative AI like ChatGPT and Bard, developers are less enthused—only 14% of developers reported it as a useful area that their companies should invest in over the next year. Although the headlines proclaim that generative AI will disrupt most aspects of modern work, the technology is still new and can produce errors and introduce potential security repercussions.

    Looking Through the Micro Lens

    Developers integrating with APIs will have various backgrounds and priorities. And although speed is an important consideration, providers should also understand where their workloads lie and what particular features they should be driving, said Nassimi. “You want to show off all endpoints and features, but if you narrow down to show users what they need to get started, you will close more deals,” he said.

    For more details, you can download a copy of Nylas’ State of Developer Experience 2023 behind an email gate here.

  • GraphQL Documentation Generators: How They Work and Why They Matter

    GraphQL Documentation Generators: How They Work and Why They Matter

    GraphQL is an open source query language developed by Facebook that provides a more efficient, powerful and flexible alternative to traditional REST APIs for fetching and manipulating data over the web. It allows clients to specify the shape and structure of the data they need and receive exactly that, no more and no less.

    Unlike REST APIs, which expose fixed endpoints for specific resources, GraphQL enables clients to construct complex queries that describe the exact data they need, with the server returning only that data in response. This allows for more efficient network usage and improved integration with CI/CD pipelines, as changes to the data requirements can be easily made without breaking existing clients.

    GraphQL also offers real-time capabilities through subscriptions, allowing clients to receive live updates as data changes on the server and supports a range of programming languages and platforms through a variety of libraries and tools.

    What are Documentation Generators?

    Documentation generators are tools that automatically create documentation from source code, making it easier for developers and other stakeholders to understand and work with a codebase. These tools parse the source code and extract information about the structure, behavior and dependencies of the code and use this information to generate documentation in various formats, such as HTML, PDF or markdown.

    Documentation generators can help improve the quality of code documentation by automating the process and reducing the risk of errors or omissions. They can also save time and effort for developers, as they can quickly generate documentation without having to write it manually.

    There are different types of document generation techniques, each with its own advantages and use cases. Let’s discuss some of them:

    • Batch generation: A generic technique that involves generating documents in bulk using a set of rules and templates. It’s commonly used for generating reports, invoices and other similar documents that follow a specific format. Batch generation can save time and effort by automating the document creation process and reducing errors.
    • Text block correspondence: Involves creating documents based on pre-defined text blocks. These text blocks can be customized and combined to create different types of documents, such as contracts, letters, and proposals. Text block correspondence is commonly used in document assembly tools, which allow users to create documents by selecting the appropriate text blocks and filling in the necessary information.
    • Forms: A type of document generation that involves creating web-based forms that users can fill out to generate documents. Forms can be used for a variety of purposes, such as generating applications, registrations and surveys. Forms can be customized to match the specific needs of the organization or business.
    • Documentation synthesis: Involves combining data from multiple sources to create comprehensive documentation. This technique is commonly used in software development where documentation needs to be created for different parts of the system. Documentation synthesis can save time and effort by automating the documentation process and ensuring consistency across different parts of the system.

    Documentation Generators for GraphQL

    Documentation generators for GraphQL work by analyzing the GraphQL schema and generating documentation based on the information in the schema. The GraphQL schema defines the structure of the data and the available operations, and it serves as the basis for generating documentation.

    Documentation generators typically follow a similar process:

    • Analyze the schema: The documentation generator analyzes the GraphQL schema to identify the available types, fields and operations.
    • Generate documentation: Based on the information in the schema, the documentation generator generates documentation in a specific format, such as HTML, markdown or PDF. The documentation typically includes information about the available types, fields and operations, as well as any associated documentation, such as descriptions or examples.
    • Include additional information: Some documentation generators may also include additional information, such as query examples, error handling information or performance considerations.
    • Update the documentation: The documentation generator can be run periodically to update the documentation based on changes to the GraphQL schema.

    Documentation generators for GraphQL are typically designed to be flexible and customizable so that developers can customize the generated documentation to meet their specific needs. For example, developers may be able to customize the format of the documentation, include additional information or exclude certain information.

    Documentation Generators for GraphQL: Why They Matter

    Documentation generators for GraphQL are important tools for DevOps teams for a number of reasons:

    • Efficiency: Documentation generators automate the process of creating and updating documentation for GraphQL APIs. This can save DevOps teams a significant amount of time and effort, particularly when working with large or complex APIs.
    • Consistency: Documentation generators can help ensure that documentation is consistent with the GraphQL API and up-to-date. This can help reduce confusion among developers and other stakeholders and improve the overall quality of the documentation.
    • Collaboration: Documentation generators can help improve collaboration among DevOps teams by making it easier to share and review documentation. This can help ensure that everyone has access to the most up-to-date information and that documentation is reviewed and approved by all stakeholders.
    • Accessibility: Good documentation is essential for developers who are working with GraphQL APIs, and documentation generators can help ensure that documentation is clear, concise, and accessible. This can help reduce the learning curve for new developers and make it easier for developers to understand and work with the API.
    • Scalability: Documentation generators can help DevOps teams manage the documentation of large or complex GraphQL APIs, making it easier to keep up with changes and ensure that the documentation is accurate and up-to-date.

    Conclusion

    In conclusion, by automating the documentation process, documentation generators can save time and effort for developers, reduce the risk of errors and inconsistencies in the documentation and provide a common source of truth for different teams and stakeholders. In addition, documentation generators can help DevOps teams better understand the API, improve collaboration and communication and speed up development cycles. 

  • Postman Releases Tool for Building Apps Using APIs

    Postman Releases Tool for Building Apps Using APIs

    Postman today made generally available a visual tool infused with artificial intelligence (AI) that makes it simpler to build software by invoking application programming interfaces (APIs) found on its network.

    Shamasis Bhattacharya, chief software architect for Postman API, said Postman Flows makes it possible to use a low-code tool to build software using tens of thousands of APIs that can be found on the Postman API network.

    The goal is to reduce the amount of toil required to build applications of moderate to medium complexity in a way that doesn’t require developers to have deep programming expertise, he added.

    Instead, developers are presented with “blocks” that they can drag and drop to create an application and deploy the associated workflows. Postman Flows leverages AI to manipulate data returned by APIs using a natural language interface that reduces the level of technical acumen required to create those workflows.

    That approach provides developers with a reactive experience that is embedded within a visual tool, noted Bhattacharya.

    Many developers still have a natural bias toward writing code, but as demand for applications continues to increase, Postman Flows provides a means to significantly increase developer productivity, said Bhattacharya. There may still be instances where writing code is required, but as developers save more time using Postman Flows, many of them will switch over to a visual tool to build software faster by essentially gluing blocks together, he added.

    There’s naturally a lot of focus these days on developer productivity during uncertain economic times. More organizations than ever are dependent on software, but their ability to hire armies of developers is limited. Low-code tools have emerged to provide a means for accelerating application development, but Postman is now looking to apply that concept directly to the network of curated APIs that it provides to application developers.

    The one thing that is certain is that as the pace at which applications are being built increases, the number of them running in production environments will steadily increase. DevOps teams will find themselves maintaining a wide range of applications that were constructed using both procedural code and low-code platforms.

    In the meantime, IT organizations may want to start evaluating which types of applications lend themselves to being built by development teams that may not require as much experience writing actual code. Much of the application development backlog organizations are struggling with today could be reduced using tools that automate a wide range of development tasks. That should free up developers with more advanced skills to work on more complex applications. That approach might also reduce developer turnover as much of the fatigue associated with building more routine applications is reduced.

    Regardless of how applications are built, there will be a need to manage them in production environments. DevOps teams may soon be able to focus more of their time and expertise on optimizing application performance in production environments versus continuing to shepherd massive amounts of code through continuous integration/continuous delivery (CI/CD) pipelines.

  • Understanding Cloud APIs

    Understanding Cloud APIs

    Six out of every 10 businesses had moved their workloads to the cloud as of last year. More steady traffic in the cloud and more direct cloud instances mean more to juggle–and the need for greater customization and integration. That’s where APIs come in. APIs are doing for the cloud what they did for on-premises resources: Segregating, simplifying, specializing and integrating services across a network–only this time, it’s future-proofing the architecture by building it in the cloud. As one cybersecurity researcher quipped, “Everyone wants to use APIs to build innovative solutions, but no one wants to invest in building them.” Cloud APIs will soon spell the difference between companies that can keep up with digitization and those that can’t.

    Ultimately, it will come down to which organizations take the time to understand them and use them to their best benefit.

    What is a Cloud API?

    Simply put, “a cloud API is a software interface that allows developers to link cloud computing services together.” APIs allow services to share functionality and information for other programs to use, and nowhere is this more important than in the interconnected ecosystem of the cloud.

    Because APIs act as a waiter in a restaurant, the better the waiter, the simpler ordering will be for you and for your customers. The best cloud API connects backend cloud components, services and platforms and does all the busy work so all your users see on the front end is a seamless customer experience. Since most of the work of tomorrow will be in the cloud (and is moving there in ever-increasing numbers), to not build up this functionality now is to take a deliberate risk.

    Types of Cloud APIs

    There are several types of cloud APIs based on the four major areas where cloud computing will require integration–either with another platform or another cloud provider.

    ● PaaS APIs (Service level): These platform-as-a-service APIs are designed to integrate with databases, portals, storage components and messaging systems, providing access and functionality in the cloud.
    ● SaaS APIs (Service level): Referred to as software-as-a-service APIs, these connect application layer resources with the cloud and underlying IT infrastructure. A CRM is a good example of where these types of APIs can be used to create a “cloud application extension” for your ecosystem.
    ● IaaS APIs (Service level): Infrastructure-as-a-service APIs control the distribution and deployment of specific cloud resources, performing such tasks as rapid provisioning and de-provisioning, network configurations and workload (VM) management in the cloud.
    ● Cross-platform APIs: Because many environments use multiple cloud providers and platforms, cross-platform compatibility is required. Cross-platform APIs streamline data management by allowing tenants to access their cloud-based resources and workloads from any of their cloud providers, not just their primary one. They provide a higher level of abstraction by translating a specific provider’s API calls into a more generic form, making accessibility, manageability and interoperability in the cloud easier.

    Cloud API Security

    In many respects, the security threats faced by cloud APIs are the same that any cloud-based resource would encounter and present the same challenges. That being said, malicious API traffic surged over 117% last year, from an average of 12 million to over 26 million calls, according to one industry report. The same study revealed that over a third of respondents experienced authentication and data exposure-related incidents with their APIs, and 54% delayed rolling out a new application because of API security concerns.

    Unguarded, a cloud API could present the keys to the kingdom and allow an attacker to access the hub of not just one but several cloud providers and their workloads, resources and assets. Protecting cloud-based APIs with standard authentication and authorization practices such as OAuth2.0 and OpenID Connect can reduce the chance of a lateral attack.

    Why Cloud APIs

    Cloud usage is not set to slow down and will soon become ubiquitous. Companies that aren’t on it are migrating their workloads in greater numbers and entrepreneurial ventures are spinning up as cloud-native. Cloud APIs are simply the logical response to the complexities that come with the terrain. Without cloud APIs, the user experience will be negatively impacted and will only become more apparent when compared with companies that do use cloud APIs.

    For companies looking to innovate in 2023 and release new applications, APIs are the way to cut-and-paste the process safely. Similarly, as more cloud-based services become API-reliant, application reusability is another factor requiring cloud APIs. And lastly, the complexity of cloud products, platforms and ecosystems (even within one organization) makes cloud APIs a necessity for smooth interoperability. And they help with scalability–multiple components of a cloud-based service can be parsed out, updated and patched individually and refined separately so that one area can develop without being dragged down by the whole. Cloud APIs allow for that granular level of customization that can help an organization refine its edge.

    Simply put, organizations will need these APIs to not only compete but stay relevant as businesses continue to take their fight to the cloud.

  • Five Tips for Moving IT Ops to DevOps

    Five Tips for Moving IT Ops to DevOps

    The era of siloed development and operations functions is rapidly coming to an end. The concept of DevOps has already closed the gap between IT and developers, but as I speak with customers around the globe, one theme continues to arise. Many systems administrators are ill-equipped to handle the shift from IT Ops to DevOps and, in some cases, don’t even know the right questions to ask to ensure they are planning accordingly.

    Having the appropriate equipment and software in place means nothing without people trained and ready to implement the shift from IT Ops to DevOps. As IT strives to support and protect developers continuing to innovate with wild-west-style creativity, how can we empower them with the tools and knowledge to ease the transition? This starts with asking the right questions, but requires IT to think about new things: Automating processes, revamping config management, building efficiencies in data orchestration and standardizing a set of APIs with enterprise-level protections.

    Asking the Right Questions About DevOps and Infrastructure-as-Code

    Enterprises need to look holistically at how infrastructure services are created, delivered and managed. Continuing current practices, such as manual provisioning complicated by different interpretations of imprecise instructions, will continue to lead to snowflake architectures and brittle systems. Organizations must modernize or replace this existing infrastructure to exploit cloud architectures and implement true platforms, actualizing the promise of the cloud.

    Infrastructure-as-code is an underlying framework that removes the manual process of managing and provisioning resources and opens doors to enabling DevOps. Using code to define the infrastructure configuration means that there is greater consistency between platforms. That consistency allows IT to seed the agile processes, methods and technical approaches needed to evolve a DevOps culture.

    To get to a point where infrastructure-as-code is facilitating a DevOps culture, it’s important for IT Ops to understand how to develop an early-stage continuous delivery and deployment pipeline. They also need to begin to seed practices and values native to DevOps for software engineering principles and practices with IT Ops. It’s also important to define success criteria–referred to as the “definition of done” in agile and begin to think about how to implement the infrastructure-as-code using DevOps best practices.

    Don’t Expect Developers to Become Expert Sysadmins

    Developers don’t want or need an extra layer of oversight or management, nor do they want to ask for permission before doing what they do best: Innovating. DevOps can more rapidly provision compute and storage resources and provide infrastructure-as-code while automating DevOps processes, empowering developers to become an innovation engine for their businesses.

    So much of what we’ve seen puts pressure on IT to be proactive when protecting developer cycles in containers and beyond. The NSA, as well as other industry data protection companies, offer tips for IT to stay ahead of these threats, but manual patching and scanning is not only handcuffing IT but stifling innovation in DevOps. The challenge is that IT can’t move as fast as developer cycles and often lose sight of what developers are putting into containers or other IT environments.

    While global data protection restrictions might have an impact on things like machine learning and AI from a consumer experience standpoint, it does not affect how IT might use these technologies to automate protection. It’s also not about extending protection to developer workloads, it’s about having an environment that recognizes and automates protection against threats in all environments. This way, developers and IT don’t have to become system admins or data protection experts. They can focus on the innovation at hand.

    Config Management is Critical to Empowering Developers

    As we continue to prioritize the automation of processes in the developer environment, it’s also important to consider how to move beyond just automating protection and infrastructure while allowing IT Ops to still have an eye on identifying, documenting and tracking changes in the DevOps stack. To do this, DevOps should look to configuration management tools to help manage and automate the architecture through strong community support, customization, scalability and the simplification of complex configurations.

    These tools, such as Ansible, Terraform, etc., can be deployed to meet specific needs and preferences. The point is, once you create infrastructure-as-code, you need a way to configure and manage it that fits the model that’s appropriate for your business. While you can use IaC to configure and manage, you still need to determine how to best implement automation and configuration in the most appropriate environment.

    Data Orchestration Eliminates Repetitive Cycles

    Data orchestration tools bring all data together regardless of where it originates or its format. An ecosystem that can collect data efficiently and convert it to a format that is easily understood by any and all endpoints is critical to the app development process. There’s no need to iterate at multiple levels, on multiple platforms or in different environments. IT can enable developers to innovate and learn from any environment, data warehouse or platform and build applications that can do the same.

    In the same way data orchestration can drive efficiency, there are additional benefits. Automating the collection, analysis and formatting of data saves IT countless hours of doing these processes manually. While there are obvious cost benefits, there are also a few other important benefits.

    To allow developers to continually innovate at a wild west pace, IT/DevOps must also ensure they can meet data privacy compliance and governance policies. Data orchestration allows businesses to delete or store data based on policies preset in the environment. It also allows businesses to ensure that internal policy is upheld throughout the development process. Orchestration then takes that data and makes it workable so that any iterative process can be applied without fear of bottlenecks or additional cycles.

    Standardized APIs Trump Those Created by Unaffiliated Coders

    Today’s developer profile expands far beyond the enterprise. In fact, according to Developer Nation, we can expect a whopping 45 million developers in the world by 2030. These numbers don’t include the unaffiliated coders working out of their basements or garages. That’s not to say that creativity isn’t appreciated or eventually adopted by industry leaders. But the code and software created don’t necessarily abide by enterprise governance and privacy standards. Yet we continue to see wild west developers pulling in anything and any kind of API to ensure it meets the needs of the next business application they are developing. How does IT police this?

    They don’t have to. For IT/DevOps to identify a set of APIs that meet business imperatives and certify them for use within the organization is imperative. Think about a scenario in which a developer has not only a comfortable environment to sit in without learning new skills but also an environment that automates protection, orchestration and gives them a preset library of helpful and open APIs. Businesses can begin to focus on delivery rather than policing and upskilling developers to work within the confines of the business ecosystem.

    As data continues to flow in and out of organizations and more data is being created and stored at the edge, a DevOps culture built for tomorrow’s developers is critical. These tips are a great starting point to ensure you’re installing a future-proof culture of innovation. What are some of the obstacles you’ve faced and overcome during the transition to DevOps?

  • The API Economy: Increasing Potential to Monetize Public APIs

    The API Economy: Increasing Potential to Monetize Public APIs

    API-first strategies are becoming more commonplace throughout today’s digital strata. APIs connect microservices architectures, power new digital transformations and help development teams avoid reinventing the wheel for common functions. And although most are built to connect internal components, studies indicate a movement toward more externalization and monetization of public APIs.

    Over three-fourths of developers now view participating in the API economy as a priority for their organization or plan to prioritize it soon, found Rapid’s newly released 2022 State of APIs report. The survey, which surveyed hundreds of professional developers, also uncovered a modest increase in companies seeking to generate direct revenue from APIs.

    Below, we’ll review some intriguing statistics from the Rapid report and consider the major takeaways technology professionals should consider in the year ahead.

    API Reliance Increases

    Reliance on APIs is rising across the board. Over 62.6% of developers reported relying on them more in 2022 than in 2021. Internal APIs help avoid development duplication and third-party APIs can quickly integrate standard functionality related to payments, messaging, geolocation, data sharing and many more areas. For example, ChatGPT has demonstrated the power of standard APIs to deliver advanced AI/ML to the masses in a programmatic way.

    As a result of this interest, the majority of organizations now consider participating in the API economy as a top priority. And as an organization grows larger, its reliance on APIs is likely to increase. A full 40% of the largest companies surveyed reported having more than 250 internal APIs. Nowhere is this more prevalent than in financial services. This finding makes sense, given how APIs can automate payments and underpin the open banking movement.

    In terms of who is using APIs, it’s most commonly full-stack or backend developers, the report found. One intriguing factoid is just how much of this work is now dominating developers’ time. Impressively, 65.5% of developers reported spending ten hours or more working with APIs in their job; 14.5% of them said that work takes up all of their time.

    In terms of design styles, various standards are used throughout the web development sphere. Yet REST is still king—69.3% of engineers used REST in production. REST is followed by webhooks, WebSockets, AsyncAPI, serverless and FaaS, SOAP, GraphQL, Kafka and gRPC, in descending order of popularity. Across the board, these statistics showed a steady increase from last year.

    Of note is that most APIs are built for internal purposes. These often wrap a database or provide open access to an internal microservice. Private use cases are by far the most common approach; according to the report, 75.1% of respondents worked on internal APIs. These findings aligned with other industry reports, such as the Postman State of the API Report, which found that, in 2022, 58% of API initiatives were private.

    Third-party APIs (53.9%) and partner-facing services (48.9%) trailed behind internal APIs in popularity. Interestingly, while internal use cases have remained steady, both partner and public-facing strategies have increased since last year. While the growth was a modest 5% for most sectors, partner-facing APIs in some industries grew by nearly 10%.

    Spotlight on Monetization

    Many still view APIs as operational glue for internal data or connecting partner services. Yet, the possibility of monetization through self-service developer portals shouldn’t be overlooked—countless API-first startups are actively gaining traction and funding. And monetizing this power is seen as a holy grail to some unicorn-chasing VC funds.

    Most APIs are purely for in-house internal integrations and are typically not externalized to the outside world for profit. However, this is slowly changing. In fact, 42.6% of organizations are now monetizing APIs, representing an increase of about 5% from 2021.

    As one may have guessed, financial services are leaders in monetizing their external APIs. The telecommunications industry is also noticeably active in monetization, too. Furthermore, with size comes increased monetization potential—about half of the companies with a large footprint of ten or more internal or external APIs also monetized them.

    API Economy in 2023

    Looking to the future, most anticipate more reliance on APIs across sectors — 69.2% expect to rely on APIs even more in 2023. Yet, organizations will have to grapple with particular hurdles in this newfound landscape. For example, a cloud skills gap might bar some groups from realizing the benefits of an API strategy. Other concerns include ungoverned sprawl, authorization concerns, shadow APIs and escalating attacks on public-facing endpoints. Also, some organizations are still determining how to best secure and scale their use of new styles, like GraphQL.

    A standards-based approach that applies platform-wide governance will likely be necessary to maintain an efficient yet stable API footprint. To meet these high quality standards, testing is nearly universally applied—92.7% of those surveyed test their APIs or plan to do so. The most common tests ranged from functional testing to integration testing, acceptance testing and performance testing.

    The Rapid 2022 State of APIs report received 850 responses from over 100 countries. For more insights, readers can view the complete results here.