Red Hat conceived the agile integration concept to help our customers tackle integration challenges more effectively. As we described in an earlier post in detail, agile integration is an architectural approach centered around application programming interfaces (APIs) and API management. At its core, this concept resides on the following three pillars: distributed integration for greater flexibility, containers for the ability to scale better, and managed APIs for re-usability and hence speed.
When we started designing this concept we actually started from two premises:
- Agility today is the most important business capability — especially for incumbents in traditional markets.
- Every organisation has integration problems.
Typically in most companies nowadays the integration function is centralized and hence technically as well as organizationally a bottleneck. Our two premises contradict each other and we set out to design an integration concept that can solve this contradiction.
In order to come up with a solution that really helps our customers solve their integration problems in the best possible way, we first analysed the market to understand what actually are the problems that users are trying to solve. Although there are of course a very wide variety of often very fine-nuanced problems, it turned out that we could classify all the problems into six typical integration challenges. The following diagram summarizes these challenges and we then discuss each of them in more detail.
Continue reading “Six typical integration challenges that agile integration can solve”
In today’s digital world, software strategy is central to business strategy. To stay competitive, organizations need customized software applications to meet their unique needs — from customer engagements to new product and services development. Drawn-out development projects are no longer acceptable, given business demands. Therefore, the need to speed up application development, testing, delivery, and deployment is no longer optional but a must-have competency.
At the same time that developers are confronting this challenge to deliver solutions more quickly, they are also facing the most diverse technology ecosystem in the history of computing. To address this challenge, development teams must modernize architecture, infrastructure, and processes to deliver higher-quality applications with greater agility.
Cloud native development is an approach to building and running applications that fully exploits the advantages of the cloud computing model. Cloud native development multidimensionality involves architecture, infrastructure, and processes based upon four key tenets:
- Services-based architecture: could be microservices or any modular loosely coupled model for independent scalability and flexibility of maintenance and polyglot language runtimes.
- Containers and Docker image: as the deployment unit and self-contained execution environment with consistency and portability across cloud infrastructures.
- DevOps automation: implementing processes and practices and instrumentation of development to test deployment of applications.
- API-based design: The only communication allowed is via service interface calls over the network. No direct linking, no direct reads of another team’s data store, no shared-memory model with an outside- in perspective.
Continue reading “Cloud Native Application Development – Adopt or Fail”
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”
Red Hat 3scale API Management Platform simplifies the integration between the APIcast gateway and Red Hat Single Sign-On through OpenID Connect (OIDC) for API authentication. Consequently, the new version enables API provider users to select and configure their API authentication process from the admin portal UI.
Continue reading “Red Hat 3scale API Management Simplifies OpenID Connect 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”
Happy (St Patrick’s) Friday, everyone.
This is a general “stuff” kind of post. From working with the technical debt of legacy systems (and processes) to navigating new regulations for cybersecurity, these links look at the different and daily aspects of maintaining IT infrastructure that supports your organizational strategies. Even the most glamorous of projects are really only glamorous in planning and in hindsight; the work of implementing those projects is (ahem) work.
Continue reading “Five Links: Get Where You Are Going Edition”