The latest release of Hazelcast’s Jet event stream processing engine for AI and ML deployments of mission-critical applications adds new app development features designed to simplify the integration of an event-driven architecture into brownfield deployments to gain new functionality around real-time and in-memory processing.

“Stream processing” is about processing data in motion–users take action on data at the time it is created. It typically involves multiple tasks performed on an incoming series of data, and it can be performed serially, in parallel, or both. The stream processing pipeline starts with the generation of the data, followed by the processing of the data, and finally the delivery of the data to its destination.

With the release of Hazelcast 4.2, the in-memory computing platform maker
is making it possible to add Jet’s extensibility to existing applications through real-time caching and stateful microservices.

The list of updates and enhancements in this release includes new support for streaming integration with MySQL and PostgreSQL databases using a unified high-level API. Traditional RDBMS-based applications require hundreds or thousands of lines of code to add functionality, as well as significant testing. With the new API in Jet 4.1, the integration becomes more of a declarative task to reduce the custom error-prone code. 

Additionally, Hazelcast Jet makes the database available as a stream. It deals with connectivity, object mapping and unifies the event handling across database vendors. The series of database updates form an event stream on which developers can more easily add microservices without impacting existing applications. This simplification lets developers focus on adding new business logic in high-performance applications rather than managing complex and error-prone integrations. 

The transactional data from MySQL or PostgreSQL can be augmented and enriched with other datasets from Hadoop, Amazon S3, Google Cloud Storage, Azure Data Lake, and others, the company says, and served through thousands of concurrent low-latency queries and fine-grained, key-based access.

“With these enhancements, enterprises can take advantage of in-memory speeds to accelerate analytical queries to scale your architecture by offloading certain workloads from your transactional database into an in-memory store,” the company said in a statement.

Hazelcast provided support in Jet earlier this year for change data capture (CDC) via the open-source Debezium project. In version 4.2 the CDC integration has been optimized to reduce the manual coding required to utilize this capability, the company says.

Also, over the last year, the library of connectors for Hazelcast Jet has been expanded to include Apache Beam, Confluent, MongoDB, JDBC, Apache Cassandra, and others. Version 4.2 includes connectors for Elasticsearch and Apache Pulsar. By connecting Jet to Elasticsearch, the company says, enterprises can rapidly enrich large data sets, including those from relational databases, and transform them into formats suitable for indexing and search-based analysis by Elasticsearch.

The post Hazelcast Simplifies Application Modernization with Event Driven Architectures appeared first on Artificial Intelligence.

I have often observed that a journey to cloud discussion for banks begin and end with Application modernization. Without a doubt, this is an important element of the journey. However, the IT landscape in a typical banking environment presents a unique setup that compels us to think about this pursuit differently.

There are two important considerations: one, the landscape is filled with Commercial-off-the-shelf (COTS) applications, which means banks are heavily dependent on System Integrators to modernize their applications to a cloud-native architecture. And number two, the lack of understanding and therefore the ensuing implementation of data privacy/security/regulatory and governance framework as the bank migrates to a cloud environment.

In a bank environment, the approach to modernization of application may vary based on the COTS attributes and the digital and business drivers for the organization. Many of the legacy applications may continue to have key technical limitations and therefore limit the migration process. Besides,

For some of the applications, the source code may be available and therefore changes required as part of cloud-native architecture are easier to carry out.

Some of the application vendors are already on the modernization pursuit and therefore the container images are available and have exposed APIs and Microservices.

There may be some home-grown applications: cloud migration is easier. However, more often than not, they are non-critical applications and therefore the benefits of running them natively on a cloud (on-prem or public) are somewhat muted.

So, how does one go about approaching application modernization? Keeping the central idea of decoupling identified functions from legacy, we will need to address the challenges of hardwired dependencies on data and application code. Here the proven patterns for incremental modernization can come in handy. The patterns are:
Decoupling Consumer Services from complex Systems of Record. Here the idea is to separate systems of engagement from the core and deploy them in the form of Microservices. This is a clean end-state one can aim for.

