devopsy.kinsta.cloud

Tag: APIs

  • Why GraphQL Will Reign King

    Why GraphQL Will Reign King

    After years of development, GraphQL is set to reign as the go-to API for data fetching. But what is GraphQL? Simply put, it’s a query language that allows you to fetch data from any server, and it’s a noteworthy alternative to the likes of other web service development styles like representational state transfer (REST) and simple object access protocol (SOAP). There are a few reasons why GraphQL will dominate the DevOps world, including its overall efficiency, ability to work with any server and overall ease of use.

    Understanding GraphQL

    GraphQL is a query language for APIs and a runtime for fulfilling queries with existing data. GraphQL provides a complete and digestible description of the data in an API, gives clients the power to ask for exactly what they need, makes it easier to evolve APIs over time and enables powerful developer tools.

    Top Benefits of GraphQL

    GraphQL addresses many pain points that often slow down developers, who prioritize adaptability and working quickly and efficiently when building applications.

    For one, it is much more flexible than other data query languages, allowing users to specify exactly what data they want and in which format. Other data query languages require users to retrieve all data in a specific format, regardless of whether they actually need the data. That excess, unnecessary intake can cause delays and confusion.

    GraphQL’s ease of use is also invaluable, thanks to its simple and intuitive syntax. The language is strongly typed, which means developers can catch errors early on in the development process before code goes into production. This can save much-needed time and money in the long run.

    Another benefit is that it can be used to fetch data from multiple sources because it uses a schema that defines the different types of data available. This means if a developer has a field in a schema that could potentially return data from multiple sources, they can specify which source to fetch the data from. Developers don’t get this benefit from other data query languages, which often allow data fetching from only a single source.

    Advantages for DevOps Teams Over Other Data Query Languages

    As the world of software development continues maturing, so do the tools and technologies DevOps teams use to build and operate their applications.

    REST and SOAP are popular web service technologies, but they come with some major drawbacks. Notably, both REST and SOAP rely heavily on URL structures and verbose XML payloads, which makes it difficult to evolve the API without breaking existing clients. And because each endpoint is a unique URL, providing a consistent experience across different parts of the API can be challenging. REST and SOAP are also quite chatty and can make it hard to optimize performance.

    In contrast to REST, GraphQL provides a single endpoint for all data requests and is much faster than making many HTTP requests. GraphQL’s declarative query language specifies precisely the data needed – no more, no less – increasing bandwidth and improving performance. Applications can run faster and use fewer resources, which is especially important for mobile apps that need to be lightweight and fast.

    Understanding the data is crucial for DevOps teams, and GraphQL allows developers to visualize data in a graph. Teams can see the relationships between different points more easily, leading to better-informed decisions about the best ways to manipulate the data.

    The increased efficiency when conducting API calls is also a plus with GraphQL, which helps teams retrieve all information they need with a single API call. Traditional REST APIs often require multiple API calls, mainly because each resource in a REST API is represented by its own unique URL, along with its own set of permissions and data that needs to be retrieved. GraphQL can eliminate this bottleneck.

    Overall, dealing with complexity is significantly reduced when developers use GraphQL. When using traditional REST APIs, writing a lot of code to handle different edge cases and error conditions is the norm. But GraphQL streamlines this – much of the complexity can be handled by the server itself, making way for simpler and more maintainable codebases. DevOps teams are also able to decouple their front-end and back-end development efforts by using a schema-based approach. GraphQL enables frontend and backend components to be developed separately without worrying about breaking changes, which means faster development cycles and fewer errors.

    The amount of data that organizations need to understand, organize and query will only increase in the coming years. DevOps teams can get ahead of the ongoing data and information onslaught by taking advantage of GraphQL and its unmatched ability to provide an efficient, powerful and flexible API for data fetching and manipulation.

  • 5 GraphQL Trends to Watch in 2023

    5 GraphQL Trends to Watch in 2023

    The GraphQL query language had a big year in 2022. We witnessed its increase in production use cases, solving overfetching and underfetching concerns that plagued traditional API integrations. GraphQL can significantly improve usability, aggregate multiple services and optimize how data is ported from system to system.

    Yet, GraphQL is also prone to new security concerns. And as attacks on APIs continue to increase and grow in sophistication, an increased security focus will undoubtedly be required to avoid vulnerabilities. The coming year will likely also see architects grappling with their GraphQL maturity as they consider how best to scale its use across an organization and its various stakeholders.

    Below, we’ll consider where the tides are flowing for GraphQL in 2023. These forecasts are informed by my coverage in 2022 and reports from within the web development community.

    1. Increased Production Use

    A full 62.6% of developers reported relying on APIs more in 2022 than they did in 2021, according to RapidAPI’s State of APIs report. As the number of APIs in use expands, we will undoubtedly see more GraphQL examples. GraphQL is popular due to its usability and flexibility which outweighs traditional integration points. Studies showed it is primarily used for exposing internal data, although partner and public use cases are not uncommon.

    Representational state transfer (REST) remains a dominant style for modern APIs. According to Postman’s 2022 State of the API report, 89% of developers use REST. GraphQL is in fourth place at 38%, superseded by webhooks (35%) and SOAP (34%). Although usage remains small in comparison, it’s steadily gaining traction and will continue to expand.

    2. Unifying Disparate APIs

    GraphQL helps expose fields in an easily consumable manner. But it’s also good for aggregating disparate microservices into a unified schema. As such, it is often used as a meta layer that combines multiple REST services, databases and even GraphQL schemas. For the time being, it appears that REST has staying power. And it’s unnecessary to migrate all REST services to GraphQL. Looking to the future, it is more likely to be adopted as a layer on top of existing REST APIs.

    Combining multiple backend services under the hood and exposing them in a unified schema creates a more usable, localized interface that frontend developers can work from. In the future, GraphQL might become a meta layer for more organizations, increasing the discovery of internal services and helping teams reuse internal microservices.

    3. Supergraphs and Subgraphs

    As mentioned above, GraphQL is used not only to combine legacy REST services but also to combine multiple GraphQL schemas. Some call this a graph of graphs—or a supergraph. A supergraph that combines multiple GraphQL schemas would offer unparalleled developer experience in that engineers can access many services from the same endpoint.

    However, there’s a downside to centralizing with a unified graph. Different internal teams or partners might only need access to a particular set of functions. Giving the entire schema to every person who walks through the door would be TMI, not to mention a potential security risk that breaks the rule of least privilege. So, the idea of a subgraph has gained traction. A subgraph is an Apollo concept, but the theory could certainly be applied in other implementations. In the future, we’ll likely witness more use cases that use subgraphs to help federate a supergraph across an organization, helping segment a graph to specific stakeholders’ needs.

    4. Turning on GraphQL Security Controls

    As of 2022, less than half (43.2%) of GraphQL implementations have disabled query introspection. Disabling field suggestions and introspection are means to reduce the risks of public GraphQL exposures. As GraphQL security best practices become more apparent, these numbers will likely become more commonplace. Other security controls, such as implementing query timeouts, query rate limiting and query cost analysis, can also help curb potential malicious behaviors.

    As we’ve covered before, security by obscurity is not enough to protect GraphQL. Yet, many native GraphQL security and performance directives go unused. Besides turning on these advanced features, new tooling is coming to market that could harden GraphQL. Security vendors continue to add support for GraphQL, making its protection more accessible for non-security engineers.

    5. Managing GraphQL at Scale

    GraphQL has arisen in some large production use cases in recent years, helping developer usability at GitHub, boosting productivity at Netflix and aiding Shopify’s API strategy. These case studies proved its usefulness in large enterprises. But how do we effectively scale GraphQL across a massive organization?

    The concepts of supergraphs and subgraphs are ways to help scale it across a company. But retaining high performance will also be vital to maintaining an effective, scalable footprint. As such, we will likely continue to see companies optimize how GraphQL is used as it matures. This includes optimizing queries and query depth and applying filtering and rate limiting to fit application demands. Taking measurements of GraphQL response times will be necessary to establish benchmarks to improve over time.

    We’re Just Querying the Surface

    Above, we’ve only scratched—or queried—the surface of the exciting developments on the horizon for GraphQL in the coming months. There is much more to be said regarding updates to the query language and improvements within the surrounding tooling landscape. Where do you think GraphQL will go in 2023? Let us know in the comments below!

  • Survey Sheds Light On Cloud, API Expertise Skills Gap

    Survey Sheds Light On Cloud, API Expertise Skills Gap

    Enterprise IT faces a three-pronged onslaught: Digital transformation, open APIs and security threats. First, most organizations are still navigating ongoing digital transformations and cloud migrations. Second, development teams continue to increase their use of open APIs, leading to sprawl concerns. And third, we’ve witnessed a slew of cybersecurity threats that appear to be growing in sophistication. Tech leaders are attempting to govern this influx of new tools and risks, yet it can be challenging to innovate quickly while ensuring that sensitive data is always protected.

    The Axway 2022 Open Everything Survey shed light on some of the above challenges and attitudes of those invested in API development and API-enabled managed file transfer (MFT). Most notably, the survey found that 86% of respondents feared an expertise gap in the coming years, in which their organization won’t have the skilled software and IT infrastructure talent they needed to innovate. Below, we’ll review other findings from the survey, focusing on the responses from those who indicated they’re invested in API development.

    Cloud Migrations Are Still Underway

    Digital transformations are still underway in the vast majority of organizations. Only 12% reported being wholly digital and leading innovation. The rest were either just beginning transformations, were midway through or were still largely brick-and-mortar. More than one-third (38%) also said their company’s digital makeup is a hybrid of old and new technology.

    The most-adopted computing environment is the public AWS cloud, at 47%. Yet other options trailed close behind, including hybrid (37%), managed cloud services (32%), Azure (28%), private (25%) and Google Cloud Platform (18%). Other reports substantiated how modern IT is becoming increasingly hybrid and multi-cloud. As digital journeys continue to shift and evolve, some organizations are embracing multiple fit-for-purpose clouds.

    Although multi-cloud offers unparalleled flexibility, the primary drawback is security. Just over half (55%) of respondents said that tracking and controlling the flow of personal data into and through the cloud is a key hurdle to a multi-cloud strategy. And 53% reported that dealing with different security requirements for regional instances of cloud infrastructure was a top challenge. This concern is warranted, as companies doing business internationally must carefully navigate many specific regional data regulations.

    Open Data Strategies Abound

    As the Open Everything name indicates, many different sectors are becoming more “open.” The report highlighted the adoption habits of APIs within supply chains, where they are most often used to configure applications, operate and monitor applications and integrate internal data sources. Popular use cases here included payment and tracking systems. APIs also have a significant role to play in the financial world—41% of those working in finance said open banking is an opportunity to discover new business models. But nowhere is the need for more open data more crucial than in health care, which was found to be the area most in need of digital transformation.

    We’d like to think of the API revolution as being driven by API-first startups and SaaS services. While these trends get attention, it’s not the most common use case for APIs. In fact, 44% of the time APIs are used to support IT consulting and system integration requirements. This is followed by providing cloud applications for customers (35%), developing a partner network (35%) and offering cloud services for customers or partners (34%). Although there are certainly business use cases for generating revenue through APIs, they are most often adopted to supplement existing platforms or to glue together internal services and data.

    Most Technology Leaders Fear API Sprawl

    Security is an encompassing concern for all walks of IT, but is especially top-of-mind when opening up data. Respondents said security is the most important concern when creating APIs (30%). This concern is warranted, as attacks on APIs have increased exponentially in recent years. Other top concerns are API adoption or consumption (15%), customer experience (14%), ease of API management (14%) and design and development (11%).

    As APIs and microservices become more abundant within an organization, it’s easier for sprawl to set in. Unbridled technology sprawl can have a deteriorating effect on design standards and lead to unknown shadow APIs that may pose a security vulnerability. As a result, over two-thirds of respondents said the prospect of API sprawl worries them.

    To mitigate sprawl and address other concerns, most companies are investing in tools to help manage the growing number of APIs. The majority (83%) said their budget for API management has either increased or stayed the same over the last two years. For 18%, this budget has risen by over 25%. Operationalizing API life cycle management capabilities can have benefits such as standardizing design style and increasing the discoverability of internal services.

    API Security Must Still Mature

    In a perfect world, we could share data without fear of misuse. But in reality, APIs are a common target for hackers. Publicly exposed endpoints with broken access control or missing object-level authorization can be easily abused for things like privilege escalation and data exfiltration. And although these risks persist, many APIs don’t adopt industry best practices regarding API security.

    Although most APIs use authentication and token schemes, under half (43%) implemented OAuth. Furthermore, only 30% implemented policies with an API gateway. OAuth 2.0 and gateways have become best practices in serving APIs, as there are too many vulnerabilities to rely solely on HTTP Basic Authentication and API keys. As such, we will likely see these adoption rates increase as API security matures.

    As with other cybersecurity endeavors, it’s really about taking a holistic perspective and applying defense-in-depth. Thankfully, most technology professionals understand this point—developing a more holistic approach to security was ranked as the top strategy for protecting personal data. Other strategies, like data encryption, advanced multifactor authentication, data loss prevention tools and highly-secured data transactions will also be necessary to protect cloud-native assets.

    Final Thoughts

    The Axway 2022 Open Everything Survey asked 1,000 IT leaders, architects and developers about their top concerns. Above, we focused on results from technology leaders engrossed in cloud and API development. For more insights and the findings from those using managed file transfer (MFT), readers can pick up a copy behind an email gate here.

  • Intel Expands Scope of oneAPI Initiative

    Intel Expands Scope of oneAPI Initiative

    Intel has expanded its effort to drive adoption of a set of open compilers, libraries, analysis and porting tools and frameworks for artificial intelligence (AI) applications, collectively made available via a oneAPI initiative, to include support for its latest generation of processors.

    The oneAPI initiative was launched more than three years ago to create a set of multi-architecture tools for building applications that could be deployed on any CPUs, graphical processor units (GPUs) and field programmable gate arrays (FPGAs). Processors that now support oneAPI include forthcoming 4th Gen Intel Xeon Scalable processors, Intel Xeon CPU Max Series and Intel Data Center GPUs.

    James Reinders, chief evangelist of Intel Software Products, said there is now a clear need for open tools and frameworks that provide equal access to multiple classes of processors. As part of that effort, the latest 2023 version of oneAPI, for example, adds support for plug-ins for Nvidia and AMD GPUs developed by Codeplay, a unit of Intel, to simplify writing SYCL code in a way that makes code portable across additional processor architectures.

    There is also a CUDA-to-SYCL code migration capability that supports more than 100 CUDA application programming interfaces (APIs) using the Intel DPC++ Compatibility Tool based on an open source SYCLomatic project. Intel is also providing tools to identify imbalances at scale using Intel VTune Profiler, and an Intel Advisor tool now provides automated roofline analysis for Intel Data Center GPU Max Series to identify root causes of memory, cache or compute bottlenecks along with insights for optimizing data transfer costs involving CPU-to-GPU offloading.

    As IT continues to evolve, it will become more routine for developers to invoke heterogeneous classes of processors within the same application, but it’s been challenging to convince providers of other types of processors to support the oneAPI initiative, noted Reinders. Processor providers have historically relied on compilers and libraries to lock developers into specific classes of processors.

    However, it’s becoming more common for developers to build applications that invoke multiple types of processors. The Intel oneAPI initiative is intended to simplify access to heterogeneous processors, also known as XPUs. That’s critical, because the pace of processor innovation has accelerated to the point where developers need to be able to invoke additional capabilities without waiting for specific compilers and libraries to be updated by multiple providers. Once oneAPI is more widely adopted, it then becomes possible to significantly lower the cost of application development and deployment, noted Reinders.

    It’s not clear whether the oneAPI initiative will become more widely adopted, either under the auspices of Intel or by some type of industry consortium that provides a neutral venue for building a common set of compilers and libraries. The one thing that is certain is that DevOps teams are vested in trying to standardize compilers and libraries across as many platforms as possible. The challenge, of course, is making sure developers only invoke compilers and libraries that can span multiple classes of processors versus ones that may have been optimized for a specific type of processor architecture.

  • Key Findings From the 2022 State of GraphQL Report

    Key Findings From the 2022 State of GraphQL Report

    GraphQL, the open source query language, has been steadily growing in popularity over the past few years. The language is excellent for frontend development, as it creates a usable interface to fetch precisely the data required for the specific client at hand. You can also use it to aggregate multiple backend services and data sources.

    Studies show that the ecosystem around GraphQL is maturing—it has a very global user base and a growing number of tools exist to aid in its adoption. The 2022 State of GraphQL Report found that 61.8% of developers are happy with the overall state of the ecosystem. Yet many native GraphQL features go unused by developers, which suggests there is a wide range of experience levels, from novice to advanced users, working with the technology. This indicates there is plenty of room for growth and knowledge sharing.

    Below, I’ll review the key takeaways from the 2022 State of GraphQL Report, considering overall usage data and focusing on the popularity of specific features. We’ll also highlight the state of standard tools used in conjunction with GraphQL to get the job done.

    Analyzing Overall Usage Statistics

    First off, there is a wide variance in the types of GraphQL APIs in production today, ranging from private to public endpoints. The report found 47.9% of developers use GraphQL for exposing an API intended for a personal website or app, 40.4% use it for private unexposed APIs for internal usage and 19.5% use GraphQL for publicly available APIs intended for third-party developer consumption. This demonstrates its flexibility to cater to multiple scenarios. And while the majority of clients that connect to GraphQL APIs include browsers (62.3%), it’s commonly consumed by other client types such as native mobile apps, other servers and desktop apps.

    Previously, we discussed using GraphQL as a composition layer to combine underlying APIs and services. And the report backs up this idea that developers commonly use it to aggregate various data sources: 55.4% of GraphQL APIs hit databases, while 35% consume REST APIs and 14.6% eat other GraphQL endpoints.

    In terms of benefits, one strong point is the ability to enforce and validate types for every object in the API. Users find other top benefits to be avoiding overfetching and aggregating requests. Yet, some hurdles still present themselves. These top drawbacks include error handling, performance issues, client-side caching and security woes.

    Regarding user base statistics, most users have been working with GraphQL for less than five years. If we look at the type of sector utilizing GraphQL, we see it primarily leveraged in the programming and technology sector. This is followed by e-commerce and retail (16.4%), finance (8.9%) and news, media and blogging (7.2%).

    Many Advanced Features Go Unused

    Many of the more advanced GraphQL features still go unnoticed by the majority of users. For example, live queries is a feature that helps obtain live data from a GraphQL server, yet only 25% who know about it have used it. Over half of respondents had never heard of @skip, a directive that skips a field based on a value passed to it. Similarly, other directives like @specifiedBy, @defer and @stream also share little-to-no awareness or use.

    Analyzing feature usage becomes a bit more serious if we consider the unadopted security and performance features. For example, only 43.2% of respondents have disabled query introspection. Disabling query introspection is a suggested security best practice to limit a hacker’s ability to perform surveillance. But as we’ve previously covered, security by obscurity isn’t enough to protect GraphQL, and an additional security emphasis is often needed.

    As most GraphQL APIs are intended for personal or private scenarios, you would think that more security features would be leveraged to limit the threat of introspection and denial-of-service attacks. Yet, the report discovered low usage and awareness of security and performance features like query timeouts, query rate limiting and query cost analysis, all of which could be turned on to curb malicious behaviors.

    Tools Used In Conjunction With GraphQL

    Developers often seek to combine, aggregate or merge GraphQL schemas from different APIs. To do so, Apollo Federation is the most common solution, used by 22.5% of respondents. This is followed by Schema Stitching (16.9%), GraphQL Modules (4.4%), and GraphQL Mesh (2.9%).

    Looking at other technologies used in connection, Next.js is the most popular framework and PostgreSQL is the most common database used. TypeScript and JavaScript comprise the most common languages used to write a GraphQL backend. Developers also use a balanced mix of IDEs to query and test endpoints, including GraphiQL, GraphQL Playground, Postman, Apollo Studio, and Insomnia.

    The report also found relatively high usage and retention for tools like the GraphQL Code Generator schema builder, Apollo Client and Apollo Server. The data shows a crowded solution market with Apollo as an industry-leading outlier—many other clients, servers, API generators and schema builders have medium-to-high retention rates yet experience far less use.

    Final Thoughts

    The 2022 State of GraphQL Report sheds some interesting light on the state of GraphQL, validating a lot of the interest and trends we’ve covered lately on the blog. Of course, there is more to be said about many areas, such as smoothing the transition to GraphQL.

    One key finding is the low number of security features being leveraged by developers. A greater emphasis on API security is required to avoid incidents and retain a zero-trust approach. This emphasis is part and parcel of responding to ongoing software supply chain threats and will require more awareness and thought leadership around GraphQL security best practices.

    The 2022 State of GraphQL survey ran from June 15, 2022, to July 15, 2022, and collected 3,094 responses. The above analysis only scratched the surface and there are many other insights. For more findings, you can read the full results here.

  • Open Banking Shouldn’t Be Open Season on Your APIs

    Open Banking Shouldn’t Be Open Season on Your APIs

    Open banking has become the latest technological advancement for financial services applications that’s modernizing the industry. For instance, Mastercard recently began its Start Path Open Banking program, which provides select startups the opportunity to use Mastercard’s expertise while learning how to apply open banking to their own business. Open banking is creating new opportunities for revenue sharing and reducing data licensing and transaction fees between financial institutions and their partners. 

    Customers who take advantage of open banking also gain a more comprehensive, holistic view of their finances so they can be in a stronger position to manage their wealth. Just as importantly, open banking will provide more opportunities to use data for products and loyalty programs across the full spectrum of their organization’s offerings. Financial services companies like Mastercard also believe that open banking programs improve inclusiveness and financial literacy. With greater financial literacy, customers can work to lessen the chances of fraud in their accounts. 

    This follows an overall trend of breaking down barriers when it comes to connecting financial organizations with consumers through new, innovative financial technologies. In fact, 96% of consumers globally are aware of fintech services, including at least one money transfer and payment. Additionally, U.S. consumers are steadily adopting new fintech, including peer-to-peer payments. 

    While open banking has the potential to shake up the foundations of the banking industry, there is also the possibility of it becoming a target for threat actors and cybercriminals alike. The reason: application programming interfaces (APIs) that power open banking are being targeted.

    Hazards Associated With Open Banking 

    Open banking uses APIs to connect financial institutions with third-party applications. The Open Banking Project is one of the leaders in providing open source APIs for banking and relies on an open source system for financial services providers to access consumer banking and financial data.

    Yet, the more financial services organizations rely on APIs, the greater their attack surface becomes. APIs, as the building blocks of today’s modern web applications, are already a big target for threat actors and a primary attack vector. Banks, and the financial services industry as a whole, are also targets for cybercriminals. 

    IBM’s X-Force Threat Intelligence Index 2022 noted that finance and insurance organizations were the second-most targeted industries. Further, IBM also found that among those attacks, 70% were against banks and 14% were against other financial organizations. This tells us that while other organizations might make the data breach headlines,  banks and financial institutions are most often under attack by threat actors and cybercriminals. While one of the major drivers for this is financial gain, there is also a wealth of data in banking, including personal identifiable information (PII), payment card industry (PCI) data, account and payment information. Much of this can be leveraged on the dark web for financial gain. 

    Unfortunately, attacks on financial institutions and the APIs that drive much of our engagement won’t change anytime soon. The problem associated with APIs is that, if left unsecured, they can provide threat actors a foothold into sensitive data that can be  exploited. Additionally, many organizations don’t have a true understanding of how many APIs they have (many are interconnected) or how these vulnerable endpoints are being protected. It is incredibly difficult to protect something that you don’t even know exists! Adding an additional layer of complexity to the API conundrum is how third-party APIs are often relied upon. Using these sources, while potentially a time-saving strategy, can leave your networks open to attack. 

    Secure Open Banking Means Protected APIs

    If you’re a company that plans to start taking advantage of open banking, it’s important to mitigate some of these threats by establishing sound API protection strategies. First, gain visibility into your entire attack surface. After all, knowing yourself, including your APIs and web apps, along with understanding your enemy, will lead to success on the battlefield (to paraphrase Sun Tzu). Once you have a comprehensive view of your endpoints, including those older and deprovisioned APIs, you can be in a better position to protect against the multitude of threats that they face. Ideally, you will be able to get real-time analysis of traffic hitting your endpoints so you can get a more holistic view of a surface that is always changing. 

    It should also be emphasized that sophisticated attacks consist of bot armies generating API traffic and attacks. Malicious bots are being leveraged on an ever-growing basis in attacks, including DDoS attacks and account takeovers. While many bot attacks are automated, being able to detect and block them in real-time, when combined with continuous monitoring, can help to lessen the threat posed by bots.  

    A future with open banking is an exciting prospect due to the fact that it will put financial control back in the hands of businesses and consumers. While there should be a reasonable amount of caution placed in many of the API-centric open banking solutions, there are ways to alleviate these concerns. Strong API security, along with bot blocking and detection, can go a long way toward protecting against modern threats.

  • Microsoft Expands DevOps Portfolio in the Cloud

    Microsoft Expands DevOps Portfolio in the Cloud

    At the Ignite conference this week, Microsoft launched a slew of updates to its DevOps portfolio as part of an effort to make it simpler to build, manage and secure cloud applications.

    Microsoft is adding Azure Deployment Environments, available in preview, that enable developer teams to invoke a set of best practices to quickly spin up application infrastructure using project-based templates.

    Microsoft is also making generally available Visual Studio Image for Dev Box, a self-service environment for accessing workstations on the Microsoft Azure cloud. Those images make it simpler to access Visual Studio functions and complimentary tools. Microsoft has also made generally available the latest version of the Visual Studio 2022 application development platform.

    In addition, Microsoft has signed an agreement with Postman to collaborate on integration that promises to accelerate the development of application programming interfaces (APIs) starting with the ability to both import and export APIs from Azure API management into Postman.

    Microsoft is also making generally available a predictive tool that employs machine learning algorithms to automatically scale virtual machines on Azure. In addition, updates to the Azure Monitor Log service now make it possible to ingest logs at a fifth of current costs and archive them for up to seven years. ​​​​​​​Microsoft is also now providing tools to migrate from legacy log agents to the Azure Monitor Agent (AMA) and has added Java profiling with a Java Flight Recorder (JFR) tool that collects data from a Java virtual machine and Java applications.

    In terms of managing application environments, Microsoft has now extended the reach of Azure Automanage to now include servers managed via the company’s Arc management platform, in addition to virtual machines running on the Azure cloud. Other capabilities added to Azure Automange include enhanced backup settings and different auditing modes for the compute server baselines and the ability to specify custom Log Analytics Workspaces and Azure tags to identify resources based on settings.

    Microsoft is also previewing an enhanced Azure remote support service through which Microsoft personnel will collect logs and commands to help resolve issues.

    Finally, in terms of securing applications, a GitHub Advanced Security for Azure DevOps tool that, now available in private preview, promises to make it simpler to identify and fix exposed secrets and vulnerable open source dependencies across the software life cycle using a CodeQL code scanner.

    At the same time, Microsoft is making available Microsoft Defender for DevOps to better secure code created to configure clouds. In addition, it will also enable DevOps teams to better prioritize their remediation efforts across multi-pipeline DevOps environments spanning multiple clouds. Microsoft Defender for DevOps is available in preview and supports GitHub and Azure DevOps with future support for other DevOps platforms planned.

    Another security addition available in preview is Microsoft Defender Cloud Security Posture Management (CSPM), which promises to provide contextual risk-based information via attack path analysis surfaced using a cloud security graph service to identify the most exploitable cloud resources. Microsoft has also made generally available a multi-cloud security framework for Microsoft Defender for Cloud to help organizations adopt DevSecOps best practices.

    Microsoft is also previewing support for agentless scanning for Microsoft Defender for Servers and an expansion of Microsoft Defender for Containers that adds support for Amazon Web Services Elastic Container Registry.

    Microsoft CEO Satya Nadella told conference attendees that Microsoft is making a concerted effort to natively embed security capabilities within its platforms to reduce the total cost of security. Many of the tools DevOps teams rely on today don’t integrate well, which is challenging at a time when application environments are becoming more dynamic as more cloud-native applications are deployed.

    It’s too early to say how much better security will entice organizations to opt for one cloud platform versus another. But it is almost certain that cloud service providers will be expected to contribute to securing software supply chains.

  • GraphQL: Security by Obscurity Just Isn’t Enough

    GraphQL: Security by Obscurity Just Isn’t Enough

    The debate about how to secure GraphQL rages on. Many organizations are hesitant to adopt GraphQL for public-facing APIs as there is no precise method to handle authorization concerns as of yet. Without a role-based access layer to enable fine-grained permissions for each field (and underlying services that GraphQL might wrap), the query language can be prone to access control issues.

    One method to hamper GraphQL access is to turn off introspection features altogether. Some may assume that hackers can’t perform introspection on an endpoint if it’s not visible. But this isn’t entirely true—even though an “internal” endpoint may not be fully documented, any endpoint on the public web can be searched and introspected quite easily by brute-forcing queries or through field suggestions.

    I recently met with Karim Rustom, cybersecurity engineer, Escape Technologies. According to Rustom, “making something obscure isn’t enough to make it secure.” Leveraging a single slip-up in access control could be used as a doorway into these systems. Although it’s a best practice to limit introspection, it’s likely not enough to protect production GraphQL endpoints, he said. Below, we’ll consider some common GraphQL threats and alternative solutions to retain a safe GraphQL implementation.

    Common GraphQL Threats

    Having run thousands of scans on production GraphQL endpoints, Rustom found common trends emerge around GraphQL threats. First, he noticed the potential for denial-of-service attacks to be quite high. GraphQL, by design, is intended to query whatever data the client requires. But sometimes, these queries can return a mountain of data.

    If GraphQL owners don’t place a limit on what can be requested in a single query, the platform can easily fall victim to denial-of-service attacks and service interruptions. And limits aren’t only necessary for bulk read-only operations—although GraphQL is primarily used for fetching data, some methods might initiate intense server-side processing, which should be limited in some form. According to Rustom, such data manipulation methods are especially pervasive in FinTech, food delivery or health care-related applications.

    Another rampant GraphQL threat lies in access control issues. This comes as little surprise, as access control is ranked as OWASP’s most common web application security risk. Often, when creating new objects or new queries, a developer might forget to add the correct authorization, said Rustom. This can become a huge problem and lead to privilege escalation.

    Finally, too many production GraphQL implementations rely on security by obscurity. “Folks think that disabling introspection is a layer of security—we highly stress that it’s not,” said Rustom. He recalled performing penetration testing for a certain client; even though they had disabled introspection, the team was able to fetch ample open paths and discover an unsecured doorway to divulge secret internal knowledge.

    Solutions and Best Practices

    To avoid some of the vulnerabilities presented above, it’s recommended to first place request limits on overly complex GraphQL calls to prevent denial-of-service attacks. One nuance here that Rustom recommended is to consider request complexity—not in terms of the query size, but the overall processing required. He suggested assigning scores for every query and permutation to help inform the decision about whether or not to process the incoming call.

    Furthermore, it’s recommended to disable field suggestions as the feature could be prone to abuse. Using field suggestions, hackers can leak a lot of information to build a partial or complete introspection. These tactics are similar to the word-busting techniques black hats use to perform introspection on REST endpoints.

    Although it’s a good practice to limit the possibility of surveillance, hackers can still discover systems and leverage other common vulnerabilities like broken access control. Rustom suggested other tactics, such as luring attackers into a honeypot or logging them into a fake account. Or, creating error messages that are intentionally misleading for a attacker.

    To retain a safe GraphQL implementation, organizations can use pre-made free and open source tools to audit their surface area and scan for known vulnerabilities. For example, GraphQL.security quickly scans your GraphQL URL endpoint to discover vulnerabilities. Or, Graphinder can examine a subdomain to discover GraphQL endpoints, which could aid auditing purposes. There’s also middleware that wraps a GraphQL service with additional security, such as GraphQL Armor and GraphQL Shield.

    Future of GraphQL in the Market

    There appear to be many flavors of GraphQL throughout the market. We’ve seen it emerge as a mechanism to power backend microservices. We’ve also witnessed the technology adopted as a layer to centralize multiple REST services with a more usable data retrieval mechanism for frontend engineers. Some GraphQL endpoints also run on the public web to serve end clients and external partners.

    “GraphQL is a beautiful technology, just lacking in security,” said Rustom. And unfortunately, his outlook for API security looks grim—amid political turmoil and economic instabilities in regions like Europe, some companies may seek to cut cybersecurity investments to stay lean. For companies that haven’t yet suffered a breach, security is easy to ditch to slim budgets, but it should remain a priority, said Rustom. “Keep securing GraphQL.”

  • The Whats and Hows of APIs: A New Developer’s Guide 

    The Whats and Hows of APIs: A New Developer’s Guide 

    For those who are new developers, you may not know a lot about application programming interfaces (APIs). However, it is likely that you’ve used them before as a consumer or an end user, whether purchasing online, using business communication software to reach colleagues or sharing images from a monogram logo maker on social media platforms, for example. It makes knowing about them helpful, regardless of if you plan to make and use one yourself or want to understand how the tools you use work. 

    Although coding and developer tools can be daunting for the outside world, we’ll put APIs into a language that new developers (and even non-developers) can understand. In this guide, we’ll cover what APIs are and the different types that exist. You’ll also learn how they work and how you can use them. By the end, hopefully, you’ll be more comfortable with APIs and know how they impact you and your business.

    What Is an API?

    An application programming interface is a piece of coding used by developers to communicate between different devices, systems, or applications. It allows information to be passed on—allowing procedures to be followed across multiple platforms. Depending on the API, this could be transferring data, images, videos, text, files and other content, or allowing developers to connect through the use of backend-as-a-service (BaaS) to link their apps to the cloud. APIs are often used in a business context and for personal projects or other purposes. 

    Generally, APIs are concerned with the raw information and passing this on to another program rather than the appearance or visual side of these applications. Another set of coding is used instead to build the aesthetic and usability of the interface, while the API tends to be less visible to users. Nonetheless, they form an essential part of our technology stack today, allowing systems to integrate and become more agile, making applications easier for users to navigate.

    Image sourced from developers.facebook.com

    For example, when you refresh your omnichannel communications application, a request is sent to the API to check other linked programs for new messages on your social platforms or calls to your 800 numbers for business. These programs inform the API of new communications and send the appropriate data across. The API returns this data to the application you are using, enabling you to read the messages from here or notify you of no new calls.

    Types of API

    1. Private

    A private API is used internally within a team, created by developers who work for the company or organization. It can help make highly personalized APIs for the needs of your business and adapt the API as and when needed. Private APIs can’t be used or worked on by external developers, as it is purely for your in-house team. These APIs tend to focus on aiding your company’s productivity and project management across multiple applications.

    2. Partner

    Alternatively, partner APIs are used externally with companies that your business collaborates with. Often, this transfers information between businesses, such as within an affiliate scheme or for external postage of online orders. However, APIs can also share and update files such as your release of liability contract or emergency procedure templates. Developers from both companies can improve the API system to effectively share data between partners. 

    3. Open/Public

    Because they are not restricted to usage by specific businesses, open APIs (also known as public APIs) can be used by anyone. You may need a subscription to give you access to the API depending on how frequently you use it, although there are other APIs that are completely free to use. Once you’ve sorted out your access, any software developer can use the API to make changes and transfer information more easily between various software for several purposes. 

    Image sourced from mailchimp.com

    4. Composite

    By taking the responses of multiple programs and streamlining these onto one platform, composite APIs are essential for business and personal use. Or, vice versa, a composite API allows you to make requests of multiple platforms simultaneously. It is helpful for omnichannel management, tracking customer interactions, online faxing and purchases across various platforms. These tend to require little input from developers and are set up for anyone to use.  

    How to Use an API

    • Choose Your API

    As you may have gathered, APIs can be used for several purposes. When choosing your API, look for something relevant to the business that helps you complete the tasks you already do. The software and tools you use may have recommended APIs to try, or there may be APIs that similar businesses use. Do your research to ensure your API performs the right functions and works with your rephrasing tool, calendar software or other add-ons you use. 

    If you’re getting used to APIs, you may want to start with a free option. It means that if it doesn’t work as you hoped, you’ve not lost anything by trying. Many APIs have a free trial period or a free subscription tier with the basic functions, so you can get a feel for the API and decide if it works for your business. When you’re confident in your choice, you can invest in the other subscription tiers that tend to allow for additional users and added functionality.

    • Find Your API Key

    An API key identifies you as the user, authenticating your actions using the API and tracking your usage. It is crucial to have, particularly with subscription-based APIs, as without it you may not be able to perform certain actions, or your users of the API may be limited. Even if your API of choice is free to use and publicly accessible, there still may be an API key to keep your information and preferences stored and linked between your platforms. 

    Image sourced from developers.google.com

    Your API key may be issued as you sign up for the service, so remember this and ensure those in your business who need it can access it. Otherwise, you may need to request or pay for an API key, although this should be clear when you sign up for your chosen API. To increase your API security and avoid your preferences being altered, keep your API key private and limit who has access to it. If your account is hacked, you may need to request a new API key. 

    • Read the Instructions

    It can be easy to overlook the documentation and instructions an API comes with, assuming you’ll get the gist through practicing and by actually using it. Although this may be true to an extent, you could be missing out on useful functions or not using the API as effectively as possible. Likewise, you could get yourself into a mess, not properly setting resource requests and limits, leading to more issues for your business when using the API in the future.

    Set aside time to read the instructions and documents for your API or divide the workload between your management team. You may discover it comes with setup instructions or useful tutorials you can use with the rest of your teams. As you introduce more people to the API, the instructions ensure everyone uses it in the same way. It prevents confusion for your teams and enables them to build their confidence with the API more quickly. 

    • Set Up Your Requests

    Depending on the API, there may be suggested requests for you to set up or you may have to create and code your own. Following the instructions from your API can help with this, allowing your in-house developers to reach their full potential within the API and informing you of the coding structure to use. Nonetheless, there are plenty of tutorials online covering how to set up your API requests without relying on coding expertise.   

    Image sourced from developer.paypal.com

    Just because a request is possible doesn’t mean it’s always relevant to your business. Consider why you’re using an API and what you want it to do once you’ve set up your requests. If you’re new to using APIs, start with a few basic requests and build on these as you gain confidence and experience, using CI/CD best practices to ensure it runs well. It allows you to become familiar with using each request and ensure it works in the way that you intended it.

    Are You Ready to Use APIs?

    As technology progresses and software is developed, having APIs in place is becoming more helpful. Being able to communicate between applications can streamline your virtual receptionist service, incoming video calls and outgoing messages, for example, as well as accelerate cloud-native application development. Having one place to make your requests and display information from multiple platforms gives you more control in managing your tasks.

    If you’re still new to APIs, you don’t have to start using them for everything immediately. Take your time learning to use them for specific functions, getting familiar with them, and enabling your teams to adjust to using them. From this foundation, add new APIs or requests as they’re needed, personalizing them to your business and the tasks you complete. Over time, you’ll gain confidence in using APIs and build a strong network of requests to run your business effectively.

     

  • Getting Started With GraphQL APIs

    Getting Started With GraphQL APIs

    GraphQL, a query language for APIs and a runtime for fulfilling those queries with your existing data, is rapidly growing in popularity. According to the latest State of JavaScript survey report, 44.3% of respondents said they had used GraphQL APIs in 2020 compared to only 5% in 2016. Additionally, many Fortune 500 companies now use GraphQL APIs for their backends in production, while top tech companies like Facebook and GitHub use the API technology to improve their product offerings and boost system performance.

    With the ever-changing technology landscape, you might have doubts about adopting GraphQL API for your backend and be unsure how it can improve your current data needs. However, regardless of what language or architecture you are using, GraphQL APIs can help simplify data access, supercharge the product development process, improve application performance and handle complex back-end data scenarios.

    One Unified Endpoint For Your Backend

    One advantage of GraphQL APIs is that they provide a single unified endpoint for your backend to meet both client and general API use cases. A single GraphQL API can handle all the client’s requests and forward them to the correct backend service.

    As companies and their products scale, REST endpoints can become large and incredibly hard to manage. One of the main problems in REST is the N+1 problem, where the client calls the server N+1 times to get N number of resources, mainly because a single REST resource does not provide enough information for the client to operate with.

    Brennan Saeta, an infrastructure engineer at Coursera, cited centralizing REST APIs for simple consumption by the client as one of the reasons why GraphQL API appealed to them.

    GraphQL API hides the complexity of the underlying backend system by aggregating the required data from different sources and providing a simple interface that clients can communicate with through a single resource.

    Improved Application Performance With GraphQL

    GraphQL API improves application performance by reducing JSON payload size and network overhead from multiple API calls. By allowing the client to specify its data requirements, GraphQL APIs eliminate the need for unnecessary generic data being passed from the back end and minimize the number of roundtrips required to retrieve back-end data.

    As companies scale and iterate their products, the data required by different clients and pages changes. In REST API design, when new requirements arise, developers must decide whether to create a new endpoint and have clients make a new request for that data or add more data to an existing endpoint. The first option leads to more server roundtrips, and the second option increases payload size, which can hinder app performance.

    With more applications being accessed over flaky mobile networks and app speed being an important metric for retaining users, minimizing server roundtrips and data transferred over the wire is paramount. Companies like Netflix and Pulley have reported faster page load times and overall app performance after switching to GraphQL APIs.

    With GraphQL APIs, clients receive only the data they specify from the backend server in a single trip, saving network bandwidth and resources.

    Improved System Reliability

    GraphQL API improves system reliability by ensuring that client queries are valid and in sync with the GraphQL schema specification before query execution. GraphQL uses a type system that describes what type of data can be queried from the backend server and in what form it exists. A strongly-typed schema offers enhanced security over REST APIs by preventing breaches like SQL injection and unintentional data leaks, resulting in a more secure and reliable application.

    Type-safety ensures that any breaking changes by the backend server would be caught by clients consuming the data, resulting in less downtime. With GraphQL APIs, you can modify and deprecate API fields while still maintaining backward compatibility. It is easier to know which fields in the API are being used by what clients and which ones are not. With GraphQL, API developers can confidently make changes to the existing APIs without breaking the existing functionality.

    Swiggy, India’s largest food delivery platform, discussed how adopting GraphQL API for their back end enabled them to make changes to their existing APIs without breaking the consumer application.

    GraphQL ensures API consistency, reliability and security, resulting in better system performance.

    Better Developer Experience

    Adopting GraphQL APIs improves the developer experience for both frontend and backend developers. Backend developers want to build APIs that are intuitive and easy to explore and navigate. GraphQL helps with that by reducing the time spent documenting APIs.

    Through a concept known as introspection, GraphQL APIs allow clients to query the schema and discover the resources available on it. With excellent tools and libraries like the GraphiQL IDE, the interactivity for GraphQL API endpoints is much more intuitive for the developer.

    API consumers want APIs that are flexible, easy to integrate and support a variety of client use cases (web, iOS and Android). Because of REST’s inflexibility, it is challenging to create a single endpoint that can meet all of the client’s data requirements. Often the same client has to call multiple APIs to get the data it needs from the backend. Additionally, with REST APIs, frontend developers have to rely on the backend for API specifications before building product features, leading to slower development time.

    Peter Downs, director of engineering at fintech startup Pipe, said choosing GraphQL APIs early on cut their development time by 90%. With GraphQL APIs, frontend and UI developers can quickly and easily iterate on features by simply specifying the data requirements in the GraphQL API, thereby reducing the dependence on backend developers to make changes.

    Getting Started With GraphQL APIs

    The best way to learn GraphQL is by getting your hands dirty and building applications with it. Depending on your language of choice, there are GraphQL libraries in many different languages to help you get started.

    As with any new technology, adopting GraphQL APIs for your back end and building high-performant GraphQL backends requires experience, which is not peculiar to GraphQL alone.

    If your application relies heavily on interconnected data, you aim to develop an API to be used across several clients or are looking for a high-performant API solution for your backend that minimizes bandwidth usage, then GraphQL API is a perfect data layer for your backend.