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”
As we described in an earlier blog, microservices are mini-applications which are devoted to a single, specific function. They are discrete (independent of other services in the architecture), polyglot with a common messaging or API interface, and they have well-defined parameters.
As application development and IT operations teams have started streamlining and speeding up their processes with methodologies like Agile and DevOps, they have increasingly begun treating IT applications as microservices. This breaks up potential bottlenecks, reduces dependencies on services used by other teams, and can help make IT infrastructure less rigid and more distributed.
One area where we are seeing this looser, more distributed approach to service development is with business rules.
Business rules and processes in a traditional structure tend to be centralized, with the complete set of functionality defined for all workflows. The problem with centralization is because there is a single, centralized collection of business rules, any changes to one set of rules can affect many other sets, even those for different business functions.
Micro-rules essentially treat each functional set of rules as its own service — well-defined, highly focused, and independent of other rules.
Figure – Function rule sets as micro-rules
Continue reading ““Micro-rules,” event-driven apps, and Red Hat Decision Manager”
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”
During the fall of 2017, we conducted a microservices survey with our Red Hat Middleware and Red Hat OpenShift customers. Here are eight interesting trends discerned by the results:
1. Microservices are being used to re-architect existing applications as much as for brand new projects
There seems to be a strong emphasis in the market by technology vendors for positioning microservices as being only for new projects. However, our survey reveals that organizations are also using microservices to re-architect existing and legacy applications.
Sixty-seven percent of Red Hat Middleware customers and 79 percent of Red Hat OpenShift customers indicated this. This data tells us that microservices offer value to users all along their IT transformation journey — whether they are just looking to update their current application portfolio or are gearing up new initiatives. So, if you are only focused on greenfield projects for microservices, it may be a good idea to also start evaluating your existing applications for a microservice re-architecture analysis. Microservices introduce a set of benefits that our customers have already started seeing, and they are applying these benefits not just to new projects but to existing ones as well.
Continue reading “The State of Microservices Survey 2017 – Eight trends you need to know”
On May 2, 2017, we announced a new open source project called Syndesis.io. Syndesis.io provides a low code environment for agile integration. We also demonstrated key capabilities at the Red Hat Summit 2017 keynote.
Building on our foundational work in Syndesis.io, we have expanded those capabilities into a new product and are happy to announce Red Hat Fuse Online as a technical preview.
Continue reading “Announcing Red Hat Fuse Online Technical Preview”
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”
I really dislike the term “legacy apps,” especially when it is used by vendors. It feels like they are calling my baby (i.e. my app) with a bad name. I love the quote by Martin Fowler, “All we are doing is writing tomorrow’s legacy software today.” I am certainly not advocating to stick to your old applications forever. All applications and systems have a life-cycle that goes from build to retire. Somewhere in between lies the stage of renewing the capabilities of the system, often named as modernization, enhancement, or rehab. This is the most important phase from the perspective of extending the life of the application and enhancing the long term value harvested from it.
In IT, each generational transition has called for modernizing and redesigning applications, business processes and IT infrastructure to exploit new technologies’ capabilities and efficiencies. App modernization isn’t carried out as a fashion statement or status symbol but for hard business reasons. Regardless of the era, the benefits of a periodic app overhaul include better performance, more features, greater usability, and higher reliability.
Continue reading “There is no magical OFF switch for legacy apps”