Staggered decoupling and modernization using Command Query Responsibility Segregation. Separating the UI layer from the back end data store and handling all the record translations and associated logic enables building services or adaptors for microservices.

In a Microservice mediated pattern, the underlying services are offered and accessed through APIs that are built on top of the core systems.

One can also do away with Microservice and access all services directly via APIs (such as Payment APIs).
Accessing data related functions – Data services, Cognitive Services, and Insights services – through a dedicated enterprise-wide data platform.

All these patterns mentioned above are important while defining the technical architecture of the journey. More often than not, the journey of modernization is a combination of these patterns, the suitability of which will emerge after the initial assessment of the application landscape.

A typical journey will comprise developing clarity around business, technology and infrastructure architectures quickly. To start with, it is important to have clarity on the business architecture: this will help define business services needed, along with the associated capability and process models. The definition of technology architecture can follow this exercise leveraging the patterns outlined earlier.

This is the step where we can define the needed microservices, APIs, automation, and integration needed to decouple the legacy into core and those integration functions that are needed to fulfil the business services.

Let us not forget the choice of Infrastructure platform: irrespective of whether the landscape is completely on-prem or cloud or combinations of multiple clouds, the necessary modernization will need to be carried out to convert the infrastructure into programmable entities. The target state may very well contain several existing components that are modernized and many commercially acquired components (or developed) as composable extensions to be integrated into servicing the business function.

DevOps and Security are two important functions that form part and parcel, not only during the ‘build’ part of this journey but also during the ‘run’ state. Interestingly, as far as processes are concerned, these are strong forte for banks. Because of the sensitivity to customer services and criticality of data, through years they have evolved the process of collaborative testing, automation, integration, and implementation of security processes. But with the advent of new tooling available for DevOps, automation, agile infrastructure, and integrated security management, it becomes important to leverage these new technologies in the context of their existing mature process framework.

A siloed and piecemeal approach to modernization will, at best, tackle the peripheral applications and therefore tend to have a sub-optimal impact. As part of scaling the adoption of cloud or modernizing legacy, banks will benefit from creating a blueprint and methodically get to the end state, realizing incremental business benefits along the way.

The post Journey to application modernization in banking appeared first on Artificial Intelligence.

These days, it seems like Machine Learning (ML) is everywhere. Well, everywhere except in legacy applications. But you can hardly blame the application if it was created prior to the recent advances in Python that have made ML mainstream (i.e. the last 3-5 years). Unfortunately, rewriting or refactoring legacy applications is typically a cost-prohibitive non-starter. But if you don’t modernize older applications by adding capabilities like ML, your customers will sooner or later stop using them.

Certainly, the market is now full of established analytics and reporting applications that are all making the leap to include some kind of AI/ML functionality in order to avoid becoming obsolete. After all, ML thrives on data, so baking it into the foundations of data analysis in the enterprise just makes sense. Every application has someplace to store/some way to leverage data. And all of these applications could  apply ML to that data in order to discover insights, create new business opportunities, or just accomplish a task faster, better, or maybe for the first time ever.

For example:

• Insurance – ML is allowing insurance companies to mine their abundant claims data in order to automate underwriting and claims adjustment.
• Banking & Finance – ML allows banks to combine a customer’s online banking behaviour with social media data in order to better understand and make predictions about the customer’s financial needs.
• Healthcare – using ML to study disease progression from clinical data allows doctors to better predict death dates for patients with terminal illnesses, and ensure that palliative care can be provided in a timely manner.

Legacy Modernization With Python

Each of these industries (and many more) have benefited by extending their legacy applications to enable ML capabilities. But when it comes to updating legacy apps, there are many different approaches. API wrapping (aka encapsulation) is the simplest, most cost-effective way to modernize older applications, making them far more usable with minimal effort. Figure 1. Below shows that encapsulation (API wrapping) has the lowest complexity and cost.

The post Add Machine Learning To Legacy Applications With Python appeared first on Artificial Intelligence.