Month: February 2024

Team of professionals

Back to all news

Case study: 365.bank – Evaluating the Future: A Comprehensive Review of Bank’s New Architecture

365.bank is poised to modernize its core IT systems, including core banking and omnichannel platform, for various business and technological reasons. They opted for modern, cloud-based solutions. The primary challenge was to confirm whether this new architecture was feasible and deliverable and could effectively address the initial reasons for initiating the program. The bank needed assurance that the transition would not only be technologically sound but also align with its business objectives and future growth plans.

Solution

Employing a structured methodology, Grow2FIT’s approach for each area included:

  • An initial workshop to review the proposed TO-BE architecture and identified issues.
  • This was followed by the preparation of a draft output for each domain.
  • Subsequent follow-up workshops allowed for collaborative refinement of these drafts.
  • The final stage involved the completion and finalization of the outputs.

The areas reviewed were:

  • Accounts & Cards
  • Payments
  • Consumer & Mortgage Loans
  • Corporate & Treasury
  • Data, Reporting, Compliance & CRM
  • Front-end, New Omnichannel platform integration

Result

After a strategic review, Grow2FIT has advised 365.bank to proceed with a phased approach to IT system enhancement, focusing on key areas such as payment gateway functionality and new customer channels. The recommendation includes the implementation of a new Cloud Data Warehouse solution, focusing initially just on incorporating new requirements into this platform.

We also recommend retaining core banking systems where beneficial. Further stages involve consideration of system evolution based on specific technological, financial, and market-driven factors. Details of the implementation are kept general to respect confidentiality agreements.

Contact Person

Martin Petrík, 365.bank Program Manager

About the client

365.bank is a Slovak bank that carries out its business activities mainly on the basis of the Commercial Code and the Banking Act. The bank offers its clients a wide range of banking and financial products and services. Its core activities include accepting deposits, providing loans, performing domestic and cross-border transfers of funds, providing investment services, performing investment activities and providing ancillary services under the Act on Securities.

Provided services

Key Technologies

  • Mambu
  • Backbase
  • AWS

Team of professionals

Back to all news

Leveraging OpenTelemetry for Fault-Tolerant Prometheus Metrics with Envoy Mirroring

There are a lot of use cases when metrics collected from applications or services need to be forwarded from the local environment to remote centralized long-term storage such as Thanos or Mimir.

This article will help build a fault-tolerant and highly available solution to collect and forward metrics from applications and services running in Kubernetes to the remote Prometheus-compatible long-term TSDB storage. It also requires proper knowledge about the components used, such as the OpenTelemetry collector, Prometheus in agent mode, and Envoy proxy request mirroring. Detailed configuration is outside the scope of this article.

The Design

The OTEL collector collects metrics from desired resources, and the pipeline is configured using OpenTelemetry collector receivers, processors, and exporters to process and send collected metrics to the endpoint of the Envoy proxy.

The Envoy proxy is configured with a static route mirror policy with upstream clusters of Prometheus pods. This means that the Envoy proxy directly connects to the k8s pod and not to the k8s service in front of the pods. Each Prometheus pod represents an Envoy upstream cluster. Data are routed primarily to one of the two replicas of the Prometheus pod and mirrored to the second one.

Prometheus is deployed into the k8s cluster with two replicas in Agent mode with the remote-write-receiver feature enabled. Also, an external label prometheus_replica was added to instances, which is used to deduplicate series in Thanos, sent from high-availability Prometheus instances pairs.

Conclusion

This design helped make monitoring more resilient and reduced the time series data gap in Grafana dashboards.

Author

Gabriel Illés
Senior DevOps Engineer

Dedicated professional with experience in managing cloud infrastructure and system administration, integrating cloud-based infrastructure components, and developing automation and data engineering solutions. Good at troubleshooting problems and building successful solutions. Excellent verbal and written communicator with strong background cultivating positive relationships and exceeding goals.

The entire Grow2FIT consulting team: Our team

Related services