APIs are the satisfaction of a long and deep need to be able to create consistent and reliable integrations between disparate systems, operating systems and datasets. As we started to use REST-based APIs, we also realized they fulfilled a previously little-addressed gap in automation. Frankly, they are a force multiplier in DevOps delivery.
Early efforts at system-independent APIs were not great, but we learned lessons and are steadily getting better. While REST is the default solution for APIs, it probably isn’t the end of the road, as we continue to learn and improve. That’s what we in tech do – get excited about an idea, drive it to broad use and then iteratively improve it.
And that’s the root of the problem. We have been, and are, saturating our applications with APIs. Internal, external, external-that-rely-on-another-external. The thing that comes to mind every single time I look at an API dependency map for even a medium-sized application is “spaghetti code.” Those lines are going all over, quite frequently returning to themselves.
And we’re going to have to maintain this creation. Maybe not us, individually, but us as in IT and DevOps teams. The only constant is change, and far too many of us are not only failing to plan for API changes, but failing to even think about them. Because things are generally going swimmingly and most IT managers and DevOps teams have more urgent things to think about.
But risk management – particularly broad risk – is an essential part of future planning. If you lose access to external API X, what will you do to keep your application running? If you lose an entire internal system that hosts API Y, how can you recover in a timely manner? While most organizations will identify and repair single points of failure, the solution is a pool, and the impact of losing Z servers in the pool needs to be understood, if nothing else – questions like, “At what point would user experience be impacted?” need to be asked, and a plan formulated to keep that from happening.
We are already seeing issues created by using external APIs. All of them are predictable – an API going offline, or even disappearing completely; an API interface or attendant data format change; a change to the algorithms underlying the API, causing a change in data results, etc.
API usage is far easier than it has historically been – and companies are working hard to make it easier to access APIs, both yours and others’. This is a good thing, as it means less time spent figuring out and tweaking API calls and request data. But it means our API dependence will only grow, and the number of lines in our dependency graphs – each representing some amount of risk – will only grow.
“But we’re doing things in the cloud, so we can auto-scale, and failures are no longer and issue for us!” some shout. While that can help some scenarios, it doesn’t help others – if a vendor goes under and takes an API you use with it, or a preferred vendor (or inside component) becomes a security risk, you’ll still need to take steps. Knowing what and where your weaknesses are before they become issues is important, and worth your time.
Most of you are killing it, cranking out solutions faster, iterating to make them better, using APIs to extend functionality and reduce delivery times. I’m just saying, stay aware of the technical debt you’re creating, because debts always come due, and risks eventually become issues. So know what’s a risk in your infrastructure, and have a plan to react when it does cause problems.
Digital transformation is increasingly propelled by rapidly changing user expectations. Release frequency is increasing, as is the need to connect a growing number of applications and digital experiences. As a result, 83% of IT specialists consider API integration critical to their business, found the State of API Integration Report.
Application programming interfaces (APIs) hold powerful sway in tech discussions of late. Building API-first could increase internal reusability. APIs have become a standardized machine-readable mechanism for connecting partners. There is also a hot market for API startups, meaning APIs are becoming products in their own right.
APIs are also enabling change for large enterprises. I recently connected with Bernd Gross, CTO at Software AG, to get his perspective on the role APIs and integrations are playing within the new wave of enterprise digital transformation. Below, we’ll see how connected customer experiences, digital business excellence and a new ecosystem-driven economy are driving the emergence of more API-based strategies.
Three Drivers of the Connected Enterprise
Businesses continue to transform into more connected enterprises. Once relegated solely to improving back-office efficiency, digitalization efforts are being applied across the board — to employee management, assets, machines, partners and the supply chain at large, said Gross.
Amid rising digitalization, connectivity is the glue that unites disparate elements and tools. A fully connected world is “the new flavor of digitalization,” said Gross. To his point, ‘connected experiences’ is a crucial driver for 68% of platform providers, The State of API Integration Report found.
So, how are APIs fueling the new connected enterprise? Gross identified three key reasons why integration is now fundamental to enterprise digitalization initiatives.
Software AG Marketecture, used with permission.
1. Connected Customer Experience
Many organizations “want to transform into a technology and software company,” said Gross. To participate in the connected digital economy, organizations are striving to create advanced 360-degree customer experiences. Today’s technology needs to “look beyond a PC application,” Gross said. These experiences must cater not only to desktops and smartphones but also to IoT devices and physical assets.
For example, he explains how one large elevator company architected an embedded connected experience, incorporating digital touchpoints within elevators to showcase signage, entertainment and ads, opening new monetization possibilities. This change was so radical that the mechanical engineering company pivoted its mission statement, reimagining itself as a “vertical transportation company.” Soon, their AI-enabled elevators will predict behaviors and optimize travel times, so they are always on the right floor, waiting for human riders.
Intelligent building technology is similarly being applied by digital-savvy hotels, Gross explained, which is especially important for contactless visits during the pandemic. A fully digitalized customer experience could involve automated check-in, a room access code sent to a smartphone, an online billing system, physical sensors and more. Enabling a seamless digital hotel experience sounds easy, but it’s technically quite challenging — there are endless integration requirements to connect. In some cases, it would take 24 integration points, noted Gross.
2. Digital Business Excellence
Gross recognized the high expectations for modern digital experiences. He described a “new trend of business excellence in delivering more of an end-to-end digital experience.” This means data can no longer be locked up; even traditional companies must transition to platforms to offer software and data to their end users. In the process, interesting things may occur — your customers could become partners, Gross adds.
He described how one medical company, a leading centrifuge producer, sought to build more digital experiences to complement their hardware. Though the machine functioned seamlessly, there was no easy way to port data results to other applications. This inhibited initiating the fully digitalized workflow required for a smart lab experience.
In this case, APIs were imperative to opening up back end cloud services to enable smooth user interfaces and end-to-end workflow automation. “Intuitive user interfaces must integrate all services, including cloud and on-premises services, to create and automate workflows,” Gross explained. “To do this, you need integration.”
3. Ecosystem-Driven Economy
The network effect of platforms is that they enable an ecosystem to form. And, according to Gross, involving partners in this new digital experience matrix is imperative for success. For example, the API gateway is one area where partnerships help an integration strategy; “You need an API gateway for security and governance reasons,” he stated.
Throughout his experience overseeing APIs on many projects, Gross often noticed a naïveté associated with defining the ecosystem. “When [clients] engage in the first phase of these projects, they think they know how to do it, but they typically don’t,” he said. Potential API providers often don’t fully realize their monetization strategy, the security implications or the complementary software providers necessary to support a working model. “Partnerships often facilitate a value-add to customers — they enrich the total offering through APIs and ecosystems,” said Gross.
Similar to how a machinery company may embed a bill of materials into the product they sell, digital partnership ecosystems can open up data so partners can access and innovate with it, Gross said. Frequently, ecosystem partnerships make a lot of sense, as they can better meet consumer expectations. For example, Gross suggested that integrating a ticketing system into a conditional monitoring system would bring compelling value.
The Next Stage: Self-Service Integration With APIs
According to the report, 40% of companies said that digital transformation is driving their need for app integration. Truly connected enterprises must embrace digitalization and integration across all aspects of the business. As a result, this is forcing a business shift toward more open ecosystems.
But building these systems will require newfound knowledge dissemination around developer experience and self-service capabilities. “Self-service has become fundamentally important,” said Gross. It’s not enough to simply open interfaces — you have to also add self-service capabilities to integration tools, he added. This could mean offering low-code options alongside APIs — such drag-and-drop UIs would help facilitate integrations for more citizen developers. A self-service approach to digital platformification is an emerging trend, yet one that’s “not fully at mass market,” described Gross; it’s still in its early stages.
Open ecosystems are guided by consumers, who often desire connections between your tool and external partners. But, opening up data isn’t just helpful for partner integration; it could also benefit internal use. As Gross described, time-series industrial analytics could empower operators on the shop floor or production facility to make sense of local data. “You need self-service analytics tools to give them that ability,” Gross said.
Building new customer experiences to cater to various devices and platforms is a big driver for API adoption. As a result, headless styles are emerging to address multi-platform requirements. For these reasons and many more, APIs are fueling new digital transformations across enterprises, powering innovative customer experiences and hiding complexity in the back end. With APIs, smart processes, smart machines and smart partners can all come together.
If you’ve spent any length of time in application development, you’re familiar with change. It’s the only constant.
And along with how we build applications come changes in the techniques used to keep them secure.
Securing modern applications requires more diligence than ever before. A review of how application development has changed over the past decade will explain why more diligence is necessary.
Traditional Web Applications: Placing an Order From a Menu
The traditional web application operates like ordering food from a menu at a restaurant. You have a list of dishes available, and you ask for one. The chef decides which ingredients are necessary and how the plate looks when it arrives.
In a traditional web app, the client fetches a URL. Let’s say you want to see a dashboard of marketing metrics, and thus your browser retrieves example.com/dashboard.jsp. The client doesn’t control what’s on the dashboard; it just knows to ask for it.
The web server processes the request in three steps:
The web server pulls data from the database.
The server builds an HTML page with the data placed inside.
The server returns the rendered HTML page to the client.
The web server decides what data goes into the dashboard and where the data goes. The client simply asks for a resource and displays what the server returns.
In this model, the client typically has very little code. It requests a URL from the server and displays what comes back. All rendering and data processing happens on the server.
Modern Web Applications: Buffet Style
Modern web applications put the client in control. It’s more like a buffet than a sit-down restaurant.
The client is often a Single-Page Application (SPA), or an application that dynamically updates the same page instead of always requesting a new one from the server.
In a buffet, you take your plate and pick and choose the foods you want. Each dish can have multiple configurations based on your needs at the time.
SPAs work like those plates. Instead of a single server creating an entire page and returning it to the client, the client knows how to make the page and asks only for the data required to do it.
Typically, Application Programming Interfaces or APIs provide this data to the client. Business logic is exposed to clients using APIs that return only what the client needs. Maybe the client only wants the last 20 notifications for an account or the ten most recent emails.
The use of APIs for business logic and data retrieval opens up the world of application development. You no longer need to build a web application. You can use a mobile application instead. You can use any technology or form factor to access the data, from mobile to Internet of Things (IoT) or other developers building applications of their own.
JSON, a lightweight data format, is one of the most useful enabling technologies for modern applications. It allows all of the APIs, the client, and the database to store and transmit data using the same format. There are no data transformations necessary, which helps keep the application responsive.
Going back to the above dashboard example, an SPA wouldn’t ask the server for the entire dashboard at once. Instead, it would ask the appropriate APIs for the specific data it needs to build the dashboard itself.
The desire for APIs and ultimate flexibility and speed of development gave way to the development of microservices. These services are kept small on purpose to be updated independently of each other and more frequently.
SPAs emphasize the client, leading to more complex code in the clients and the risk of security vulnerabilities in the clients (more on that later). But this change has opened up transformational technologies like IoT devices.
From Monoliths to Microservices
A common theme in the evolution of application development has been toward breaking functionality and features into smaller and more granular components. Just as with the SPA example above, the functionality of the web page is in isolated components, the same trend is true when you look at overall application architecture in general.
Where a legacy application might have been designed with separate modules and functions, each internally making calls to each other, modern design now breaks out separate functions into discrete services. Now rather than each development team maintaining similar code/functionality inside their application, many business functions are separated into clearly defined services. Consider an ‘address verification’ service which can be used by many other applications. The functionality of validating an address is decoupled from the ‘customers’ that use the service, which introduces value into the delivery lifecycle. This approach enables development teams to focus on smaller, more granular changes and therefore shorten their cycle time and accelerate delivery.
Microservices – a Response to the Accelerating Pace of Change
Digital transformation and the rapid acceleration of the pace of change within the industry dictates a new way of thinking. This thinking is encapsulated in the following quote by Bronwyn Clere, Executive Director for Capital Planning & Delivery, at Telstra Corporation in PMI’s Pulse of the Profession 2017 report:
We are implementing features and products and using technology that were not invented 18 months ago. No longer can we afford these large monolithic programs that go on for two to three years. We know that what we set out to do at the beginning of that time is not what we will finish out doing. So, we are focusing on very rapid delivery cycles, asking ourselves: How do we mobilize a project very quickly? How do we use the right delivery techniques to work through it quickly? How do we get product into market or to customers or into the business?”
Business leaders everywhere are demanding technology teams deliver faster. As a result, teams have adopted new ways of working and new ways of architecting their solutions. We’ve seen widespread adoption of Agile, CI/CD, and DevOps tools. Similarly, application development and architectures have evolved to further enable velocity.
A Tour of Cloud-native Architecture
The increasing pace of change would put significant stress on any IT infrastructure. But cloud-native architecture has fundamentally changed how applications can be built and scaled.
Cloud-native technologies, such as containers, service meshes, microservices, immutable infrastructure, and declarative APIs, empower developers to build and run scalable applications on public, private, and hybrid clouds.
Cloud-native architecture focuses on creating loosely coupled services with high resiliency. Developers can make changes frequently without negatively impacting the entire system.
Let’s take a quick tour of cloud-native applications so you can see how they differ from traditional web applications.
The bulk of cloud-native applications include many microservices deployed in containers. Each service is isolated from the others and can be destroyed and recreated easily without affecting other services.
Often an orchestration tool like Kubernetes is used to monitor all of the microservices used in an application. Orchestration is necessary when hundreds of services serve a single application. Kubernetes can detect malfunctioning containers or services, destroy them, and recreate new ones to keep the application running smoothly.
Each service can be created and updated independently from all the others. Each service can use a different programming language altogether. As long as each service exposes a documented API, the language used behind the scenes doesn’t matter.
Below is a diagram of Microsoft’s eShop on Containers open source application. It demonstrates what a real-world application looks like using cloud-native technologies.
In this example, the development team building the Marketing microservice can make changes as often as they want without affecting the ordering or cart functionality. Different technologies can be used within each service and each service has a separate datastore. Flexibility and speed are the hallmarks of modern development.
In the next post, we’ll dive deeper into specific challenges and considerations you need to take when adopting cloud-native applications.
4 Necessary Mindset Shifts For Cloud-native Success
The pace of change affects more than technology. Processes, management styles, and even ways of thinking have to adjust to make modern application development successful within your company.
Delivery: Think Agile and Devops
Because of the intensive need to shorten delivery cycles and to automate delivery, cloud-native architectures embrace delivery practices that support short and responsive turn around. Developers can deploy new code in seconds, with some companies pushing new code to production hundreds of times a day.
As a result, your project management processes have to change. Agile practices (Scrum, Sprint, Lean, etc.) along with strong DevOps capabilities (i.e. trunk based development, CI,CD,etc) best support wide scale microservice development. It’s critical to get delivery, cultural, and organizational changes completed before trying to do cloud-native development at scale. The DevOps Handbook is an excellent resource for those new to DevOps development.
Production: Think Products, not Projects
The days of ‘throw it over the wall’ and let Operations manage the application are over. Given the complexity of modern applications with multiple microservices and associated APIs, development/product teams need to ‘own’ the application in production as much as they do in development. In order to successfully scale your adoption of cloud-native applications, you need to explore and embrace “Product Management” over “Project Management” as a practice to manage the full lifecycle of your application.
Think of your application as a long-term product that will change over time. Market insights and customer feedback will continue to improve it. It’s not a one-and-done exercise.
Security: Think Security Everywhere
Security is a major concern in this new environment. The traditional approach of building a fortress of defensive walls and moats around the application and then you ‘trust’ the activity inside the fortress is insufficient in a world where the individual elements of the application are expected to communicate with other components. On many levels, the new paradigm for security is one where each microservice, each component must have security built in, they need to embrace “zero trust” as a policy for how they operate.
Trust No One – Zero Trust in Microservices
Zero trust is a security architecture that lives by the motto: “Never trust, always verify.” It means verifying every request before returning data or performing an action.
In a traditional network architecture, we protect the perimeters. Firewalls and DMZs only allow certain types of traffic into the network. We use VPNs to enable secure communication between company servers and remote workers.
However, the biggest flaw with this security method is that traffic within the network is implicitly trusted. It’s similar to a bouncer protecting a nightclub from a long line of wannabe party-goers. It’s tough to get into the club, but once the bouncer lets you in, you can pretty much do whatever you want.
In a zero-trust network, all traffic is considered suspect. Just because a request comes from within your environment doesn’t mean you can trust it. Check every request first before the service returns data.
Microservice architecture requires a zero-trust architecture to be secure. It’ll ensure no requests fall through the cracks.
Diligence, Compliance and Oversight of Cloud-native Applications
In addition to zero trust as an approach to enabling microservices to operate securely, organizations must rethink how they monitor and manage their security posture. We’ve covered several significant changes in web applications, especially in the last ten years.
Faster change than ever before
Small, independent services on different platforms
Autonomous teams
Cloud-native
More moving parts
More can fall through the cracks.
New levels of diligence are required to secure this new breed of application. Cloud-native applications and microservices create new security vulnerabilities companies must account for to keep up with attacks.
In the next post, we’ll cover what security measures need to be in place to protect cloud-native applications.
The Linux Foundation announced today that an open source application programming interface (API) gateway known as KrakenD has become the latest project it will oversee.
Rechristened the Lura Project, the lightweight stateless API gateway was originally developed by KrakenD, which plans to continue to offer an enterprise edition of the platform.
KrakenD CEO Albert Lombarte said the API gateway it developed provides a more streamlined approach to managing APIs that doesn’t require an organization to install a separate proxy or database. All the reverse proxy capabilities most organizations require is already embedded within the API gateway. That approach also makes it easier for IT teams to decouple back-end server applications from client applications because now an API can be more easily updated without impacting client applications, Lombarte added.
Organizations that already contribute to the ongoing development of the API gateway include 99P, Hepsiburada, Openroom, Postman and Stayforlong. The API gateway also is embedded in a variety of other platforms, said Lombarte; he noted that the number of servers running the gateway now exceeds more than one million per month.
API gateways have been available in various forms for years, but with the rise of microservices the number of APIs organizations need to deploy and manage continues to rise steadily. Each microservice added to an environment adds yet another API. At a time when microservices-based applications are at the core of many digital business transformation initiatives, IT teams must employ a more flexible approach to managing the interactions between APIs.
Thanks in part to the role they play in enabling digital business transformations, APIs are also being targeted more frequently by cybercriminals that have come to view them as an efficient way to exfiltrate data or inject malware into an application environment.
It’s not clear what impact the Linux Foundation’s support might have on organizations’ selection of one API gateway versus another. In fact, many organizations are still trying to navigate when to employ an API gateway versus relying on proxy software to manage a handful of APIs versus a service mesh to manage thousands. The issue comes down to not just how many APIs there are, but also the overall weight of the platform being employed, said Lombarte. A service mesh typically requires more time and effort to deploy and manage, he noted.
As the number of APIs in an IT environment continues to increase, there may come a day when organizations will have to revisit how APIs are created and maintained. All too often, APIs are still created as an afterthought once an application is created. They tend to be brittle and, as a consequence, still break often. A more holistic approach to managing APIs based on a set of DevOps best practices is required. The challenge is getting DevOps teams to prioritize APIs when there are so many other issues that require their attention. Nevertheless, it’s become apparent APIs are, in many cases, becoming too strategic to the business for their management to be left in the hands of a single development team.
For developers working with cloud-native technologies, software testing and quality assurance is a key part of product development. For most teams, testing has “shifted left,” so the quality of the code can be assessed as it moves through the CI/CD pipeline. This approach to quality assurance reflects the rise of DevOps and other modern development practices – developers today own their applications from end-to-end, and conducting testing early in the product life cycle is how they find potential bugs, save their organizations time and money and build products that delight their customers.
More recently, developers have added end-to-end API and browser tests into their CI/CD practices, extending the scope of their testing and quality assurance practices. By testing how code performs on different browsers and how it interacts with important data sources, developers have added another layer of quality testing to the early stages of their development processes. This has brought added benefits to other “shift left” practices, such as unit testing and security testing, and has led to a new understanding of quality assurance.
Traditional Approaches to QA Can’t Support the Pace of the Cloud
As companies have migrated to the cloud and adopted agile development methodologies that align with DevOps practices, they’ve encountered conflicting priorities between releasing code quickly and maintaining the highest level of quality on each release. Traditional manual testing techniques were not built for agile workflows, but instead supported older waterfall methodologies, in which testing could be conducted as a discreet instance before code went to production. With agile development, having a specific team in charge of all testing right before production is not the most sustainable approach, as it hinders the rapid pace of development that the cloud enables. This is why testing is “shifting left” to earlier stages of the development process, and why manual testing is being done by people embedded within each engineering team.
Cloud-Native Teams Have Shifted Left Into CI/CD Pipelines
As part of these agile methodologies, companies have moved toward leveraging CI/CD practices to ensure code is always in a state where it’s ready to be deployed. As code moves through these pipelines, developers want to ensure they are able to catch bugs earlier in the development cycle. To do this, they’ve taken to testing earlier and more often.
In particular, developers have increasingly recognized the value of end-to-end testing throughout their CI builds. API tests allow teams to verify end-to-end workflows by chaining HTTP requests and API calls, so they can validate all the layers of their systems from worldwide locations. Browser tests capture the user’s view during critical transactions, so teams can understand how UI changes are impacting web applications. Shifting both left into CI/CD pipelines saves time and money, as fixing a bug earlier in the development lifecycle is much less expensive than trying to fix it at the last minute, when it has grown in complexity and scope.
It also means many issues are caught by the developers, without the intervention of another engineer manually validating their work. This reduces the number of cycles required to find a bug, allowing the code to be circled back to developers, fixed and re-deployed to a testing environment. When regressions are caught early, developers can focus on the details that will make the product great.
Visibility of Metrics, Traces and Logs Drives Value
Running browser and API tests in your CI pipelines is beneficial, especially when teams can correlate these tests with data from across their stack – front end and back end, application and infrastructure. With correlated metrics, traces and logs that can be accessed easily without toggling between different products, teams will have the full context necessary for both detecting and troubleshooting failed tests. Detecting the failed tests allows for the rollback of bad code before it goes to production, and the correlated full stack data can be used to troubleshoot and fix any issues not caught during the development stage. This creates a new culture of quality assurance, in which maintaining quality is a holistic process that involves every part of the development cycle, and draws on data from every part of the stack.
Consistent Quality Requires Collaboration
This change in quality assurance goes beyond the practice of shifting browser and API testing left, and represents a fundamental change in how engineering teams collaborate within an organization. Testing happens before code goes to production, continues with robust monitoring once code is live, involves data from across the stack and is the responsibility of teams from various parts of the business. With this collaborative approach, for example, a front end engineer can easily identify an issue in the integration of their latest changes with the way the back end APIs are structured. They can then engage with the back end team owning this service to collaboratively iterate and find the best solution to resolve the issue. It may start with a shift left, but, ideally, it ends with the removal of silos and the opening of communication channels among teams.
Automated QA Delivers Customer Value Faster
A fully operational approach to quality assurance means that issues are resolved faster, or even resolved while code is still in development, so they never become issues at all. This creates a virtuous cycle – fewer regressions means less downtime, which makes customers happy, and frees up engineers to build new products, which makes customers happier still. That baseline of reliability and customer experience enabled by effective quality assurance is what allows for new innovation that delivers value to customers.
In recent years, implementing AI and IoT technologies has been top priority for many organizations as their leading-edge capabilities have become a requisite for digital transformation – but the speed of their adoption is greatly influenced by the flexibility of supporting software. Enter low-code, no-code programming and truly open APIs.
Low-code/no-code platforms are a promising alternative to traditional software platforms for non-technical business users; a more democratic approach to software development, built on either no or minimal code. The approach begins by minimizing external expenses and time required by outside developers or programmers as business analysts and line managers can now structure new process flows and functionalities.
This is coming into sharp focus, as the increasing need to get new applications to market quickly is coupled with a growing demand for digital transformation from the C-suite. But to access the benefits, organizations must ensure that their underlying software can integrate well with external systems—introducing application programming interfaces (APIs).
Low-Code/No-Code – The New Focus
Analyst predictions have revealed an industrywide trend geared towards these platforms, as 60% of CIOs are set to employ low-code/no-code tools by 2025, with plans to bolster their output capacity. Other analysts expect to see 65% of all application development taking place in low-code/no-code environments by 2024. But, it is the openness of APIs that will determine the success of this software.
APIs have reached new heights since the early days of component-based architecture, but today’s APIs are still inspired by Roy Fielding’s Representational State Transfer (RESTful) API.
APIs – Providing Essential Internal and External Openness
Some vendors will talk about how they have open APIs, but these are often limited and designed for specific, pre-determined integration scenarios. The application, in the meantime, internally communicates in a proprietary fashion that cannot be leveraged by external systems. To maximize the agility delivered by low-code/no-code tools, the entire application should be built on open APIs.
Enterprise applications can go a step further by relying on the ISO/ICE–approved OASIS Open Data Protocol (OData), making things even more interoperable with more choice, flexibility and capabilities for customers. When the application is built on the same set of RESTful APIs it exposes to other systems, it is even easier to access the precise spot in a value flow with which organizations need to integrate.
With the support of open APIs, there is an opportunity for companies to leverage low-code/ no-code tools and achieve crucial business returns in three ways:
1. Undisrupted Connectivity
A robust architecture built on RESTful Data APIs, documented according to the Open API Initiative specifications, gives organizations the ability to extend enterprise software on the outside to create task specific apps or connect to other systems.
This may simply be used for automating steps around onboarding a new employee; for instance, filling in a desk number in an office floor plan, initiating payroll activities and creating an Outlook account. It could also populate a serialized part structure from a machinery manufacturing process into the software that will be used to annually service that piece of equipment. Any data, action or event should be accessible in a clear and thorough API library.
With enough of these RESTful APIs, any number of low-code/no-code tools can be used to create targeted apps that interact with enterprise software and other systems running in a business. Commercial software offerings can be used to build an experience and drive processes in enterprise software.
2. Digital Transformation Accelerated and Uninterrupted
The main benefit of using RESTful APIs is that an organization’s external and internal systems can automate processes, expand access to data, and create extensions to their enterprise software on the outside. Regardless of whether an internal process automation (IPA) tool or external low-code/no-code process orchestration software is used, their ERP system should offer transparent access to the part of the system supporting any given integration or process automation.
Here’s where a low-code/no-code approach helps to develop new solutions and industry specific functionalities that can be built faster, cheaper and with higher quality. Integrating a low-code domain-specific language (DSL) into solutions not only helps create value faster, but also insulates organizations from future technology changes. The DSL describes the intent of what a component in the application (for example, an API) should do, rather than how it is technically done.
3. Increased Software Governance
Low-code/no-code tools are also more commonly used to tailor how enterprise software works internally, giving organizations more control over their software. Software providers might currently offer the ability to extend the data model or to tailor the user interface and user navigation flow through a process to an organization’s specific needs, using no-code tooling. But this is not enough.
Low-Code/No-Code: Go the Extra Mile
Enterprise software platforms should offer intuitive low-code/no-code tools that will not only automate process steps or actions, but add machine learning capabilities for intelligent process automation. This democratizes the creation of intelligent systems by putting it within reach of business analysts and line managers—a simple what-you-see-is-what-you-get.
Logical, Automated Processes
With the IPA capability embedded into software, any additional input needed from users can be captured automatically. These capabilities can then be further enhanced with intelligent parts, such as AI and machine learning models, to make choices inside the automation about what to do next (branching decisions), or predicting values to be filled in.
As the need to digitally transform continues to surge, enterprise solutions based on open APIs, strengthened by low-code/no-code programming, will become fundamental business tools—speeding up deployment times and delivering business value when it matters most.
An open source library provided by RapidAPI, available in beta, makes it possible to discover Kafka clusters and topics, view schemas and test and consume records from a browser via either the RapidAPI Marketplace or the RapidAPI Enterprise Hub. The library is based on Apache Avro and Confluent wire formats found in the open source confluent-schema-registry library. RapidAPI extended that library to add support for JSON and a protocol buffer, which is now being shared with the open source Kafka community.
RapidAPI CEO Iddo Gino said DevOps teams can now discover all available Kafka clusters and instances in the same location where they find, test and connect to microservices based on REST, SOAP and GraphQL APIs. That effort is designed to complement initiatives, such as the AsyncAPI specification, that is now being advanced under the auspices of the Linux Foundation, Gino noted.
RapidAPI is adding this capability because usage of Kafka to enable asynchronous communication across event-driven applications has significantly increased, Gino said. As the number of digital business transformation initiatives increased in the wake of the COVID-19 pandemic, Gino said reliance on asynchronous messaging platforms such as Kafka became a requirement. In many cases, synchronous communications across highly distributed applications simply isn’t feasible, Gino added.
That doesn’t mean asynchronous requirements will replace the need for traditional synchronous APIs. Rather, developers will find themselves incorporating a greater mix of both as enterprise IT environments become more distributed, noted Gino. Applications are increasingly become one large puzzle that developers need to construct using various classes of APIs, added Gino.
The library created by RapidAPI is expected to be generally available in the third quarter. In the meantime, adoption of Kafka continues to accelerate. The open source community that oversees development of Kafka, under the auspices of the Apache Software Foundation, claims more than 80% of all Fortune 100 companies are using the platform for everything from constructing data pipelines to running streaming analytics applications. In some cases, data is being queried directly while in transit versus waiting for it to be stored on-premises or in the cloud.
Regardless of how Kafka is employed, developers are rediscovering event-driven architectures, that can trace their lineage to the 1980s, for building applications. The difference now is there an open source framework for handling the asynchronous communications required to build and deploy those applications at scale.
It’s not quite clear how the rise of event-driven applications will impact DevOps workflows, as event-driven applications become more commonly built and deployed. However, as the APIs become more widely employed within the context of these applications, it should become simpler to incorporate them.
The challenge is event-driven architectures typically requires developers to think differently about how their applications are structured, so it might be a while before Kafka – and other similar platforms – are pervasively employed across the enterprise.
Okta this week lowered the barrier to adoption of DevSecOps best practices by making available an Okta Starter Developer Edition to enable developers to embed Okta authentication, authorization and user management capabilities into applications at no cost for up to 15,000 monthly active users.
Randall Degges, head of developer advocacy for Okta, said interest in identity management among developers is rising as a method for implementing zero-trust initiatives that better secure application environments. Rather than having to embed and maintain authentication and authorization themselves Okta is making a case for developers to invoke an application programming interface (API) to access a service that provides those capabilities on demand, noted Degges.
The Okta Starter Developer Edition, announced at an online Oktane21 event, reduces the friction developers encounter as they look to embed identity management capabilities, such as multifactor authentication, into their applications, Degges said. Developers can, for example, access enhanced documentation and sample applications as well as new integrations with Kong, Heroku and Terraform platforms and tools, alongside integrations with multiple continuous integration and continuous delivery (CI/CD) platforms.
In general, Degges said, the shifting of responsibility left toward developers is happening at a much faster rate because the level of appreciation for security among developers is now a lot higher. Identity management capabilities are simply another API that developers can now invoke as part of a DevOps workflow, noted Degges.
The Okta Starter Developer Edition comes on the heels of the announcement of the acquisition of Auth0, a provider of authentication and authorization services that can be easily embedded within an application. That $6.5 billion deal, however, is not expected to close until summer.
In the meantime, Okta is moving forward with the Okta Starter Developer Edition that could eventually create a large pool of applications that will one day consume Okta services for a fee as they scale. The more applications an organization deploys, the more likely it becomes that they will have more than 15,000 active users per month.
In the meantime, the level of experimentation involving digital business transformation initiatives is likely to increase. Developers will be able to demonstrate to their often skeptical cybersecurity counterparts that their concerns have been addressed before an application is deployed in a production environment.
It’s not clear what impact access to initially free identity management services might have on the adoption of DevSecOps best practices. In many cases, developers will take advantage of a service like Okta simply to address a requirement. Their appreciation for how that service fits within the context of a larger DevSecOps workflow might not be all that high.
Nevertheless, the state of application security should improve in the months and years ahead. In fact, some developers may opt to update existing applications that, at present, do not meet zero-trust requirements to take advantage of identity management services that can be invoked via an API. Alternatively, the may also decide to replace authentication capabilities that are challenging for them to maintain and update with an API that calls a service. Regardless of the path forward, the historic divide between developers and cybersecurity teams appears to be finally narrowing.
A survey of 521 attendees at a recent online Future of Salesforce DevOps Summit event hosted by Gearset, a provider of a continuous integration/continuous delivery (CI/CD) platform for Salesforce developers, found just under half (47%) of respondents now release software at least multiple times a week, with another 29% releasing software weekly or biweekly.
More than half of respondents (52%) also noted they now can deploy software in less than an hour.
Gearset CEO Kevin Boyle said the survey suggested the level of DevOps maturity among developers building applications on top of the Salesforce software-as-a-service (SaaS) platform is increasing rapidly. In the wake of the COVID-19 pandemic, many organizations embraced SaaS platforms to accelerate their digital business transformation initiatives rather than building entire applications from scratch.
However, the biggest benefit cited by survey respondents was not the ability to release applications faster, but rather the improvements to application quality (77%), followed by increased productivity (69%) and enhanced collaboration (46%). Other benefits cited included reduced complexity thanks to automation; increased agility; more reliable releases and time and cost savings.
Overall, the survey identifies source code control, CI/CD, unit testing, change monitoring and backups of metadata and data as being the most widely implemented DevOps capabilities that have been adopted. Over the next 12 months, capabilities that will see the most increased adoption among survey respondents include CI/CD, static code analysis and sandbox seeding with data.
Survey respondents said their top obstacles to adoption of DevOps are ramp-up time, followed by difficulties adopting source control and a perceived steep learning curve. For many organizations that have adopted Salesforce, the intimidation factor when it comes to adopting DevOps best practices is still fairly high, Boyle noted.
Most recently, Gearset added a free training platform, dubbed DevOps Launchpad, that employs gamification techniques to make DevOps more accessible to developers. Topics covered include version control fundamentals, Git branching strategies and Salesforce backups.
Gearset counts McKesson, Zillow, Traction on Demand, Intercom, Accenture, IBM and Johnson & Johnson among its customers. It’s not clear to what degree appreciation for DevOps has risen among smaller companies. However, as the number of custom applications deployed as extensions to the Salesforce platform increases, it is apparent that manual processes for building and deploying applications will not scale. The Salesforce platform itself is uniquely constructed using a set of objects and tables that generally lead organizations to adopt a DevOps platform built for that environment. However, it is possible to build and deploy applications using a DevOps platform designed for building and deploying applications that might need to span multiple platforms. Those applications would be integrated with the Salesforce platform at an application programming interface (API) level.
Regardless of how custom applications are built and deployed, it’s clear Salesforce platforms are becoming more widely used in enterprise IT environments. Each DevOps team will need to determine how best to integrate those platforms within the context of their overall DevOps strategy.
In advance of its online GraphQL Summit this week, Apollo GraphQL announced today it has updated its Apollo Federation offering that enables a GraphQL Server to span multiple platforms, making it more accessible to a wider range of developers using different tools.
Apollo Federation is now integrated with both Apollo Studio, a web-based tool for navigating GraphQL application programming interfaces (APIs), and Apollo Workbench, a plugin for Microsoft Visual Studio.
At the same time, Apollo GraphQL is making available a command line interface (CLI), dubbed Rover, that makes it simpler to integrate Apollo Federation within a DevOps workflow.
Matt DeBergalis, CTO, Apollo GraphQL, said GraphQL is continuing to gain traction as an alternative to more rigid REST APIs as more organizations begin to appreciate how dependent they have become on software. REST APIs may be simpler for developers to create, but APIs based on GraphQL are easier to update and manage, DeBergalis noted.
The challenge organizations encounter is that a GraphQL Server can become too large to easily navigate. Apollo Federation provides a mechanism that enables of subset of those APIs to be managed on multiple platforms that make up a federated instance of a GraphQL server, DeBergalis explained.
DeBergalis also noted that IT vendors that have embraced GraphQL are also starting to add support for Apollo Federation. DataStax, a provider of a curated instance of the open source Cassandra database, has added Apollo Federation to the open source data gateway Stargate it provides to access data stored in a Cassandra database.
At its core, QraphQL provides an open source data query and manipulation language for APIs along with a runtime for fulfilling queries. Originally developed by Facebook, the GraphQL Foundation is now an arm of the Linux Foundation. As more organizations embrace APIs to construct applications based on microservices, GraphQL adoption has steadily increased. It’s not likely GraphQL will completely replace REST APIs any time soon, however, given how pervasively deployed REST APIs already are.
However, DeBergalis said that organizations that require a more agile approach to building and deploying software are voting with their feet for GraphQL APIs that are easier to update. As the rate of change in software environments continues to increase, the need for a more flexible approach to deploying and updating APIs becomes that much more apparent, added DeBergalis.
GraphQL is also more efficient than REST APIs in terms how much data is shipped back and forth between a client and a server. At a time when the amount of data that is being consumed is steadily increasing, the need to give clients more control over how data is returned from a server has become more pressing. Apollo GraphQL claims more than two billion queries per day are now being launched against instances of its GraphQL Server.
Regardless of what types of APIs are employed there are more of them with each passing day. As the number of digital business transformation initiatives increased in the wake of the COVID-19 pandemic, so too did the number of internal and external facing APIs. Developers may have their own individual preference for the type of API they want to use, but as developers are increasingly being tasked with both building and managing APIs after they are deployed, the appeal of GraphQL becomes harder to ignore.
