devopsy.kinsta.cloud

Tag: API

  • Index Tracks Impressive Growth of API-First Startups

    Index Tracks Impressive Growth of API-First Startups

    APIs are the building blocks of modern software, and their use continues to grow around the globe. A full 89% of investment into APIs will increase or stay the same over the next 12 months, Postman’s 2022 State of the API report found. And the evolving API-first approach is ushering in many innovations and startups into the field. This trend is epitomized by the latest research from GGV Capital, which maintains an API-First Index of leading developer-first software companies.

    The API-First Index tracks API-first companies that have raised $50 million in funding or more. And as of Q3 2022, the number of businesses that met this threshold increased to over 60. Just in Q3 alone, $350 million in funding was raised by companies on the index, and, in total, the index represents over $14 billion in funding. Undoubtedly, interest and investment in this space are expanding and will continue to increase in the year ahead. It’s a good area to keep tabs on, as the emphasis on modularity impacts how software is pieced together.

    I recently met with Tiffany Luck, partner at GGV Capitol, who oversees the API-First Index. Below, we’ll explore the index a bit more and get Luck’s viewpoint on why these findings represent a unique moment for API-first technology and business models as a whole.

    The API-First Index

    The API-First Index focuses on companies that serve niche functionally through APIs; also known as API-as-a-product. The list includes an assortment of API-based tools from FinTech, communications, health care, commerce and other sectors.

    For example, Stripe is likely the most well-known API-as-a-product, as it is commonly integrated as a way for businesses to accept payments. There’s also MessageBird, an API for sending notifications across any channel. Other examples include Mapbox, an API for geolocation data, Mux, an API for creating live and on-demand video experiences, Nylas, which offers a popular email API and Alpaca, an API for stock and cryptocurrency trading and many others.

    Currently, the index doesn’t include the entire API platform landscape of tools, which ranges from areas like API management to testing, documentation, monitoring, design, security and observability. There are also middleware integration platforms to consider as well. With these included, the list of well-funded API-related toolsets would surely be even longer.

    Why the Excitement About API-First?

    The number of people deciding to build API-first companies is rapidly increasing. These API-based web components are interchangeable and represent the future of software development. “The world is going toward web and cloud components,” said Luck. The trend represents a global movement with much effort reflected in Europe, Asia and the U.S. Furthermore, API models seemed resilient throughout ongoing economic uncertainty and the patchy VC funding of 2022. “APIs are holding up very well compared to the broader VC landscape,” said Luck.

    So, why is there so much excitement around APIs? Well, people are looking for best-in-class structural blocks that can be used to build common features like geolocation, AI, weather, payments or specific CRM functions. Niche APIs can swiftly deliver particular features without the bulk of a large platform. Another reason is that they’re relatively sticky—API-based delivery models are efficient at building a self-service platform that expands over time, which is a very keen prospect to investors, said Luck.

    Unicorn APIs Solve Hard Problems

    In evaluating API-first companies, Luck looks for those offering B2B solutions to super-hard, shared problems. This equates to reusable functionality that is difficult to build, maintain and scale individually. Furthermore, the solution must solve a need that’s common across companies but that is not core to their products.

    For example, Luck has her eye on a few impressive API-first use cases. Stream, for example, powers in-app user-facing features. Knock offers solutions for handling notifications. But many of the top most-challenging areas include financial services, as this functionality is difficult to build from a regulatory and connectivity perspective. Examples include Pinwheel, which aggregates real-time income and employment data. Method API does something similar but for aggregating consumer debts.

    Luck described APIs as a “modern way of accessing what would otherwise be technically inaccessible.” We’re seeing this action unfold in open banking, as new standards around the globe now mandate that consumer financial data be programmatically accessible, often in the form of an API connection.

    Developer Experience: The New Competitive Advantage

    In a competitive market surging with powerful developer-facing tools, non-functional aspects such as developer experience (DX), security, performance and reliability are becoming more of a focus. According to Luck, developer experience is probably at the top of the pyramid as it represents a catch-all for many of the aforementioned traits. Specifically, developer tools with high-quality DX have excellent documentation and must maintain backward compatibility to avoid breaking changes on the consumer side. “Ultimately, what you’re implementing impacts that customer’s end customer. Customers want zero negative impact and zero disruption,” she said.

    The API-First Index is good for the industry as it helps educate the public on private investing rounds. And as discussion around it increases, it brings awareness and visibility to the benefits of building API-first.

  • Introduction to MACH Architecture

    Introduction to MACH Architecture

    In recent years, the need to construct end-to-end digital experiences has become increasingly important. But to deliver new features and services promptly, organizations must double down on agility and reusability. As part of this trend, applications have become increasingly modular, often constructed using pre-built microservices and integrating common SaaS to avoid reinventing the wheel.

    MACH is an architectural style that fits into these trends quite well. It stands for Microservices-based, API-first, Cloud-native, and Headless. The locus of the movement is The Mach Alliance, a group of API-first companies abiding by these principles. At the time of writing, MACH is gaining mindshare as more API-first companies enter the market and the appetite for cloud-native technology grows.

    I recently chatted with Gary Ballabio, VP of technology partnerships, Cloudinary, about the ongoing MACH trend. According to Ballabio, MACH delivers “best of breed” technologies that avoid the bloat of larger platforms. Yet, for software consumers, building in a MACH style will require stitching together individual components and orchestrating them effectively. Below, we’ll explore MACH and consider the benefits and drawbacks of utilizing tools that conform to this approach.

    What Is MACH?

    MACH is an emerging software architecture style adopted by a number of commerce and digital experience tools. To understand MACH a bit deeper, it’s necessary to understand the underlying concepts of microservices, API-first, cloud-native and headless. So, let’s first break apart these familiar terms:

    • Microservices: Unlike monolithic development, a microservices architecture organizes functionality into self-contained, specialized components. This improves reusability and allows for more frequent, targeted software updates.
    • API-first: API-first takes design-first one step further. It means putting the consumption model, the API, ahead of other concerns, like the application or UI. Web APIs have become ubiquitous for connecting a microservices ecosystem and exposing data and functionality to partners and public consumers.
    • Cloud-native: An umbrella term for projects purpose-built for the elasticity and scalability of the cloud.
    • Headless: Headless means separating the front end, or “head,” from the back end. By decoupling development this way, websites and apps are better equipped to cater to multiple platforms and devices.

    According to Ballabio, companies can leverage cloud-ready best-of-breed functionality by integrating tools that adopt MACH principles. Incorporating one single SaaS to fit a specialized need can also be considered an alternative to using large, comprehensive enterprise commerce suites like Salesforce, Adobe or SAP, said Ballabio.

    There are many examples of specialized SaaS services built in the MACH style. Some include Algolia for search and recommendations, Cloudinary for media management, Builder.io for mobile experiences, or Contentstack as a headless CMS. All these tools are members of The MACH Alliance, a group of over 70 vendors, partners, startups, systems integrators and other ambassadors dedicated to fostering the MACH approach. And although the emphasis has been on commerce and digital experiences, MACH is expanding beyond that scope to other areas.

    MACH technologies support a composable enterprise in which every component is pluggable, scalable, replaceable.

    Some readers may wonder, “How is this different than Jamstack (JavaScript, APIs and markdown)? In a way, MACH is similar to Jamstack, as both approaches aim for headless frontend experiences and a modular backend powered by APIs. But a key difference, said Ballabio, is that MACH doesn’t dictate the use of specific programming languages.

    Benefits and Drawbacks of MACH

    MACH combines many development trends we’re seeing in the software landscape. Digital applications are becoming more composable, cloud-first is rising, and headless models can deliver customization benefits. Yet, there are some potential drawbacks to introducing this style too. So, let’s weigh some of the positives and negatives of adopting MACH architecture.

    Benefits

    • Flexibility: The most significant benefit of MACH is the flexibility it offers, said Ballabio. “There’s value in being able to choose the services you want to use based on your own unique requirements.” Looping in a specific API-first tool for something like e-commerce, payments, CMS or email can enable a lot of customization.
    • Reduced waste: This can create less waste, too, as you create a leaner footprint by acquiring only what you need for each project, and freemium models enable consumers to pay for only what they use. This is helpful when you want a single component but don’t require the bells and whistles of a more holistic platform.
    • Best-of-breed: Niche API-first products are focused on doing one thing really well, and this particular focus can improve quality and agility. It also releases engineers from being at the whim of an extensive product’s development life cycle.
    • Developer-first: Lastly, most digital experiences share common functionalities that developers shouldn’t have to reinvent. MACH supports being developer-first, says Ballabio, which is an asset to companies investing in developer experience.

    Drawbacks

    • Increased maintenance: Consuming many third-party cloud services will inevitably bring new maintenance hurdles. These include tracking, monitoring and securing all integration points. It also requires responding to new version updates.
    • Stitching together: Naturally, when you add a cloud-based abstraction layer to the services you consume, the onus is on the consumer to then to stitch them together to make components talk to one another.
    • Startup costs: Due to the coordination between services, initial costs and engineering time could be more than implementing a holistic suite, admitted Ballabio. “But you get more long-term benefits,” he said.
    • Assistance may be required: Those unaccustomed to microservices development and API integration may need help. This may require the support of systems integrators or middleware to orchestrate connections.
    • Lack of standards: MACH is more of a general architecture rather than a standard specification. Thus, the precise technologies under the hood and the specific behaviors may differ from service to service.

    Future of MACH

    A recent MACH Alliance study found 79% of tech leaders plan to invest more in MACH technologies in the next year. Although the style has been primarily trending in Europe, Ballabio predicts the U.S. will soon pick it up. The MACH Alliance presents and advocates for an open and best-of-breed enterprise technology ecosystem.

    Along with the rise of composable architecture, the MACH approach is gaining interest among cloud-native leaders who see the advantage of assembling applications using pre-fabricated building blocks. MACH is especially a good fit for greenfield development, where the slate is clean to integrate new technology.

    MACH represents a new category of companies that are growing together. Ballabio remarks that he feels part of a movement, part of an industry—and, arguably, this movement can potentially disrupt larger commerce ecosystems.

    But although MACH gives a name to a face, most techies still aren’t aware of the acronym. While the concept may, for now, live in the domain of vendor-speak, Ballabio foresees it becoming a more common parlance for consumers and end developers.

  • Choosing the Right API Solution

    Choosing the Right API Solution

    There are more choices than ever when it comes to APIs–and that’s a good thing. But it also means you’ll need a strategic plan for choosing the right API solution.

    Two questions I’ve found can help guide that decision: 

    1. What problem are you trying to solve right now? 
    2. What functionality will you need in the next five to 10 years? 

    Once you’re clear on the answers, you can evaluate API solutions based on the following five criteria to choose the one best suited to your needs.

    Performance

    In a highly competitive global market, it’s not enough to have reliable uptime. Speed also matters–a lot. A site that loads in one second has a conversion rate three times higher than one that loads in five seconds.

    To accommodate current customer expectations for page speed, API response time should be no greater than 90 milliseconds. One way to blazing-fast API speeds is to take a client-side approach where data is delivered to an edge node of a CDN network instead of stored on a server somewhere in your data center.

    But let’s return for a minute to the first question I introduced above: What problem are you trying to solve? If you’re an online retailer, you want your site to load fast so your customers don’t click away and you want everything on it to be accurate–for example, if an item sells out while a customer is browsing, they shouldn’t be able to put it in their cart.

    Not every function requires the same level of speed. Product description content, for example, is mostly static, while inventory is not. So content delivered by your CMS’s API may not require the same speed as data from a transaction engine. 

    While high performance is important for every API you use, the actual performance benchmarks each one needs to meet vary based on function and on the end-user problem you’re solving.

    Documentation

    Thorough documentation is a must-have for any API solution you adopt. Without thorough documentation, your team will be forced to figure out how to use the API via trial and error supplemented with time-consuming support interactions. Strong documentation lets developers use APIs more effectively and, ultimately, ship products to market faster.

    But even among providers that offer thorough documentation, there are more and less helpful varieties. I’ve read plenty of documentation, for example, that is written with the assumption that the person reading it already understands how the API works. This makes it harder for newer developers to learn and understand the capabilities of an API.

    As you consider providers, look for those with documentation written for someone who is totally new to the API–which you and your team will almost certainly be. As a stylistic guide, look to documentation from Mozilla, MDM and W3 schools, which I think do an excellent job of communicating for non-experts.

    To gauge the helpfulness of a potential provider’s documentation, I recommend having your team read some of it and asking the partner team how often they update it. A best-case scenario is that they consider documentation an ongoing project that will never be complete.

    Security

    Security is pretty self-explanatory, so I won’t spend a ton of time on it here. Any API provider should offer robust security to ensure that the API cannot be used nefariously by bad actors or hacked to expose sensitive information. REST APIs almost always follow standards like 0Auth and TLS to maintain security. It’s worth looking at how the API you’re using describes its security practice.

    Flexibility and Extensibility

    Your team should have the freedom to create whatever they want with the APIs you use, meaning they shouldn’t be hampered by roadblocks in the API’s design. This freedom to create should exist in all aspects of the API: It should let your team create whatever customer experiences they can dream up, and it should let you manage back-end information in whatever way makes sense for your organization.

    In other words, an API solution should be well-defined but should not define everything you can do with it.

    Pricing Model

    The final piece to take into consideration is the API’s pricing model, by which I mean not only its actual cost but also the way the provider charges to use its service.

    For example, does it charge by order? By bandwidth? By number of records? Again, this comes back to the problem you’re trying to solve: If you have a lot of requests to make, for example, don’t choose a service that restricts requests per minute.

    And even if a pricing model works for your business today, will it work as you scale? This question brings me to my final thought.

    API Solutions Should Make it Easy to Grow and Evolve

    I started this piece with two key questions to guide the process of choosing API providers: What problem are you solving and where is your business going?

    If you’re exploring APIs as part of a replatforming project, there’s a good chance you chose a platform 10 years ago that could do everything–but that can’t keep up with evolving customer expectations or that restricts your team’s creativity today. The APIs you choose should let you meet current needs and make it easy to make changes–including swapping one API provider for another–as your needs evolve.

    In other words, when you choose the right API solutions, you should never need to do another replatform.

  • ‘The OG App’ Devs’ Facebook Ban | WFH Vs. NYC Real Estate | Calif. Pay Law is GO

    ‘The OG App’ Devs’ Facebook Ban | WFH Vs. NYC Real Estate | Calif. Pay Law is GO

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: A third-party Instagram app causes ructions, remote work causes office slump, and more on Cali’s salary transparency law. (more…)

  • Empathy for the API Developer

    Empathy for the API Developer

    Security teams have always been perceived as an impediment to delivery by software teams who feel that security imposes arbitrary and unreasonable policies and use poorly-integrated tools that are beset with high false-positive rates. With the advent of DevOps, security has been seen as an increasing obstacle to rapid deployment cycles. 

    Security teams believe developers do not care about security and will try their best to avoid security controls or policies. Security teams are often frustrated by developer pushback when remediating vulnerabilities, particularly when they fail to appreciate the cascading effects of making code and dependency changes late in the life cycle.

    From my perspective, with a foot in both camps and a decade of experience helping developers produce more secure code, I believe the key to addressing the disconnect between teams is to develop greater empathy for the developer.

    Why Insecure Software Exists

    Software development is a complex endeavor with many (often conflicting) requirements. Blaming software developers for insecure software is an overly simplistic and counterproductive approach, best summarized by a former colleague:

    “I can tell you that virtually all developers I talk to care about application security. They care about the quality of the products they create, the integrity of the data their software handles, and the reputation of the organizations they work for.” —  Jim Jastrzebski, Veracode

    From my experience, developers don’t deliberately set out to create insecure software; instead, there are a number of reasons it happens.

    Devs are overly optimistic: Developers are creative folks and natural problem-solvers. They can often visualize the perfect end result of their labor without necessarily considering the technical and security debt they may encounter along the way. Remember—things do go wrong.

    Overconfidence: I often refer to this as the Dunning-Kruger effect for developers. Faced with complex platforms, languages and frameworks, developers tend to overestimate their ability to comprehend and master them. Complex systems take time to fully understand and being overly confident can lead to unintended consequences and compromise security. Beware of insecure defaults and configurations.

    Bad things only happen to other developers: Think of this as a kind of schadenfreude for developers. During code reviews with developers, I have been surprised to hear comments like, “ … But that won’t happen to my code!” Despite vast evidence to the contrary, some developers think that bad things only happen to others and to others’ code. Assume a defensive mindset; expect the worst and hope for the best.

    Taking shortcuts: Developers are goal-oriented and want to produce working code on schedule. And schedules are tight. The inevitable consequence is that sometimes shortcuts are taken (missing error handler or input validation, for instance) leading to security vulnerabilities. Track and tackle your technical debt.

    Technical debt or legacy code: Speaking of technical debt, it’s probably one of the biggest issues facing developers: The burndown of technical debt and maintenance of legacy code. Software systems are complex and minor changes may wreak havoc, especially in microservices-based applications and architectures. Remember that developers may have legitimate concerns about making changes that are not absolutely necessary.

    This stuff is difficult: The biggest thing to remember to develop the empathy muscle is to appreciate the difficulty of the software development process. Developers are facing multiple conflicting requirements against tight deadlines and are required to master a variety of technologies. Mistakes will happen; the important thing is to learn lessons and improve the process.

    The last point is perfectly captured by this quote:

    “90% of security problems are just complexity problems. It’s technical complexity, it’s network complexity, it’s organizational complexity.” — Adrian Ludwig, Atlassian

    Care and Feeding of Developers

    Once security engineers have a better understanding of the challenges facing developers, they can focus on their messaging when communicating about security issues. Remember that the developer is unlikely to be personally responsible for every issue and should not be blamed or scolded. This will produce defensive behavior and is unlikely to achieve a positive outcome. Focus on the shared security challenge at hand and how a joint approach can solve the problem.

    A frequently-cited problem for developers is the relatively high false-positive rates security tools produce, particularly with code scanning tools. Security engineers should make sure that the tools are suited to your technical stacks and fine-tune the tool as much as possible. Ideally, the security team should triage the initial report and remove obvious false positives. 

    Additionally, certain legacy security tools do not integrate well into CI/CD pipelines and cannot be easily automated within the build process. If a developer has to use a manual or asynchronous process to perform a security scan, they will become frustrated and possibly ignore this requirement. Make sure security tools work well with the developer’s environments and workflows.

    Do not assume every developer has a deep understanding of the security issues identified—take the time to explain them thoroughly and/or document them internally. A great approach is to conduct shared learning sessions where developers and security teams work through a vulnerable application together to learn the concepts.

    Another frustration developers cite is a lack of clear understanding of the security requirements or requirements that are constantly changing. Ensure security policies are clearly stated and available to developers, and explain the reasons why the policies exist in the first place—for example, to meet PCI DSS accreditation. 

    Finally, make sure the combined teams are given time not just to learn but to absorb lessons and that success is recognized and rewarded. 

    “The sky is always falling—we never celebrate success.” – Chris Romeo, Security Journey

    Empowering Developers

    So, what does developer empathy look like for API developers?

    First, API developers and security engineers can both benefit from the positive security model that uses the OpenAPI definition as the contract for API behavior. Anything not specified by that contract is considered invalid—in other words, the contract specifies the allow list. This is in stark contrast to the traditional approach for web security which is reliant on blocking according to a block list—obviously, not all bad input can be known leading to false negatives with this approach. Overly aggressive blocking may block valid input and typically result in false positives; familiar to users operating web application firewalls (WAFs).

    The OpenAPI definition offers another advantage: The applicable policies can be expressed as code in the definition as opposed to via some verbose, abstract policy documentation. The benefit of policy-as-code is to uniformly enforce policy across the life cycle starting when the developer first starts coding the API. 

    Finally, developers need security tools that work in their preferred environments (for example, first-class IDE and CI/CD plugins) and provide value in the form of remediation guidance or actionable findings that help developers reduce technical debt. 

    Security and development don’t have to be at odds; help developers to help themselves by building empathy and working with them rather than against them.

  • 3 Ways API Analytics Can Help Application Owners

    3 Ways API Analytics Can Help Application Owners

    Software development is fraught with risk that can run projects aground like a ship against a rocky beach. Whether it is misunderstood requirements, rapidly evolving marketplaces or old-fashioned bugs and schedule slippage, all can derail otherwise well-resourced and managed software development projects.

    Even when software development teams eventually ship their product and collect payment from their customers, there is no guarantee that the product will be used. A 2022 study found that among those paying for SaaS software, 29% of their software is either underutilized or wasted. This study also noted that only 33% of IT professionals track SaaS software usage. The takeaway here is stark: As an industry, most of our labor is not going to productive ends. 

    This is not a new trend in software; an entire ecosystem of tooling exists to help software development companies collect user engagement metrics to drive development decisions. In fact, out of the top 10 million websites in the world, nearly two-thirds have an analytics solution in place. By contrast, however, API applications lag far behind in adoption of this practice. It is difficult to get market penetration data for API analytics, but a report from API management vendor Apigee revealed that even among its customers (that is, those who were already paying for a service that included API analytics), only 26% made use of the analytics functionality. This gives credence to the belief that most features go unused.

    API application owners who are not integrating real-world analytics usage data into their decision-making process are leaving time and money on the table. Despite not having immediate access to user behavior, API analytics can be quite valuable in helping API application owners make better decisions about application development and maintenance. 

    API application owners should look to the following three ways to make better product development decisions.

    Prioritize Feature Development in the Most Actively Used Areas of the Application

    One of the best lessons I learned from working at a bike shop is “stock what sells.” In other words, there’s no point in filling your shelves with products that your customers aren’t buying. The same goes for stocking your API product catalog with endpoints that your customer isn’t using. 

    API analytics allow API product owners to measure the use of features and evaluate their effectiveness. Product owners can use this valuable information to prioritize extending popular features or developing new features, with a clear yardstick for measuring usage. Further, this data enables development teams to “maximize the amount of work not done,” by shipping preliminary feature sets and evaluating usage metrics before a full implementation. Likewise, if the real-world feedback is not encouraging, it allows you to pivot to another opportunity within the product.

    Deprecate or Sunset Unused Application Features

    Unused code and features are a liability to an API product organization and can carry bugs, create performance problems and introduce security risks. I’ve seen situations as a software developer where these older features were written by developers who have long since left the organization. These unused sections often harbor serious security flaws and vulnerabilities (such as software dependencies that go unpatched for years) and dubious authorization logic that no one at the company fully understands.

    Unused, extraneous features also contribute to a bloated product that can distract end users from the core value of your API. It can be difficult to advocate for the removal of “working product features,” but API analytics data can help make a strong case that certain features are nothing but an expensive distraction. Removing old, unused parts of your application also frees developers to focus on the parts that users love. 

    Prioritize Performance Improvements

    Performance is often a fine balance between implementation time/costs and product requirements.

    It’s a well-understood maxim in software development that premature optimization is the root of all evil. Yet in the absence of real-world performance data, determining what represents premature optimization versus totally-necessary-and-prudent optimization often comes down to a subjective argument among engineers or worse, a risk-averse software development culture that contributes to slow time-to-market.

    Having an objective measure of performance impact, like the number of instances in which clients are impacted by suboptimal performance, can help application owners decide how to allocate their budget to improving performance versus developing new features or fixing bugs. Moreover, having this feedback loop in place can empower development teams to take a nimble “go fast, release often and evaluate” approach to development. Rather than optimizing performance up front out of fear that invisible problems will lead to bad performance and dissatisfied users, performance can be tracked and reviewed over time. 

    Selecting API Analytics Solutions

    API product owners operating a single application have a variety of choices when it comes to deciding which analytics tool to use for their product. Many specialized solutions exist for individual API development languages and frameworks. However, security teams have a unique problem: They need all the data, across all applications and across all the tech platforms within the organization. In that case, I recommend an API protection vendor with strong API analytics capabilities that not only protects against threats but also gives you the visibility you need to prioritize efforts. 

    API analytics should be a tool that powers innovation. Don’t leave it unused in your toolbox. 

  • Hasura SDK Integrates GraphQL Platform With More Data Sources

    Hasura SDK Integrates GraphQL Platform With More Data Sources

    At its HasuraCon ’22 conference, Hasura today announced the early release of a software development kit (SDK) that extends the reach of its GraphQL platform to additional data sources.

    In addition, Hasura is making generally available integrations with the GitHub repository, support for OpenTelemetry Traces within the Hasura Cloud Platform and Microsoft SQL event triggers.

    Finally, Hasura Cloud can now be deployed on the Google Cloud Platform while the Hasura Cloud Enterprise edition is now available on the Amazon Web Services (AWS) marketplace.

    Hasura CEO Tanmai Gopal said that while the company already provides support for widely used data sources such as the Postgres database, there are many data sources that organizations also want to be able to query via GraphQL application programming interfaces (APIs). Organizations want to be able to join data using GraphQL regardless of what repository it resides in, he added.

    The open source Hasura engine at the core of the company’s offerings automatically generate a GraphQL schema from a data source. That can then be used to accelerate the development of APIs to make it easier for a wider range of developers to build applications that aggregate data across multiple sources.

    That approach eliminates the backend complexity that IT teams encounter when adding GraphQL APIs to an application environment that already has a range of APIs for internal IT teams to support, noted Gopal.

    GraphQL was originally created by Facebook, but it’s still not clear to what degree GraphQL APIs will supplant REST APIs. Developers tend to prefer GraphQL APIs because they provide more granular control over what data is accessed. The challenge is the number of backend services that expose GraphQL APIs is still comparatively limited.

    It’s not likely IT teams will replace REST APIs with GraphQL-based APIs overnight, but the percentage of new applications that rely on GraphQL APIs will steadily increase. Overall, the number of APIs employed within IT environments is rapidly expanding as more microservices-based applications are deployed. Each microservice generates its own API. Over time, IT teams will find themselves managing a wider variety of types of APIs.

    The challenge is that it’s not always clear who within IT organizations will manage those APIs. They are often created by developers and are left to IT operations teams to maintain. It’s not uncommon for IT teams to find themselves managing hundreds, perhaps thousands of APIs.

    In addition, many of those organizations are now consuming data via APIs exposed by other organizations. Over time, the level of interdependency between APIs and applications will serve to make application environments much more complex to manage.

    In the meantime, DevOps teams will need to extend existing DevOps workflows to both support and secure GraphQL-based APIs. The amount of sensitive data being accessed via those APIs is likely to accelerate the rate at which organizations are adopting DevSecOps best practices. Let’s hope this happens before they wake up to discover GraphQL APIs have already proliferated across the enterprise.

  • The APIs You Really Don’t Know About

    The APIs You Really Don’t Know About

    A few years ago, we were rightly warned about the amount of exposure our APIs created. A massive attack surface that often used “security by obscurity” as its primary method of protection. We’ve come a long way since then, building secrets, tokens, RBAC and even more into our API interfaces.

    We’re still behind in getting comprehensive lists of APIs, but this bit is getting better as time moves on. Increasingly, both API management and DevSecOps markets are helping to catalog new APIs, and both the API management and application and API protection markets are helping to protect APIs that are unknown by tracking calls moving through the network. By using proxies, it is relatively easy to capture calls to APIs and report the list of APIs (and sometimes much more; about parameters and data transport, for example) to security or operations staff.

    In summary. the API management and security market has been doing great work, searching out the various APIs that are active in our systems, and cataloging new APIs as they are created. This gives us a comfortable and complete look at our current API environment and how it is protected. Most of these tools help protect what isn’t currently well protected.

    If only that really were all of the APIs in our networks. Unfortunately, that’s not the case. Because the ones not in this “complete list” can be the most insidious. As always, it is what you don’t know that poses the biggest risk.

    You see, there are APIs that are not currently maintained and are not currently actively accessed. Say you have an application that you installed from a third party—open source or purchased, either one—and then stopped accessing. Well, it is still sitting out there. The APIs are available—not necessarily documented and not necessarily secured. For security staff, this is how nightmares begin.

    Historically, we could count on these interfaces to be private. Those days are long gone in the hybrid environment. They might be private, but the definition of “private” is much looser than it has historically been and if there is a route from the internet to the API, it’s not private, and for well-known applications, is a time-bomb.

    This is another reason to clear out old versions and/or redundant installations of things like web servers and databases. Don’t make excuses—just upgrade them to the most recent version or remove them entirely. You can do this by merging what they do with a newer/better-protected installation or by just stopping them and fixing the apps that this impacts. “Turn it off and see what breaks” is admittedly a risky step, but sometimes will prove necessary to lock down the environment. If you don’t know what is using it, I’d argue your security risks are larger than an unprotected API hanging about, but that’s a topic for another blog.

    Meanwhile, keep rocking it. There is so much in your purview that we have to discuss what you don’t know about in the domain you are the specialist in. That’s not a weakness in you, that’s a statement about how much crap is tossed on your plate while making the org more competitive. And you’re dealing with it. So smile, keep kicking and lock down the scary bits.

     

  • Smoothing the Transition From REST to GraphQL

    Smoothing the Transition From REST to GraphQL

    Since its open source release in 2015, GraphQL has taken the development world by storm. GraphQL, the query language originally developed by Facebook, is a big boon for frontend developers, as it enables you to grab the exact data you need with a single request. This solves the problems of over-fetching and under-fetching, which classical REST APIs are prone to. GraphQL also offers a nice developer experience with a consistent schema and documentation. Some are even treating GraphQL as a convenient meta layer to aggregate multiple underlying services and abstract their interfaces with simple commands.

    For these reasons and more, many development teams are considering switching from REST to GraphQL. Even enterprises are beginning to use GraphQL in large production environments. But, how can these teams make the switch without breaking existing integrations? How can we ensure that things like developer experience, security, and access control all remain stable?

    I recently met with Anant Jhingran, the co-founder of StepZen, to discover tips for transitioning from REST to GraphQL. According to Jhingran, most organizations see the benefit in adopting GraphQL but are hesitant to forgo years of investment into RESTful architectures. But according to Jhingran, it’s rarely a case of “either/or”—more often, he sees projects running both styles simultaneously or layering one on top of the other. Below, we’ll explore some things to keep in mind as you invest in GraphQL.

    The Decade of Developers

    We’ve reached ubiquity of web APIs among companies big and small. “APIs have turned out to be phenomenal for software supply chains,” said Jhingran, the former CTO of Apigee. They help share data between partners and can enable platform ecosystems to thrive. Jhingran describes how within the last decade, APIs and API management have peaked to near-ubiquity in terms of adoption.

    But not all APIs behave the same way. Although representational state transfer (REST) is the most popular style, it’s still quite a general architectural guideline for web APIs—how the data comes out of each service is still highly nuanced. The structure of requests and responses are different from service to service, causing developer experience hangups at scale.

    GraphQL, on the other hand, “is a fantastic way of structuring data,” said Jhingran. With a single call, you can return the explicit information that the client requires in an expected format. For an e-commerce application, for example, this might be customer information, order numbers and delivery status. Displaying this all with one call is an awesome experience for frontend developers. And, GraphQL APIs are easy to explore and navigate since the schema is baked in. This improves upon REST APIs, where documentation may not always match the actual production implementation.

    “This decade is the decade of developers,” said Jhingran. Satisfying developer experience has become more mission-critical as enterprises work to increase their footprint in the cloud marketplace and GraphQL is part of this movement. “For people who build apps, it’s just better,” said Jhingran.

    But just because frontend teams clamor for the ease of use of GraphQL doesn’t mean backend teams can easily restructure their entire framework around it. Doing it right requires many skills, and the journey can be arduous, explained Jhingran.

    It’s Rarely REST Vs. GraphQL

    REST and GraphQL are often pitted against one another to the point that they seem like polar opposites. But in practice, teams often use GraphQL to build on top of APIs already in place. Jhingran describes the most common pattern as “GraphQL comes in as a layer that connects the dots between various REST APIs.” Either GraphQL is consumed directly or as a REST layer above GraphQL. “It could go either way,” he said.

    GraphQL is a fantastic data infrastructure tier as it can mix and match database backends. It could, in essence, become the new plumbing upon which applications are constructed. But while GraphQL may be excellent for internal construction, the name of the game is stability when externalizing services to the outside world. With REST, the big goal is to decrease broken clients and ensure high-grade security for each resource. Therefore, Jhingran foresees certain use cases where using a REST wrapper around GraphQL services to deliver fixed JSON responses would be preferred.

    Another point is that GraphQL is not only relegated to appeasing frontend developers—it has some backend potential, too. “GraphQL is an opportunity to reimagine frontend and GraphQL is an opportunity to reimagine backend infrastructure,” said Jhingran. This concept has weight nowadays, as Netflix engineers, for example, use GraphQL as a backend for microservices architecture.

    Making the Transition From REST to GraphQL

    Not all apps are going to be transformed on day one. Teams may encounter cultural resistance to new technologies. Interface redesigns, especially for those external apps which are exposed to third parties, must also require extra precaution to maintain app compatibility to avoid breaking change.

    Thus, it may take time to transition effectively. “Getting it started versus getting it right are not the same thing,” said Jhingran. He said people who get started with GraphQL may struggle for months due to competing best practices and tools. For example, Jhingran identified two main perspectives when approaching GraphQL: Programming and declarative.

    • Programming: Teams use GraphQL libraries such as Apollo to program their way out of your GraphQL endpoint. In this approach, you just start writing. It’s quick to get started, said Jhingran, but you end up describing everything you do and encountering many contingencies along the way.
    • Declarative: The other option is a more declarative approach—instead of telling the system how, you tell it what to do. For example, this subsystem should do X, this subsystem should do Y and so on. According to Jhingran, adopting tooling with declarative snippets to create GraphQL endpoints is “better in the short and long run.”

    GraphQL Security

    A March 2022 report from Salt Labs found a shocking 681% increase in API-based cyberattacks over the previous 12 months. There are many concerns surrounding API security right now—these valuable endpoints are prone to broken access control, data overexposure and over-permissive states.

    As I’ve covered previously, GraphQL security is a bit nuanced compared to REST. Within the REST paradigm, you can easily assign permissions and rate limit calls per resource. But with GraphQL, it’s not that simple. Since you can batch multiple queries, callers have much more power at their fingertips, and hackers might abuse such power if the proper authorization isn’t in place.

    Companies may rightly worry about opening another can of worms with GraphQL. But according to Jhingran, these worries are all solvable. A comprehensive GraphQL endpoint will likely require another layer to uniquely segment authorization to retain a least-privilege model for all resources and backend endpoints.

    Future of GraphQL

    To date, GraphQL has gained modest prominence. But, Jhingran foresees an incoming inflection point in the next two to three years. “The dominoes are beginning to fall,” he said.

    Now that the market is saturated with APIs, characteristics outside of functionality will be what sets a service apart and gives it a competitive edge. This includes things like performance, security and developer experience, the latter of which makes GraphQL an attractive proposition. This, paired with the explosion in GraphQL tools, will undoubtedly help developers perform their jobs better.

    Looking to the future, Jhingran predicts increased usability and abstraction in how developers work with GraphQL. He compared it to how disjointed pages on the web became interconnected and searchable with links. We see similar thinking happening in the world of APIs, he explained, in which the disjointed APIs require a better connection. Similar to how Google simplified search, he foresees GraphQL and the tools that work with it helping to decrease cognitive load by abstracting complexity with declarative commands.

  • Taking a DevSecOps Approach to API Security

    Taking a DevSecOps Approach to API Security

    An application programming interface (API) is a data transfer approach that enables services within an application to talk to other applications (or other services within a system). Essentially, it enables Service A to talk to Service B in a uniform way. Companies benefit from APIs on a daily basis without even thinking about them. APIs are a way for companies to gain market share from competitors and monetize applications in new and exciting ways. For example, every time someone signs on to their favorite social media platform or shops on Amazon, the application is utilizing APIs to fetch and update the data with which they are interacting.

    Discovering and securing APIs is a never-ending battle for IT teams across all industries. APIs, for all their benefits, open new attack surfaces targeting a company’s data via vulnerabilities and exposures. In Gartner’s recent report, API Security: What You Need to Do to Protect Your APIs, the analysts estimated that for 2021, 90% of web-enabled applications will have more surface area for attack in the form of exposed APIs rather than the user interface (UI), up from 40% in 2019. This turned out to be accurate.

    Traditional Approaches to API Security

    Traditionally, APIs are protected by enterprise API gateways and content delivery networks (CDNs). Although these approaches hedge against most brute force and denial-of-service (DoS) attacks, a more nuanced and sophisticated attack can breach these protections. The traditional approaches to API security are littered with limitations.

    Companies typically use two types of APIs – customer-app-facing APIs also called “north-south APIs” and internal APIs called “east-west APIs.” The external type is exposed to all public internet traffic. External developers can make requests and receive responses to these customer-facing APIs and take advantage of the functionality and data of an application while bypassing the user interface (UI). Internal APIs, however, are exposed only to intra-application traffic. For example, the cart service may call the user service via an internal API during the checkout process of an e-commerce application.

    Customer-facing APIs tend to be a bit more stable, visible, and targeted at a developer audience. The largest challenge of these north-south APIs is ensuring that this layer is secure every second of every day. This open and accessible API is designed to be utilized by developers outside the publisher’s organization. The goal is to leverage a community of technical audiences and increase usage of the organization’s data and services. Occasionally API publishers encourage developers to create applications that expand on the core business.

    While internal developers may call north-south APIs for their application development, the more common east-west API calls between services often drive much of the incremental feature development and new innovations. These APIs may or may not be accessible by developers outside the publishing organization. However, increasing numbers of east-west APIs are native in the public cloud so the attack surface can easily be exposed publicly. Further, changes to these east-west APIs are made constantly — as fast as a company’s DevOps and CI/CD practices allow. Unfortunately, this speed of change makes mistakes, errors, and security oversights more likely. These APIs and changes are less visible, which leaves companies at risk of discovering vulnerabilities only after a hacker has breached private data.

    Security Breaches of APIs

    Data leaks through all APIs, but companies can’t protect what they don’t know. The moment APIs are exposed on the internet, they create attack vectors for hackers to extract data. If some of the largest companies in the world have insecurities throughout their codebase of APIs and services, we can bet every other company does too.

    Security breaches of APIs are so dominant because APIs are such a ubiquitous method of passing information. Data breaches come in many forms, but they almost always affect company revenue and reputation. New API breaches and vulnerabilities are discovered almost daily. Capital One, Microsoft, T-Mobile, Symantec, McDonald’s, Instagram, Salesforce.com, and Venmo have all experienced major API breaches in the past few years.

    The DevSecOps team or security specialists should make ongoing risk-based decisions on when certain issues should be mitigated, and where in the CI/CD pipeline those concerns should be tested. However, in key scenarios, active protection is required to prevent a security incident from occurring or escalating. IT teams need to use tools that add this layer of protection without requiring humans to be involved.

    The traditional approaches to API security, although helpful at reducing the attack surface, are too slow to keep up with the ever-evolving tactics of bad actors. Only with a clear and full-stack view of an application’s security can IT manage risk and enforce appropriate security policies. Without better telemetry and observability, every security decision will be a shot in the dark and critical holes in API security will be missed.

    Consistently and Constantly Analyze

    Security processes and tooling should constantly analyze the cloud environments, API gateways, logs, web and mobile applications, as well as source code for changes that might create vulnerabilities. Once IT is able to identify the changes to their system, they can confirm that authentication, authorization, encryption, access and verification meet the standards set for the team.

    Active protection without human intervention is the only way to achieve real-time enforcement of security policies and protect against attacks as they occur. Ideally, a security solution should automatically discover and inspect for API security vulnerabilities, while humans analyze the situational risk and prioritize the work.

    With active protection in place, when a security incident occurs, IT will be able to rapidly leverage critical information to appropriately identify the components of the system affected and the contributing factors that led to the event, and protect the data.