devopsy.kinsta.cloud

Tag: API

  • How Network APIs Will Finally Realize the Potential of 5G Slicing

    How Network APIs Will Finally Realize the Potential of 5G Slicing

    The applications used by people and businesses today run over the top of the network. That is, they use the network to transmit data from one point to another but don’t interact with the network in any way.

    As those applications get more advanced, that comes with a risk. If the network isn’t provisioned adequately, a self-driving car, for instance, might suddenly lose connectivity and freeze in the middle of an intersection.

    That’s why developers are progressively realizing they’re going to require more from the network if they are to create revolutionary new applications. But the catch is they’re also not network specialists.

    Instead, they yearn for quick and simple ways to tap into and onboard 5G network capabilities within their applications — to dynamically adjust connectivity speeds based on real-time conditions, for example. That’s where network application programming interfaces (APIs) enter the picture.

    In 2023, the telecoms industry committed to unprecedented levels of openness with the announcement of the GSMA Open Gateway initiative and the growing popularity of the CAMARA project.

    In 2024, there is an expectation that there could be even more momentum around and demand for open network APIs as developers start to get real access to them — and begin to explore the potential of leveraging specialized network capabilities, delivered through techniques such as network slicing for their enterprise and consumer applications.

    What are Network APIs and How Will They Be Used?

    A network API is like any other API that allows for two or more applications to communicate with each other. It’s just that, in this case, one of those applications is the network itself.

    This is possible because today’s cloud-native 5G networks are fundamentally software-based, meaning they are also programmable through APIs and other software development tools. So unlike the networks of years ago, which were more hardware-dependent and closed in nature, developers can now get easy access to deep functionality and data within the network.

    Through a network API, applications and networks can share information about their status and needs, allowing for optimizations to be made on either side. The network could signal to a drone or autonomous vehicle where other related devices are operating or whether congestion is likely to occur in a given area, enabling on-the-fly route changes to maintain optimal performance. Or the application could use that information to request specialized capabilities from the network in certain situations, such as low-latency connectivity or more uplink capacity.

    The ability to deploy specialized network capabilities for specific applications in specific locations may sound familiar. It’s essentially the promise of network slicing, which was promoted heavily in the early days of 5G rollouts but never really caught on as expected.

    This is largely because network slices have to be planned for and provisioned well in advance — a dealbreaker for applications that need to manipulate parameters such as quality of service based on real-time conditions.

    Network APIs change that, providing access to specialized network capabilities in a dynamic, automated way — whether by spinning up a network slice or through the use of other telecommunications tools. The emerging applications of tomorrow will increasingly require such specialized network capabilities.

    Consider beyond visual line of sight (BVLS) drones that are operated remotely by a person hundreds of kilometers away. As the drone travels, it will need different network capabilities at different parts of the journey based on the unique conditions it encounters along the way.

    Deutsche Telekom has been working to deploy network APIs for this very scenario, which includes APIs for location verification (for more precise tracking of the drone’s position) as well as “quality on demand,” so that as it passes over highly congested areas where thousands of people are also using up network capacity, the drone can get greater prioritization to ensure it doesn’t fall out of the sky.

    That’s just one potential use case. Network APIs can open up innovations for industrial robots, real-time streaming of immersive video using multiple cameras, latency-sensitive applications like VR and cloud gaming, and much more.

    Creating a Network-Powered System Ecosystem

    APIs can help foster a network-powered ecosystem of digital innovation that brings benefits to everybody involved. By being able to leverage specialized network capabilities on demand, developers can create innovative applications and experiences for their customers — transforming their ideas into real solutions.

    Existing applications can also be enhanced for better performance, such as drones that can reliably transmit high-definition video from any location and under any circumstances to improve the situational awareness of first responders and public safety agencies.

    For the communication service providers (CSPs) who operate the networks, these APIs will help deliver a better return on investment for their 5G infrastructure. Revenue growth for traditional communications services in both the consumer and enterprise markets is limited by an unwillingness to pay more for those services and the perception that value lies in the applications rather than the network.

    Thus, the need for CSPs to develop new revenue streams has never been greater. By charging developers for access to the network APIs — and by forging closer connections to the applications that will use the capabilities within the network — CSPs will be better able to generate monetizable value from their networks.

    What’s Ahead for Network APIs

    APIs have been around for more than two decades. The fundamental principles of network slicing have been talked about since the introduction of 4G. While these technologies have been around for years, they will come together in exciting new ways in 2024, enabling entirely new possibilities.

    In the year ahead, there will likely be a greater demand for specialized network capabilities among application developers. That demand will be driven by early digital adopters in industries such as oil and gas, automotive, industrial and high-tech manufacturing, public safety, security, gaming and entertainment, and others.

    But it’s important to note that no one company can make all this work. There needs an ecosystem of companies coming together. Developers need to demand it, and CSPs need to build systems and platforms to support it.

    Infrastructure vendors will play a role as well, with network as code platforms to provide easy access to network APIs — serving as the bridge that enables greater levels of collaboration, innovation and mutual growth so everybody can harness the full potential of 5G networks.

  • What Are You Securing?

    What Are You Securing?

    Every once in a while, I think it is important to look at the available technologies and tooling and ask, “What are we trying to do?” In the case of information security, we need to ask, “What, exactly, are we trying to protect?”

    The answers to that question are seriously limited. Availability, reputation, data. Since reputation is a business mapping of the other two, that leaves us with availability and data. Of the two, data is more important. Our systems being down absolutely costs us money, but leaking customers’ private data or our corporate secrets, like source code or technology designs, is worse in the long run.

    The problem with these observations is that if we are here to protect the data, and data is the more important piece of security, then why do we have far better application security than data leak prevention? Almost all of you have policies and processes to run an application through the wringer and get an “as secure as possible” result at the end. But data? The purpose of applications is to expose it. And in the process, we risk exposing too much of it or allowing tons of it out of a valid endpoint. I remember in the early days of login-based websites, there was a spectacular leak that let an attacker get hundreds of valid user credentials per page submission (there were a surprising number of these for a couple of years there; this one was at a college). We are facing much the same thing via APIs these days or even via pages meant to make access easier for users.

    Locking all of this behind logins is a useful step, but to use one of the many phrases we’ve stolen from military science, it is only a part of ‘defense in depth.’

    Once it is agreed that data is one of the two key things we need to protect, then the focus should be on how to do so. There are some amazing DLP products, both standalone and integrated into other technologies, that are worth looking into. There are also some great advances in automated response under the guise of AI/ML that should be watched closely because they are changing rapidly. Limiting the maximum number of responses allowed from a query is almost mandatory for application stability and for data leak prevention. And it isn’t that hard to implement.

    I assure you that ne’er-do-wells—particularly state-sponsored and corporate espionage hackers, but also amateurs—are using AI to make attacks more successful and less detectable. The least you can do is respond in kind, with some of the tools that can now do things like notify you about low-and-slow data leak attacks.

    Keep focused on what the goals are. Reiterate them often, and keep rocking it. That’s a lot of data splashing around the organization that your team is responsible for; make sure it’s as safe as possible.

  • Low-Hanging Fruit, 2023 Edition: Part One

    Low-Hanging Fruit, 2023 Edition: Part One

    We’ve been cranking it out, haven’t we? Generating cool new toys for the business, creating new infrastructure to host those new toys and trying our best to secure all this new stuff while maintaining both our sanity and our cadence. And we’re doing it. Kind of.

    One thing we’re naturally lagging behind on is security. While we don’t purposely shortchange security in our DevOps processes these days, it always takes a bit to figure out the best way to secure new technologies after they’re implemented. And we’re implementing a ton of new technologies. So our security staff (and increasingly, DevOps/SRE teams) is rushing to play catch-up. One area where this is screamingly apparent is APIs. We’re spewing them across the organization, often without cataloging or responsibility. This makes sense, as in many cases, the API is just an evolution of the function call. “I need a service, it is a good generic service, let me throw it up and we can use it from wherever the client ends up deployed,” type of thing. The problem is that leaves a ton of attack surface not truly protected. Because without cataloging or responsibility, there is no way for security to know about many of these APIs.

    API Scanning Technology

    That brings us to today’s topic. If you haven’t done so yet, it is past time to look at API scanning technology. It comes standalone and bundled with pretty much any API security product on the market and is increasingly bundled with other development security or even development tools. And the whole point is to get a list of APIs. Oh, most commercial implementations do something with that list–include it in static testing, drive it into WAFs, whatever—but just having the ability to inventory what is running on your network is reason enough to stop doing less important stuff and figure out what your exposure is. And the tools make it easy. They come in two flavors, and we should consider both.

    Static API Scanning

    The first type digs through source code and API specs to come up with the list of what is supposed to be running on the network. The big weakness of this method is that it only knows what it is told. This is static API scanning.

    Dynamic Scanning

    The second watches network traffic for API calls and then documents them, possibly even generating API specs for you. The big weakness of this method is that it only discovers what is being accessed on the network while it is watching traffic. Currently, unaccessed APIs are not caught, nor are ones on unreachable networks. Unsurprisingly, this is dynamic scanning.

    As usual, the two together are more powerful than apart. By implementing both technologies, an organization can work toward a hardcore comparison of what should be running on the network versus what is running on the network. This goes beyond detecting unreported APIs, it also means that zombie APIs or runtime drift can be discovered by comparing what is there to what should be there.

    If you’re not doing this, consider adding it to the toolbox. Setup is not onerous, and the reports are lists of APIs and parameters that can be reviewed at leisure. Some commercial products that offer these two functionalities take it quite a way beyond list generation, and if comparisons are made, work hard to understand just how much each toolset can do.

    And keep rocking it. We need more tools to lock down the new perimeter precisely because you and your team are tackling new technologies and platforms to better serve the business. We are increasingly seeing security tooling catch up with the broad selection now available, so go implement them.

  • The Case For an API-First SCM

    The Case For an API-First SCM

    Somewhere around a decade ago, about the time DevOps really started to manifest, we began seeing technology companies—including some of the largest ones today—investing heavily in their APIs.  

    API-first companies managed to rapidly gain widespread adoption because of the benefits of being API-driven. Everything from automation and scalability to flexibility, performance, speed and monetization.  Once DevOps thinking made it increasingly clear that automation would solve problems like human error and increase performance and velocity, creating more machine-to-machine interaction became a critical factor in software delivery—because the problem in the technology world was not innovation, but rather integration.

    Twilio is a prime example. The company became famous for its API-driven approach to customer management and even had a famous Silicon Valley billboard trumpeting their success. They changed the game for customer communication for some of the largest companies in the industry, from Netflix to DoorDash to Coca-Cola, by making communication completely invisible to users. These APIs largely served developers by unifying communication on the backend and providing powerful customer-facing capabilities on the business side. But they’re not the only ones.

    API-first SCM

    API-driven companies managed to disrupt entire markets nobody imagined could be disrupted, such as Stripe for payment processing and Slack for immediate communication (their former head of developer relations, Amir Shevat, said that Slack’s developers were literally measured by their API’s active tokens). Companies that harnessed the power of their APIs saw unprecedented growth over the last decade due to the integration power they unleashed. 

    Today, there really is no self-respecting dev-first technology that doesn’t invest heavily in the robustness of its APIs. There are even entire companies today built around API integrations—from marketplaces like Rapid API to security companies like Akita Software to companies like Kong that focus solely on simplifying API gateways.

    The API-First Dev Tool Revolution

    The same transformation that disrupted various business industries is now beginning to take center stage in the technology and dev tools space. This is also part of the developer experience revolution that is the stimulus for all the nifty dev tools in the first place. As developers become the new decision-makers—masters of their own domain—and are no longer being forced to adopt and use technology someone else purchased for them, the experience of using these tools impacts their choice of whether or not to add these tools to their chain. This means that those creating the tools today need to deeply understand the developer’s workflow and optimize their products for this user persona.

    This very same evolution that typical tooling underwent is now impacting age-old tooling in the developer ecosystem—and developer pain and friction are starting to come to the forefront. This includes the need for better and more robust API capabilities, “as-code” (infrastructure-as-code, testing and security) tooling, low-code/no-code and code variations and much more.  

    It’s interesting to see that, even with the cloud-native and DevOps revolution, our most core developer tool—our source code management—hasn’t really changed much in the last 20 years. Git remains ubiquitous, but its design is optimized for developer workflows from two decades ago. It’s long past time for an API-first SCM, and there are a number of use cases that can benefit from better APIs.

    Evolution and Anatomy of APIs to be Git-Native

    Even with the most exciting innovations we’re seeing from Git SaaS tools like GitHub and GitLab—from Co-Pilot to Codespaces, pipelines and more—they’re only as strong as the technology they are built upon. As the world evolves, this fundamental weakness is proving to be a sort of kryptonite.  

    Despite Git being an old-school, monolithic tool with proprietary protocols, Git hosting providers like GitHub, GitLab and Bitbucket have invested a lot into making their services API-driven to cater to tool integration. True, each has its own API, which drove some players integrating with the service (especially in the early days) to integrate via an SDK rather than an API.

    GitHub itself provides a variety of APIs—from the simpler REST through the more elaborate GraphQL. These APIs provide you with the ability to do pretty much anything, but are somewhat cumbersome for some use cases. To deal with the core Git functionality, you are required to directly manipulate objects in the Git database.

    Code Deployment and GitOps

    As engineering organizations grow, the need for greater control of code and infrastructure resources has become a real pain—and this is where GitOps provided the methods and the tools to support automated policy management at scale. This automated policy and governance is largely enabled, machine to machine, via APIs, and many of its controls are built on code and configuration files that are hosted via Git (hence its name: Git Operations).

    When using this methodology, a configuration change is first committed to Git (as the single source of truth that will apply changes in all the relevant places). Only then does this trigger automatic processes to apply these changes universally. In some cases, these automatic processes have to commit files to Git via API.

    Another area where SCM APIs play a key role is versioning and release management.  DevOps teams need to manage the release of new versions of their applications, including creating release notes, tagging releases and creating release branches. These processes, which sometimes take place multiple times every day, include many steps and require accuracy—a comprehensive suite of efficient APIs is critical for such an operation.

    UX Customization

    Today, there’s a huge diversity of stakeholders in modern engineering processes, particularly in the context of game development, but this is also true in any kind of web-based or UI-based engineering, as well. Today, product and design are an integral part of engineering processes, but Git still remains the domain of developers.

    There are times when you’d like to have a unified interface for your asset management that pulls data from multiple APIs and sources—such as Git for source control and Google Drive for large files. The added benefit is to abstract and decouple the underlying technology from the user experience and interface so that users can be free to migrate and move between their technologies of choice. This is true whether at the SCM or the storage level without having to change the interface that the team is accustomed to.

    APIs that efficiently perform the full set of SCM functionality allow developers to use a single backend for managing code versions while still providing end users with the desired experience, regardless of what that might be.

    Versioning-as-a-Service

    SaaS products have made it significantly easier to manage and maintain our services through simple UIs and dashboards. However, this simplicity also has a tradeoff. Have you ever made a simple configuration or code change, quickly regretted doing so and then attempted to revert it via your SaaS console? In most SaaS apps that aren’t managed as code, this happens all the time—from Okta to Datadog and many others. Without the benefits of “as-code” and the version control that comes with it, reverting changes is nearly impossible.

    The most you can achieve is “undoing” a previous configuration—if you can still catch it with a CTRL+Z—simply because engineering didn’t bother (or did not have the resources) to implement versioning. Imagine if this could come as a service for all of your SaaS applications!

    For software developers, API-based version control will unlock the possibility of easily incorporating rich version control capabilities into their product—in the same way they can currently use other capabilities such as database, file storage, etc. 

    The World is Ready for an API-First SCM

    TL;DR: API-first models have delivered some of the greatest innovations that ‘dinosaur’ industries—from payments to communications—needed to move faster and do so securely. It is almost laughable that the technology industry has inherent limitations due to a core technology that has a legacy design. This should not be a technology limitation we should accept.  

    Our source code should be able to be controlled, manipulated and transformed via API to remove human toil from places it isn’t really needed and free people to focus on higher-order problems.  With the widespread adoption of generative AI and smarter machine overlords, we’ve discovered that there are many formerly manual tasks that we can offload to machines. Free SCM APIs to unlock the next generation of innovation—because soon there will be more machines than humans to manage them. APIs are the key to tapping into this power. 

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

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

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

    The Rise of APIs and Mixology

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

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

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

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

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

    Maintaining Confidence in Ever-Changing Recipes

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

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

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

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

    Documentation is Key

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

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

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

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

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

    Continuous Improvement = Continuous Education

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

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

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

  • State of Developer Experience Report Finds Growing API Reliance

    State of Developer Experience Report Finds Growing API Reliance

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

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

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

    Rising Importance of APIs

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

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

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

    APIs Bring Developer Experience Benefits

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

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

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

    Developer Experience Improvements

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

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

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

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

    Looking Through the Micro Lens

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

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

  • Modern DevOps is a Chance to Make Security Part of the Process

    Modern DevOps is a Chance to Make Security Part of the Process

    I’ve mentioned before, and many of you have lived through, the slowly changing beliefs around DevOps versus security. We are past the days of “Security slows us down” and into “How can we bake security into the development process?” which is essential. Indeed, I would say it’s more essential every day as the number of threat actors and their use of automation to perform more attacks increases.

    So where can we slip in a little security to protect those sweet, innocent apps from the Big Bad Wolf? Let’s make a list, then chat about it.

    • Source code
    • Inclusions–libraries, shared objects, etc.
    • Container/cloud images
    • Network
    • Running applications and APIs

    This is honestly not an exhaustive or detailed list, but we’re writing a blog here, so let’s stop there so we have time to discuss.

    Source code security is greatly enhanced by putting in any of a dozen development security tools, which include static and dynamic security scanners along with a variety of other features.

    Inclusions are often nested and confusing. A mod that developers include relies on other mods and libraries—sometimes so many that the developer can’t even list them all. So, this type of security starts with software composition analysis (SCA), then uses the list that generates to pursue vulnerabilities—normally by looking for the included libraries in a vulnerability database. Several prominent source code security solutions bundle at least the SCA part, and some also help nail down included vulnerabilities. Check with your vendor if you’re just getting started here.

    Container images are akin to the “golden images” of old. Build one that has what most applications need, add on the security that an organization wants most applications to support and then have every project start there and only add what this specific app needs. That allows for scanning of the base image so all applications start out at least somewhat secure. Cloud images can be done much the same, but beginning at a higher level. Look into registry security or image scanning tools to meet this need. It is worth asking your source scanning vendor if they offer this functionality; some do.

    The network on which an application will be exposed needs to be locked down. While the access points into the org probably are protected, portability of applications means that the application itself should be locked down wherever it uses that network. Tools are specific to the platform and networking in use, so look into it—I can’t offer much more generic advice.

    Security has long tried to lock down running applications—generally with pushback from developers and even ops, a bit. Between web application firewalls (WAFs) and API security, we have the ability to stop a whole host of attacks on their way in … But you have to use WAFs and API security best practices. If you’re starting from scratch, consider tools in the application and API security space that protect against both the web UI and API attacks with a breadth of technologies. For those with a WAF, look at API security tools that protect APIs. For those with API security covered, consider a next-generation WAF.

    My usual encouragement applies. You are rocking it, and all of these tools are increasingly integrated into the DevOps toolchain, so it’s worth the time investment to get them set up and let them run. If you’re just starting out, start with source code security. Honestly. It will make the overall app more secure by tightening its source. But don’t ignore the ops side, as that is part of the attack surface. Protect those apps you built and/or maintain that are keeping the org running.

  • Tips For Standardizing API Life Cycle Management

    Tips For Standardizing API Life Cycle Management

    Software life cycle management is becoming more critical for today’s technology-fueled organizations—because you can’t just release software into the world and expect it to work perfectly for years to come. More often than not, development teams must constantly adapt their software, progressively add features and cater to new use cases as they arise. This is nothing new for web APIs, which are prone to continual evolution and whose integrations require regular upkeep to avoid breaking changes.

    As such, the discipline of API life cycle management has gathered steam. This concept focuses not only on the design and development of APIs, but on the entire life cycle, including testing, monitoring, documentation, maintenance, versioning, CI/CD and even deprecation. Localizing a strategy for API life cycle management from the get-go can increase the longevity and usability of a platform. It also helps software providers treat their APIs as an iterable product rather than a one-and-done offshoot of a digital platform.

    I recently met with Rakshith Rao, co-founder and CEO of APIwiz, to gather insights on standardizing API management across an organization. According to Rao, there are many ways to implement governance to make these interfaces more consistent. For example, automated security analysis, contract-driven development and implementing style guides are just a few ways to wrangle an increasingly extensive API portfolio. Below, we’ll review these tips and others to consider how to best manage API life cycles, hopefully, before sprawl sets in.

    Four Tips to Increase API Governance

    Medium-to-large organizations might be handling thousands of APIs, said Rao. This new paradigm brings many opportunities for digital transformation, but it can also be a nightmare to manage. Too often, APIs aren’t built with tangible business requirements taking center stage.

    Many of these initiatives didn’t begin with consistent policies from the get-go. For example, it’s also easy to skip out on documenting internal services. But, fractured practices harm discovery and reusability. To rectify this issue, Rao shared many ways in which technical leads can promote better API hygiene.

    Enable Visibility of API Usage With API Monitoring

    The API life cycle spans stages of design, deployment, deprecation and eventual retirement. And throughout this life cycle, developers will likely release new versions of the same service. But although you want consumers to adopt the latest version, some large organizations must support legacy versions for years to come, explained Rao. As a result, different API versions are often developed and run simultaneously by various internal or partner teams. Sometimes, “no one turned the tap off and the water’s still running,” he said.

    To enhance visibility for all active (and non-active) sessions, it’s important to conduct ongoing monitoring. This will help discover individual client usage patterns and help avoid shadow or zombie APIs from forming. These forgotten endpoints could pose security vulnerabilities, said Rao, as you might not enforce best practices on older versions if you don’t know they exist.

    Automate Security Analysis to Capture Vulnerabilities at the Design Level

    Not having consistency between APIs could pose data compliance issues. One method to avoid errors is to conduct design reviews on an ongoing basis, and to automate this security analysis at the design level, said Rao. Perhaps authentication tokens need to be encoded, logging requests aren’t coming in, or payloads are structured incorrectly. Whatever the case, having a complete checklist to scan and performing ongoing security analysis early on to catch these inconsistencies can be a big boon to overall governance and long-term cybersecurity.

    Adopt Style Guides but Allow for Flexibility

    Very simple data modeling errors could severely impact a system, said Rao. Thus, it’s in an organization’s best interest to use standard taxonomies and ensure data governance is an overall aspect of life cycle management. One way to ensure consistency is by using specification-driven development—OpenAPI is a common standard for this need.

    Rao also suggested developing API design style guidelines but admitted that these guides become challenging to enforce and limit as an organization scales. This is because various teams in different departments will have different API needs and often design their interfaces for various front-end requirements. His takeaway is to centralize practices but take a GUI approach to configuring and sharing them. This way, API style can be “minimally intrusive but uniformly enforced.”

    Use an Abstraction Layer for Multi-Cloud

    A full 98% percent of enterprises are using at least two cloud infrastructure providers, according to a recent Oracle report. Nearly everyone is adopting a multi-cloud strategy, but this new reality brings novel pressures for DevOps, especially when overseeing the deployment of APIs across different cloud platforms. An API life cycle management platform decoupled from these CSPs could help wrangle polyglot deployments.

    Sticky Notes Aren’t Enough for API Management

    API life cycle management goes well beyond the development and runtime phase. And as more API-first development occurs within organizations, maintaining standard interfaces will naturally require more effort. Rao also advocates for increased infrastructure automation and low-code solutions to meet these new challenges. Automating various parts of the API life cycle so there is less manual work “helps to bring down the guesswork of ensuring reliability when you release an API,” said Rao.

    We’re seeing some enterprises move from supporting hundreds to thousands of APIs. In this new paradigm, “API sprawl is imminent,” said Rao. As such, it will become virtually impossible to manually keep these interfaces in line, understating the need for more automation. Especially during times of economic uncertainty and leanness in the tech market, the democratization of such API management automation will be vital in helping organizations move faster.

    Having broken pieces of information and scattered API contracts will lead to a messy and potentially insecure adoption. As such, API management can no longer be done using sticky notes on the edge of a computer screen, said Rao. Taking the guesswork out, centralizing common policies and shifting more legwork behind the scenes will be required to avoid a splintered portfolio of services.