devopsy.kinsta.cloud

Tag: APIs

  • Low-Code Makes API Testing More Accessible

    Low-Code Makes API Testing More Accessible

    APIs are rising both in quantity and business value. But with that growth comes an increasing number of vulnerabilities, which could affect cloud service dependencies and internal APIs. Functionality and uptime could also suffer as cloud services evolve their APIs with new versions. Thus, API endpoint testing is critical to ensure a reliable back end. With growing interest across the organization to stabilize these integrations, how do we test APIs in a reproducible way that non-developers can grasp?

    Low-code platforms — tools that enable workflows with visual programming models — are opening doors for citizen developers to construct applications in a visual mode. Similarly, the low-code concept could aid API testing by providing an easier method to create API tests to verify functionality and uptime. This could arm quality assurance, DevOps and site reliability professionals with an easier means to test high-value integrations and their UI representations.

    Amid a growing headless movement, APIs are now powering many end-user experiences. However, during a developer drought, it may be challenging to find talent with integration know-how.

    I recently met with Dan Belcher from Mabl to discuss combining low-code and API testing. Here, we’ll uncover why it’s difficult for non-engineers to conduct API testing and consider what API testing must address to ensure today’s software meets tomorrow’s digital innovation demands.

    A Low-Code Approach to API Testing

    The software landscape has evolved rapidly in recent years. “Many forces have combined to create an incredible amount of change,” said Belcher, citing DevOps, CI/CD, the API economy and agile enterprises as examples. In this era, applications are becoming more dynamic, disrupting the way teams conduct end-to-end quality testing.

    API-based cloud services are part of this new frontier, becoming popular building blocks within modern applications. Yet, integrations require upkeep as cloud services evolve and version. Without continuous testing of API-based cloud services, organizations could easily suffer from breaking change and poor usability.

    Unfortunately, as it stands, typical QA teams aren’t well-equipped to handle ongoing regression testing for APIs. Instead, “developers, historically, have been the only ones that understood API testing,” explained Belcher. For years, API testing has been relegated to the realm of developers, who use tools like Postman to perform unit-level testing. But why is API testing so difficult for others?

    What Makes API Testing Difficult?

    Well, to start, non-engineers are typically more accustomed to UI-based testing. These environments use a structure designed for anyone to consume, making it easy to locate fields and confirm values, Belcher explained. When it comes to API testing, you often must handle massive chunks of JSON responses to match fields and surface issues. Testing API responses typically requires writing code, parsing JSON and writing it to variables, Belcher explained, which may be difficult for non-developers to implement.

    Or, difficulties could arise when testing asynchronous endpoints, Belcher added. Asynchronous APIs often involve background server processes that take a while to respond. This comes at a moment when event-driven architecture (EDA) is a growing trend. Take AsyncAPI, a standard API specification for EDA APIs, which recently joined the Linux Foundation. A recent report found AsyncAPI production usage tripled from 5% in 2019 to 19% in 2020. According to Belcher, testing such asynchronous services requires an infrastructure for continuous testing to anticipate these emerging scenarios.

    Four Crucial Areas For API Testing

    So what should API tests be focusing on? Belcher highlighted four areas that warrant close examination throughout the API testing process:

    • Functionality: This is the core functionality. Does the API do what it promises? Does it return the correct data?
    • Uptime: What is the API’s availability? Are all endpoints available in production?
    • Speed: This ensures cloud dependencies meet SLAs. What is the latency? Is there drift in API performance over time? Though API monitors like Api.expert help aggregate industry performances, they might not always reflect your specific customer-level realities. Belcher recommends not placing faith in supposed performance and instead, clocking your own.
    • End-to-End: Belcher stresses the role APIs now play across customer-facing presences. An end-to-end workflow should involve API endpoints, how they interact with one another, and the resulting visual representations. “Just like we have end-to-end testing for UIs, we should have end-to-end testing for APIs,” he said.

    API testing isn’t always combined with other parts of the user experience, but Belcher believes, going forward, end-to-end testing will be critical to ensure all workflows function in concert. For example, if a user profile is created within a browser, teams should verify the user profile has been created at an API level, as well.

    Low-Code API Testing and Shift Left

    APIs are beneficial to avoid reinventing the wheel. However, 100% operational uptime is impossible. Applications will inevitably encounter API problems, including outages, technical failures and functional misrepresentation. Developers also often come to rely upon production behaviors that may not be officially documented, an effect known as Hyrum’s Law. This can cause unstable integrations as APIs version over time.

    Thus, for these reasons and more, it’s a good practice to adopt continuous API testing. With the surging interest in site reliability engineering, spotting API errors early on will become an important aspect in reducing mean time to recovery (MTTR). Testing third-party APIs could also expose production latencies to inform cloud investments.

    “As the pace of change is going up, how do we deliver great quality to our customers?” Belcher asked. API testing is one answer to address this rapid change, and is growing in importance for the software delivery life cycle. It especially rings true for headless frontend experiences, where the API-driven backend isn’t transparent to QA testers.

    Low-code capabilities for API testing could help tear down silos inherent in the development process, enabling more people to participate in testing integrations. Belcher also stresses the importance of improving the usability of API testing for developers and non-developers alike. “We need to integrate with tools developers are already using for verification,” he added.

  • 42Crunch API Security Platform Now Available On-Premises

    42Crunch API Security Platform Now Available On-Premises

    42Crunch has announced that the scanning tools it provides to enable DevOps teams to secure application programming interfaces (APIs) can now be deployed in on-premises IT deployments.

    Previously only available as a cloud service, the 42Crunch API Security Platform has also been updated to provide expanded support for the OpenAPI specification for REST interfaces defined by the OASIS standards body.

    Finally, the 42Crunch API Security platform now allows IT teams to share collections of APIs among specific teams and users with different levels of access in addition to providing integration with third-party identity management platforms.

    Dmitry Sotnikov, chief product officer for 42Crunch, said the on-premises edition of the API scanning platform will make it possible for IT organizations, including those that require all the platforms they run to be deployed in an IT environment, to exercise more control over and extend their DevSecOps workflows to include scans of APIs.

    Cybercriminals are increasingly targeting insecure APIs because they potentially provide access to a trove of data, Sotnikov noted. Those same APIs also enable cybercriminals to compromise an entire software supply chain, Sotnikov added.

    At a time when more organizations are deploying APIs, thanks to the rise of microservices, it’s apparent there is a greater need for a tool that dynamically scans APIs for vulnerabilities before they are deployed, said Sotnikov.

    In general, Sotnikov said IT organizations are becoming more sophisticated in their approach to securing software. Ford Motor Co., for example, is using the 42Crunch API Security Platform to secure both internal and external APIs, Sotnikov said. 42Crunch claims its revenues increased 900% in 2020, with more than 150,000 users of the platform.

    As organizations of all sizes become more dependent on software, cybersecurity teams are now reviewing how that software is constructed. Of course, responsibility of security is still shifting left as part of the overall transition to DevSecOps best processes, but Sotnikov said cybersecurity teams still want to verify for themselves that whatever software is deployed is secure. IT organizations are moving away from a “whack-a-mole” approach to security as they embrace DevSecOps, Sotnikov added.

    Unfortunately, APIs don’t always receive the level of attention they deserve. Many developers still tend to view them as an afterthought, and once deployed, it’s not uncommon for APIs to languish for years without being reviewed or updated. Making sure APIs are secure requires dynamic scanning processes to be baked into DevOps workflows if organizations want to ensure the integrity of their software, said Sotnikov.

    APIs are, of course, everywhere now. The days when a handful of APIs were exposed to share data with a limited number of customers and partners are long over. There are almost no applications built and deployed today that doesn’t expose myriad APIs. Cybersecurity teams obviously can’t keep pace with the rate of change being made to those APIs, as new ones are added and others updated or replaced. The onus for securing all those APIs is, now more than ever, clearly on the DevOps team.

  • Linux Foundation Takes Control Of AsyncAPI Specification

    Linux Foundation Takes Control Of AsyncAPI Specification

    The Linux Foundation announced today that it now plays host to an AsyncAPI Initiative that has developed a specification and a suite of open source tools for asynchronous application programming interfaces (APIs) and event-driven architectures.

    Founding sponsors of the AsyncAPI Initiative include Ably Realtime, Apideck, Bump, IQVIA Technologies, Slack, Solace and TIBCO. Most recently, Postman, a provider of API management tools, committed to providing engineering resources to the project as well.

    AsyncAPI provides a language for describing the interface of event-driven systems, regardless of the underlying technology, and supports the full development cycle of event-driven architecture. That approach helps unify documentation automation and code generation, as well as managing, testing and monitoring asynchronous APIs.

    Chris Aniszczyk, CTO and vice president for developer relations at the Linux Foundation, said the Linux Foundation will work with the member organizations to facilitate a governing framework similar to the frameworks other open source projects have adopted under its auspices.

    In general, reliance on event-driven architectures is on the rise thanks, in part, to the rise of digital business process initiatives that require the processing and sharing of data across multiple platforms in near-real-time. The AsyncAPI Initiative makes it simpler for disparate event-driven platforms to be integrated. It’s unlikely multiple organizations involved in a digital business initiative are ever going to standardize on the same event-driven platform, so an AsyncAPI specification provides a critical linchpin.

    Usage of the AsyncAPI Initiative is already fairly widespread, with Adidas, PayPal, Salesforce, SAP and Slack all employing it in production environments. In fact, the Linux Foundation cited research that identified AsyncAPI as the fastest-growing specification being implemented by developers, after seeing adoption rates in production environments triple from 2019 to 2020.

    Event-driven IT architectures have, of course, been around for decades. However, as they have gained traction in the modern era of software development, the need for the equivalent of a REST API for asynchronous communications between platforms, based on different event-driven architectures, became apparent. The AsyncAPI doesn’t replace the need for other types of API specifications, but Aniszczyk noted that, over time, it will soon player a larger role, especially as cloud-native application environments become more distributed and the number of use cases that can’t be addressed using traditional batch-oriented techniques continues to rise.

    In the meantime, the number of providers of event-driven platforms based on proprietary architectures spans vendors ranging from Oracle and IBM to cloud service providers such as Amazon Web Services (AWS). At the same time, open source messaging platforms such as Apache Kafka are starting to have a significant impact on how IT teams build their own event-driven platforms.

    The level of enthusiasm for an API specification that makes all those platforms more interoperable than they would otherwise be is unclear. However, as modern IT platforms continue to evolve, more IT teams are becoming aware of the crucial role API specifications play in preventing them from becoming locked into one platform.

  • DevSecOps May Be Key to Prevent Data Leaks

    DevSecOps May Be Key to Prevent Data Leaks

    Data leakage has become something of a norm in the digital realm, despite the fact that cybersecurity budgets are growing and more engineers are assigned to these very issues. Nowhere does this seem more true than in the realm of health care, where breaches that expose sensitive patient data are, sadly, a fairly common occurrence. 

    A recent report by Approov illustrates how severe the problem has become. According to Approov’s  All That We Let In research report, many of the mobile healthcare applications in use today are leaking sensitive patient data through APIs, potentially compromising millions of patients. 

    The study tested 30 popular mobile health (mHealth) apps, and the research estimates that some 23 million mHealth users are exposed, at a minimum. The average number of downloads for each app tested was 772,619. Analysts expect that the total number of users exposed by the 318,000 mHealth apps now available on major app stores is likely far greater. Among vulnerabilities detailed in the report:

    • 50% of the records accessed contained names, Social Security numbers, addresses, birthdates, allergies, medications and other sensitive data for patients.
    • 50% of the APIs tested allowed users (medical professionals) to access the pathology, x-rays and clinical results of other patients.
    • 50% of the APIs tested did not authenticate requests with tokens.
    • Of the 30 popular apps tested, 77% contained hardcoded API keys, some of which don’t expire, and 7% contained hardcoded usernames and passwords. Seven percent of the API keys belonged to third-party payment processors that warn against hard-coding their secret keys in plain text.

    “Look, let’s point out the pink elephant out in the room,” said Alissa Knight, researcher and author of the report. “There will always be vulnerabilities in code, so long as humans are writing it. Humans are fallible. But, I didn’t expect to find every app I tested would have hard-coded keys and tokens, and all of the APIs to be vulnerable to broken object-level authorization (BOLA) vulnerabilities allowing me to access patient reports, X-rays, pathology reports and full PHI records in their database. The problem is clearly systemic.”

    The report helps to illustrate a critical point: Sloppy code can lead to data leakage. “These findings are disappointing, but not at all surprising. The fact is, leading developers and their corporate and organizational customers consistently fail to recognize that APIs servicing remote clients, such as mobile apps, need a new and dedicated security paradigm,” said Approov founder and CEO David Stewart. “Because so few organizations deploy protections for APIs – that ensure only genuine mobile app instances can connect to backend servers – these APIs are an open door for threat actors, and present a real nightmare for vulnerable organizations and their patients.” 

    For organizations deploying apps using a DevOps methodology, it becomes very clear that much more must be done on the cybersecurity side to prevent data leakage. However, the general consensus is that data protection falls under the purview of CISOs and cybersecurity teams in the enterprise. Perhaps there is no better argument for adopting DevSecOps than the data leakage problems caused by insecure code and sloppy APIs. The report echoes that sentiment and offers several recommendations for developers creating and organizations using mobile applications. In other words, organizations should take several key steps to protect their customer data and sensitive resources, including:

    •  Address both app security and API security: Recognize that synthetic traffic to the API is an issue, and arises from bots and automated tools, not from genuine apps and legitimate data requests.
    • Shift left and shield right: Secure the development process and harden apps, but ensure that runtime protection is also in place.
    • Protect against X-in the middle attacks: Certificate pinning is critical, but often left undone because expired certificates can block apps and impact customer experience. However, when done correctly, certificate pinning does not impact either performance or availability.
    • Improve visibility into controls: Organizations and developers need to monitor the effectiveness of the controls they implement and adjust them easily – both for compliance with legislative mandates and to sustain data security and privacy.
    • Continuous testing: Penetration testing and static and dynamic code analysis should be performed regularly.

    Interestingly, those recommendations fit squarely into the role that DevSecOps should take in the DevOps process. 

  • Esri Unveils PaaS Environment for Calling Geospatial Data via APIs

    Esri Unveils PaaS Environment for Calling Geospatial Data via APIs

    Esri today unveiled a platform-as-a-service (PaaS) environment through which developers can embed geospatial capabilities into their applications by making an application programming interface (API) call to a cloud service.

    Euan Cameron, CTO for developer technology at Esri, said the ArcGIS Platform will make it simpler for developers to incorporate mapping capabilities enabled by a geographic information system (GIS) system with, for example, a mobile application. The entire ArcGIS software stack can be accessed by those applications by making an API call. Previously, IT teams would have to stand up the entire Esri platform on their own to provide development teams with access to the Esri geospatial platform.

    The PaaS environment also makes it possible for developers to access professional-grade geospatial content that can be plugged directly into their applications, Cameron said.

    Geospatial platforms gained prominence with the popularity of mobile applications that require mapping capabilities. With the expansion of 5G wireless networks, the number of applications that require similar capabilities will continue to grow, Cameron said. A PaaS environment that abstracts the complexity of managing a geospatial platform behind a set of APIs will make it easier to build those applications at scale, Cameron said.

    There are, of course, other approaches to making geospatial databases available as a service. However, Cameron said Esri has long history of providing these capabilities alongside content it curates across a wide range of consumer and business applications. Those capabilities are now an API call away from any application, Cameron said.

    Of course, DevOps teams will need to integrate a PaaS environment that can be invoked as a cloud service within their overall workflow. Esri is committing to making its PaaS offering available on a global network of data centers to minimize latency for applications making API calls to its platform.

    These days, it’s hard to imagine an application that doesn’t require at least some degree of geospatial capabilities. Time and place have become critical elements of any application experience. The total cost of providing those capabilities drops considerably when the geospatial platform required to enable them is managed by its provider. In fact, as application development continues to evolve, DevOps teams often find themselves orchestrating a broad range of API calls to external services. Each one of those calls is simple enough, but over time, the sheer number becomes challenging to manage. Nor is the quality of the APIs surfaced by each service always of the same quality.

    Regardless of how geospatial capabilities are integrated into an application, the days when dedicated teams managed complex GIS platforms may finally be coming to an end.

  • DataStax Delivers on Open APIs Commitment

    DataStax Delivers on Open APIs Commitment

    DataStax announced today the general availability of the open source Stargate application programming interface (API) framework for building applications on the Cassandra database.

    Ed Anuff, chief product officer at DataStax, said Stargate will make it easier for developers to use de facto standard REST API, GraphQL API, schemaless Document API or JSON to build applications that run on Cassandra.

    Previously, developers had to employ a unique set of APIs to build applications for an open source database based on wide-column store architecture. That often resulted in IT teams employing Cassandra only when their applications ran into scaling issues on other platforms, said Anuff.

    Stargate will now make it possible for developers to use APIs they already know to build applications that are deployed initially on Cassandra. That, Anuff said, should reduce the headaches that are encountered whenever an organization is required to move an application from one database to another.

    Stargate is available for download via the Astra cloud database service, a managed instance of Cassandra provided by DataStax. Initially previewed last summer, Stargate also makes it possible to store JSON objects in Astra without any upfront modeling required to more easily prototype applications without having to pre-define schema and queries.

    DataStax is clearly trying to make it easier for developers to both build applications for Cassandra and move them if required. Many developers tend to embrace document databases early on simply because they tend to be more accessible and don’t typically require a database administrator to deploy and manage. As those applications start to scale, however, it’s not uncommon for developers to have to rehost them on another platform.

    In general, Anuff said database management is finally starting to be incorporated into a larger set of DevOps processes within many IT organizations. At the same time, traditional DBAs are migrating into DataOps or CloudOps engineering roles that have been created to manage data across a wide range of data stores. The days when DBAs typically identified themselves with a single type of database platform are now largely over, he said, noting IT organizations are instead moving to models where data is made available as a service regardless of where it is stored via standard APIs.

    DataStax is making a case for using Cassandra as the foundation for data services because of the platform’s ability to scale those services over time.

    It’s hard to say how the database platform wars will ultimately play out. Many IT teams routinely make use of a wide range of databases and data stores. Nevertheless, there is now a lot more pressure to reduce the total cost of IT, which may lead more organizations to rationalize the number and types of database platform they support.

    Regardless of the database platform selected, the way data is accessed in the enterprise has utterly changed. The challenge now is conforming the processes employed to build and deploy applications to the way data is now managed.

  • Survey Surfaces High Reliance on DevOps to Build and Deploy APIs

    A survey of 13,586 IT professionals who work with application programming interfaces (APIs) published today by Postman, provider of an API development platform, finds best DevOps practices are now widely employed to both produce and consume APIs.

    The primary method through which teams working on APIs collaborate is by sharing URLs (42%). However, publishing API artifacts to GitLab, GitHub, Bitbucket or other repositories came in a close second at 40%, followed by publishing API documentation to an API portal (39%) and instant messaging (28%).

    When queried about change management practices specifically, Git repositories topped the list at 63%, followed by versioning APIs (59%), versioning server code (34.6%), versioning client code (27.8%) and semantic versioning (21%).

    Respondents said when it comes to deploying APIs, the most widely used option was continuous integration/continuous delivery (CI/CD) pipelines (53%).

    A total of 77% of respondents listed their functional area as engineering/development, followed by DevOps/API Ops at 34% and developer relations/evangelism (13%).

    Among DevOps practitioners that participated in the survey, Jenkins is the most widely employed platform (41%), followed by AWS DevOps (30.7%) and Azure DevOps (26.1%).

    Overall, the survey finds REST is still the dominant architectural style for APIs (93%), followed by webhooks (34%), SOAP (33%) and GraphQL (23%). JSON Schema is the dominant API specification (76%), followed by Swagger 2.0 (44%), OpenAPI 3.0 (28%) and GraphQL (23 %).

    When asked to rate the percentage of their organization’s development effort spent working with APIs, 41% said more than half of the effort is spent on APIs.

    Kin Lane, chief evangelist for Postman, said the survey also makes it clear that more organizations have adopted an API-first philosophy to application development. Over 60% of respondents rated themselves as 5 or better out of 10 in terms of embracing an API-first philosophy.

    Nearly half of respondents said investment of time and resources into APIs will increase over the next 12 months, while another third stated that investments into APIs will stay the same. Eighty-five percent said APIs are playing a significant role in their digital business transformation initiatives, while nearly a third (31%) also noted APIs played a role in their organization’s ability to respond to COVID-19 by, for example, enabling customer communications or remote work options.

    APIs appear to have become a lot more stable in recent years, with more than half of respondents reporting APIs do not break, stop working or materially change specification often enough to matter.

    When it comes to producing APIs, the No. 1 obstacle by a wide margin is lack of time, while the No. 1 obstacle cited for consuming API is lack of documentation.

    The four most important factors individuals consider before integration with an API are reliability (72%), security (71%), performance (71%) and documentation (70%).

    Looking to future technologies, respondents appear to be most interested in microservices (49%), Kubernetes (44%) and containers (42%). Given the cloud-native attributes of those technologies, it appears all but certain the number of APIs strewn across the extended enterprise is about to increase exponentially.

  • Volterra Service Mesh Service Automatically Discovers APIs

    Volterra Service Mesh Service Automatically Discovers APIs

    Volterra announced today it has updated a service mesh it makes available via a software-as-a-service (SaaS) platform to include the ability to automatically discover all the application programming interfaces (APIs) in an application using machine learning algorithms, then automatically apply all the whitelist policies that apply to those APIs.

    Service meshes add a programmable layer of abstraction above a proxy server that makes it easier for IT teams to provision networking and security services on demand. The challenge is service meshes tend to be complex to deploy and between the service mesh itself and the underlying proxy server software also consume a significant amount of resources.

    Company CEO Ankur Singla said Volterra addresses that issue by making VoltMesh available as a service that DevOps teams can invoke remotely to simplify the provisioning of network services without having to deploy and maintain a service mesh on their own. Volterra claims VoltMesh has already been embraced by more than 50 enterprise IT organizations and service providers. VoltMesh can also be globally extended to clusters across multiple cloud providers via an application delivery network (ADN) that the company also manages.

    Singla said VoltMesh is shifting control over networking and security services left toward DevOps teams by employing a network fabric delivered as a service that eliminates the need to deploy separate load balancers, API gateways and web application firewalls for each cluster. That network fabric also provides DevOps teams with a zero-trust architecture for networking services that better ensures application security because it is managed by Volterra, added Singla.

    In general, service meshes are emerging as a critical linchpin in the convergence of network operations and DevOps processes. Most DevOps teams can provision virtual machines in a matter of minutes. However, outside of a public cloud it can still take days or sometimes weeks to provision networking and security services. Service meshes provide a mechanism for programmatically exposing networking and security services to APIs without requiring networking staff to manually provision each individual appliance, router and switch using command-line interfaces (CLIs) that are unique to each device.

    It’s too early to say to what degree IT organizations may decide to rely more on external networking services. However, more organizations are showing a marked preference for devoting more of their limited resources to developing and deploying applications. Everything required to run those applications simply becomes yet another cloud service that can be programmatically invoked.

    Naturally, the implications of that transition for network operations teams could be profound. Many organizations have “sunk costs” in enterprise networks measured in multiple millions of dollars. However, at a time when DevOps teams are being challenged to deliver applications faster than ever, tolerance of rigid networking services is declining. Many DevOps teams will simply opt to rely on external networking services in much the same way they opt to employ virtual machines in the cloud versus waiting for internal IT teams to make resources available in a local data center. When it comes to traditional approaches to networking, time and patience are running out.

  • Mendix Adds Git Repository Support to Low-Code Platform

    Mendix Adds Git Repository Support to Low-Code Platform

    Mendix today updated its low-code development platform to add support for Git repositories as part of an effort to make it easier to share and reuse code, as well as a visual conflict resolution capability that enables developers to easily see the differences between multiple versions of the same code.

    Announced at its online Mendix World 2.0 conference, Mendix 9 also now provides access to a Data Hub based on a searchable Mendix Data Hub Catalog, an open, standards-based metadata repository designed to help developers discover data more easily.

    The Data Hub Connect tool enables organizations to populate that Data Hub. The first connectors being made available are an open source oData connector and connectors to Siemens Teamcenter and SAP applications. Mendix is a subsidiary of Siemens. Mendix is also including an External Entities capability that presents data from remote systems as if they were local resources.

    Sheryl Koenigsberg, global director of marketing at Mendix, said the Data Hub Catalog is designed to make it easier for developers to drag-and-drop data into applications as part of an effort to streamline processes.

    Mendix today also unveiled a Workflow Editor, through which development teams can invoke workflow templates for both machine-executed and human-executed processes. These workflows can be accessed via a central task manager, and pre-configured dashboards to track and manage workflows are available.

    In addition, Mendix has enhanced Mendix Assist, the artificial intelligence (AI) tool within the platform to include a bot specifically focused on performance issues. Mendix Performance Assist analyzes applications against known best practices to either suggest or automatically implement changes that ensure solutions don’t implement anti-patterns that deprecate application performance.

    Mobile application development is being improved with support for Progressive Web Apps (PWAs). Developers now can deploy different types of mobile applications using, for example, a highly interactive React Native framework alongside a traditional browser-based framework within the same solution using the familiar Mendix modeling tools.

    Finally, Mendix is making available augmented reality (AR) widgets to make it much easier to build the next generation of exciting business applications. Developers can now easily create a user interface, including 3D objects, images and marker detection.

    Koenigsberg said Mendix is squarely focused on accelerating the development of critical digital business applications. In the wake of the COVID-19 pandemic many organizations are turning to low-code tools to allow professional and citizen developers to build applications faster. From a DevOps perspective, low-code tools such as Mendix 9 accelerate the velocity at which applications are being built and ultimately deployed using low-code tools that abstract away much of the complexity associated with building those applications.

    Mendix 9 effectively represents an effort to extend the reach and scope of that layer of abstraction across a much broader swath of the application development life cycle, added Koenigsberg.

    It’s too early to say to what degree the COVID-19 pandemic has driven organizations to embrace low-code tools more broadly. However, at a time when many DevOps teams are under pressure to deliver more code faster than ever, chances are good low-code platforms are building many of the digital business applications that organizations now need to survive and ultimately thrive.

  • APIs: The Secret Sauce for Low-Code Platforms?

    APIs: The Secret Sauce for Low-Code Platforms?

    As companies become increasingly talent-strapped, APIs are helping spur a low-code movement to help them remain competitive

    Low-code platforms have the potential to alter how software is built and delivered. By focusing on visual flows and drag-and-drop UIs, low-code platforms dramatically lower the barrier to software development.

    Yet, anyone with a toe in the no-code waters will tell you the space is full of half-promises. Can you scale an entire enterprise software architecture with zero code? Probably not. Can a low-code platform single-handedly create and expose compelling infrastructure? Maybe.

    I recently met with Jon Scolamiero, manager, architecture and governance at Mendix, a Siemens business that bills itself as a low-code alternative, to get to the bottom of the low-code phenomenon.

    Read on to discover why low-code platforms could be the next big thing. We’ll cover low-code benefits and caveats, the use of low-code in agile application delivery and how an API-first emphasis sets some low-code providers apart.

    What is Low-Code?

    Low-code platforms use drag-and-drop tools to help non-developers assemble software solutions. Instead of coding every line, integrating with databases and programming network integrations, low-code users visually construct application models with default containers that initiate the logical processes and data storage abilities they require.

    In this way, low-code is dramatically abstracted from standard software development. Examples of low-code platforms on the market include Siemen’s Mendix, Amazon’s Honeycode, Google’s AppSheet, Microsoft’s Power App and OutSystems. Among these solutions, default configurations and customization abilities vary.

    Low-Code Benefits

    With the growing need for more applications, companies turn to productivity solutions such as low-code development to quicken velocity. There are, theoretically, many other benefits to low-code or “no-code” platforms:

    • Welcomes “citizen developers” into the fold: Low-code platforms offer unprecedented usability for the less technical folks. By reducing the barrier to entry, laypeople can participate in complex application development.
    • Break silos and improve collaboration: Since non-technical roles can become more involved, low-code enables better collaboration between teams. It provides a common language for organizations.
    • Improved time to value: Some low-code platforms allow you to build, deploy and run instantly, thus dramatically reducing development time. Especially if integrated with CI/CD capabilities, using low-code platforms means a greatly decreased time-to-value.
    • Addresses the talent gap: In a world of high engineering demand but few developers, low-code development spurs continual growth in light of a limited workforce.
    • Cloud-agnostic: Low-code can grant cloud-agnostic capabilities, enabling companies to run applications on SAP cloud, Azure or “lift and shift” to other cloud vendors.
    • Platform-agnostic: Low-code platforms also offer device-agnostic capabilities, meaning the application could run native mobile code. A low-code layer could also help cater to other experiences, such as voice, chatbot or smart televisions.

    Low-code could also support digital transformation initiatives for internal, non-commercial solutions. For example, a manufacturer could leverage low-code capabilities to quickly spin up connected digital solutions to help operationalize factory production.

    Low-Code Caveats

    Though low-code suggests many positive outcomes, Scolamiero said that industrywide, there are some issues:

    • Security: Good security with low-code is possible yet complex to implement. Low-code platforms must carefully handle access management and delegate identity throughout the app ecosystem.
    • Normalizing expectations: Low-code isn’t magic. These platforms have their limits and do take time to onboard. Scolamiero encouraged having a robust training program ready and available “to teach everyone how to fish.”
    • Consulting services: Scolamiero cautioned IT leaders to beware of some solutions that taut the low-code or no-code label, yet are more akin to consulting divisions. Buying armies of service people is “not a respectful business model for a customer,” he said.
    • No universal standards: Scolamiero noted that the low-code industry has yet to unite on a data integration at scale method.

    APIs Under the Hood: The Secret Sauce

    In 2002, Amazon CEO Jeff Bezos issued a companywide mandate, which has become known informally as the “API Manifesto.” In it, he stated that “all teams will henceforth expose their data and functionality through service interfaces.”

    This API-first strategy increased internal efficiency and reusability, and eventually enabled Amazon to resell its own infrastructure, creating a whole new class of impressive revenue streams. Lyft is another excellent example of a microservices-driven product.

    Many developers now fully understand the power of wrapping everything in a web service. Yet, based on his conversations with clients, Scolamiero estimated that 1 in 6 CIOs are still unaware.

    “If they were, we would have 10 Amazons at this point, not one,” he said. “It’s really easy to wrap your head around data having value, but now it’s the infrastructure that matters.”

    An added emphasis on APIs fits into the current trend toward event-driven, message-based systems. Having the ability to expose APIs to different clouds increases API elasticity, he said.

    Keeping APIs and Low-Code Under the Hood

    Low-code and no-code solutions promise that anyone can become a developer. While the reality is a bit more complicated, with the right frameworks in place, perhaps teams can become closer to that ideal.

    Utilizing an API-first approach both for systems that comprise low-code platforms and providing the ability to expose data through APIs could give low-code platforms an edge.

    According to Scolamiero, tech leaders are still “digitalizing traditional paper processes.” They don’t often think of streamlining event-driven architecture, or how infrastructure itself could have external value.

    Regardless, if it successfully executes a business case, then it works. Perhaps business leaders don’t necessarily have to know what’s under the hood. That’s sort of the point of low-code, isn’t it?