At its core, IoT is all about data: data from devices, commands to devices, integrating IoT data with other data to gain insights. The data sources include devices, enterprise applications, vendor/partner systems, service providers and customers. The point-to-point integration between these various systems is not feasible; hence, APIs become the primary means of communication between these disparate systems. A clean architectural approach is the one suggested by the agile integration concept. APIs are central to this concept, which allow data to be shared securely between internal and external systems. The opening of APIs enables a company to provide uniform data and transaction interfaces to internal and external developers, partners, and customers, for improved data access and control of remote resources. By providing well-defined APIs, developers can use data in a programmatic manner; e.g., app developers can get access to IoT devices data without worrying about the underlying hardware interfaces. Considering the importance of APIs for IoT, it’s imperative for an organization to manage these APIs effectively. In fact, APIs have been called a fundamental enabler of IoT however, without an effective API Management solution, API sprawl can easily lead to catastrophe.
Continue reading “Taking Control of your IoT APIs”
In the mid 90s, Bill Gates famously said that “banking is necessary, banks are not.” There is certainly a lot of truth in this statement. We all need banking services in some shape or form. But who delivers these services to us is secondary. In fact, Accenture concluded in a study conducted in 2016 asking over 30,000 people in 18 countries that if the tech titans like Google, Amazon, or Facebook would offer such services, 31% of the respondents would switch to them. This clearly imposes a significant threat on traditional banking institutions.
Another challenge that banks are facing worldwide are the increasing demands for regulatory compliance with respect to openness. Such regulations include, for instance, Payment Services Directive 2 (PSD2) in Europe, the Amendment Bill to Japanese Banking Law in Japan, the National Payments Corporation of India (NPCI) with the Unified Payment Interface, UK’s Open Banking standard by the Competition and Markets Authority (CMA), or the Open Banking Regime by Australia’s Federal Government. Banks approach these regulatory challenges in many different ways. Some see it as a serious business threat and only do the bare minimum for compliance; others see it as an opportunity and with smart investment start building banking platforms for the future.
Our suggestion for building the banking platform of the future resides on the principles of agile integration, which is an architectural approach centered around application programming interfaces (APIs) and API management. At its core, agile integration resides on the three pillars: distributed integration for greater flexibility, containers for the ability to scale better, and managed APIs for re-usability and hence speed. We described the details in an earlier post.
Continue reading “The Role of Agile Integration in Open Banking”
Earlier this months at the Gartner ITxpo event, Massimo Pezzini presented the challenges that must be addressed by a pervasive enterprise integration strategy. In summary there are four types of hybrid challenges (see Massimo’s diagram below).
Continue reading “How to Address the Challenges of a Pervasive Integration Strategy”
If you Google the term “agile integration,” you’ll come up with about 30 million results, but they focus heavily on one area: continuous integration within agile development. That definition of agile integration is based on the build environment.
However, it is possible to have another definition for “agile integration,” one that looks at the platform architecture.
In this definition, “agile” doesn’t relate to the process or the infrastructure, but to the flexibility and adaptability–the agility–of the application architecture. Integration within this context has a more strategic role, as the architectural framework that defines the interoperability of services and with a focus on the application functionality.
Traditional vs. agile as an architectural approach
There are functional similarities between traditional integration and agile integration – like routing, connectivity, and orchestration capabilities. The difference between traditional enterprise application integration and agile integration is not in the tasks performed, but in the strategic perspective of those tasks. Put simply, integration can be viewed as a necessary but often limited part of the infrastructure (traditional) or it could be viewed as the core framework of the application architecture (agile).
Continue reading “What is agile integration?”
In Red Hat 3scale API Management, we can manage any HTTP(S)-based APIs – including REST and SOAP. With REST, it is particularly straightforward as individual URL paths usually map quite nicely to operations. By operations, we mean fine-grained tasks and services which providers may wish to a) get visibility into and b) apply control access to.
With SOAP, there is more of a challenge, as it is typical for multiple operations to share the same endpoint. Yet providers may still want to get the same visibility and control they get with SOAP as they get with REST.
Continue reading “Integrating SOAP based Web Services into Red Hat 3scale API Management”
In an earlier blog, we wrote about how very low latencies in Java-based microservices can be achieved through our plug-in wrapper. That solution was general in nature, applicable to any API service.
In this blog, we show that the plug-in wrapper is applicable to a specific microservices framework – the open source microservices framework Light-4-J. In particular, we took an implementation of a microservices chaining tutorial, built upon it, and applied our Java plug-in wrapper API management component to it.
As we stated in our first blog, this approach may be well used for a particular use-case, i.e. internal API traffic, typically microservice to microservice. Services exposed to external parties, outside the DMZ, can continue to use the API gateway deployment for its routing and security capabilities. And indeed this differentiates Red Hat 3scale from other vendors in that both the plug-in deployment and the gateway deployment are feasible.
Figure 1 – Plug-in approach: API Management intelligence and configuration are decoupled from traffic enforcement and reporting
Continue reading “Low Latency API Management for Microservices framework Light-4-J – with Red Hat 3scale”
Today is a special day for the 3scale team at Red Hat. It’s been just 10 short months since the company joined Red Hat in the summer of last year and there has been a buzz of activity for the entire time.
One of the biggest new goals was to add a fully on premise version of the 3scale API Management product to the line up alongside the existing Software as a Service (SaaS) version. Hence the team is very happy to announce the availability of that new version which is now generally available. Get started looking at 3scale’s customer portal page.
Launching the on-premise version is special for two reasons. First, because increasing numbers of customers are now running large numbers of public and private APIs – often deep in their internal infrastructure. Deploying API Management in their own data center or in a cloud environment they own is often a key part of succeeding. Second, it is special because of the way on-premise is being delivered. Specifically the new product is shipping entirely on Red Hat’s powerful container management platform, OpenShift.
Continue reading “Go Anywhere API Management: 3scale API Management adds a Fully Containerized On-Premises Version”
Oxford Dictionaries runs a global API competition, and Red Hat and the 3scale team are more than happy to support this initiative. Find more about the competition here.
Oxford Dictionaries powers a huge range of technologies, apps, and digital services. Their world-renowned dictionary data powers search engines, provides definitions in e-readers, and makes predictive text and language-learning software possible. On top of their rich language data, which is integrated with cutting-edge technology, they provide an outstanding API. Oxford Dictionaries uses that to work with partners across the globe to create some of the most flexible and reliable platforms and services in the world.
Here is what the folks from Oxford Dictionaries have to say about their competition:
At Oxford Dictionaries, we love language, and we want the world to communicate more easily. So, to celebrate language, communication, and the launch of our API, we’re holding the Oxford Dictionaries API competition. To enter, simply create an app that uses one or more of the languages in the Oxford Dictionaries API. It doesn’t matter if your app is an existing application that has recently integrated Oxford Dictionaries data or a brand new app; already published in an app store or never-before publicized. You can enter as an individual or as a team. We want to see what you can create!
The winner and four runners-up will be showcased on our site and receive PRO subscriptions to our API and a collector’s mug, and we will send all entrants a collector’s T-shirt. You can find out more about the competition and how to enter here.
In this article, we provide a solution that enables almost latency free API management for Java-based microservices APIs. We build on Manfred Bortenschlager’s white paper Achieving Enterprise Agility With Microservices And API Management. We provide a practical solution for adding the management layer Manfred outlines to internal microservice-to-microservice API calls.
API Management and Microservices
Figure 1 – a typical microservices architecture with depictions of externally and internally consumable microservices
In the white paper Manfred describes a typical microservices architecture consisting of:
- A perimeter service layer that is typically implemented by an API gateway which manages and secures components that follow the backend for frontend (BFF) pattern. The perimeter service exposes APIs to external consumers.
- Internal microservices that are clustered into functional elements and communicate via APIs.
The most common and most decoupled way to achieve API management is through deployment of API gateways on the API provider’s infrastructure. These gateways act as traffic controllers which authenticate, authorize, and report on API traffic to the 3scale API Management Platform. These extensive management features are achievable with very low latency overhead through our caching and asynchronous architectural features. Additionally the gateways provide excellent routing and security protections such as defense against DDoS attacks and more.
Continue reading “Ultra Low Latency API Management for Microservices with Red Hat 3scale”