Cloud Computing Köln - Seite 2408 von 7061 - Neues zu Cloud Computing, Internet of Things und Technologien

Banks and other financial service institutions (FSIs), such as payment processors, need to overhaul their fragmented legacy payment infrastructures, which can no longer support growing online demand in Asia-Pacific, where consumers want real-time response and personalized service.This will be increasingly pressing as market competition likely drives transaction fees closer to zero, and FSIs are compelled to seek out new revenue streams to plug the hole.They can find these opportunities in the Asia-Pacific region, where online adoption is climbing and consumers are increasingly choosing digital payments over cash. This trend will continue as the global pandemic stretches on. The desire to minimize contact during the COVID-19 outbreak has pushed 91% of consumers in Asia-Pacific to pay with cards or mobile apps, instead of cash, according to aVisa study. And 75% plan to retain their digital payment habits even after the pandemic is over. These habits are surfacing in India, for example, where 39% prefer digital payment methods, compared to 26% who choose debit and credit cards, and 26% who prefer cash, according to astudy by YouGov and ACI Worldwide. Some 57% in the country use digital payments, including e-wallets, more than twice weekly to pay for their purchases during festive seasons, up from 43% in 2019. In addition, 29% now use digital payments at least once daily, compared to 15% last year. India has 190 million unbanked adults, indicating there is ample opportunity for even further growth. Failed transactions, however, have become a concern for 44% of Indian consumers, compared to 36% in 2019, the ACI study finds. Another 42% are anxious about fake apps or websites used in scams, while 40% express concerns about fraudulent Know Your Customer (KYC) updates and fake online payment links.Consumer anxiety over payments presents opportunities for FSI players to differentiate their market play by offering services that are not only more secure, but also more transparent. They can also stand out from the competition by delivering services tailored to the customer’s preferences and buying habits.To do that, banks will need an infrastructure that applies artificial intelligence (AI) and data analytics, and one that is able to establish a consolidated view of a customer’s financial interactions. They will not be able to do all of that with their legacy payment systems.Remove silos to deliver consistent payment experienceTraditional banks and payment processors are built around product ownership, which creates silos that separate the solution components that deliver standalone customer experiences.Walk into a bank today and you will find credit card and transaction account systems each running their own set of processes, around fraud and crime detection. Because these are developed on an individual product level, each built in a silo, the bank ends up with multiple structures for fraud detection. Many financial crimes occur because enterprise policy is not consistently embedded across systems and channels, and by reducing silos, a bank can increase confidence that policies are correctly enabled. On the other hand, consumers want a frictionless purchasing experience. They don’t care what processes are used as long as they are able to safely and easily complete their transaction. Further, this purchasing experience should not disrupt a frictionless buying experience, it should be processed in real-time, and it should be carried out free of charge or at a low cost.A payments experience should cater to how customers want to pay, and should be as seamless as possible to the customer, while a complex transaction process takes place in the background.To do this, payment infrastructure should be scalable and agile so it can accommodate spikes in demand driven by seasonal volumes and real-time fluctuations in compute resources. Such infrastructure can only be achieved via a cloud-native architecture that can facilitate microservices and application programming interfaces (APIs). This level of interoperability and granularity means that new services can be developed both internally or with external partners. APIs enable banks to build applications that leverage different legacy systems and microservices, and also allow banks to share this data and functionality with partners, eliminating the laborious system integration challenges that often plague the banking industry’s various siloed systems. FSIs will need to rebuild their systems and deliver customer-focused digital payment experiences, lest they risk losing out to neobanks or other fintech competitors. For example, it has been true for several years that younger customers engage with their financial services providers differently than older generations. If FSIs want to stay relevant, and to grow with this consumer base over time, they will need to rethink their payment strategies—and that starts with an agile, cloud-based, API-first approach rather than ongoing reliance on legacy processes.How banks are leveraging Google Cloud to remain competitive Singapore-based fintech playerFOMO Pay saw a gap in the market when it launched a digital payment processing platform that enables merchants to accept a full suite of mobile payment options, including Visa QR, WeChat Pay, and Alipay. Running on Google Cloud, FOMO Pay processes more than 3 million transactions every month and handles up to five transactions per second with no service disruption. The company taps Google Cloud’s data analytics, machine learning, and AI features to generate analysis and insights from various data sources, helping it better meet customer expectations. FOMO Pay also chose the cloud platform due to Google’s ability to meet security and regulatory requirements governing the storage and processing of sensitive payment and customer data.Australian electronic bill payments platformBPAY Group also turned to APIs to resolve challenges that were impacting its customers. Having operated for more than 22 years, the company realized it had legacy practices that needed reengineering. For instance, it traditionally used batch-processing systems to handle requests between billing companies and banks, but this would result in service disruptions in which an error in one request would cause an entire batch to be rejected. Batch processes also took longer to complete, which drove neobanks’ preference to work with real-time transactions.BPAY turned to Google’s Apigee API management platform to drive the development of its APIs, releasing four foundational APIs. These now let businesses not only validate payment information before submitting a batch file, which significantly reduces the margin for error, but also automatically generate batch files in the right format for different banks. It is also through these APIs thatBPAY’s partner Zip allows customers to tap its Buy Now Pay Later (BNPL) services to pay any bill that bears the BPAY logo.Such innovative digital payment services can only be possible when banks and FSIs have the right infrastructure in place, defined by qualities that include:cloud-native and agile built for streaming and able to handle burst capacityintegrated with robust security featuresable to provide data insights through AIAPI-enabledThe cloud will better arm FSIs to monetize payment flows and facilitate collaboration with partners, including new fintech players, to drive the development of innovative payment solutions. Google Cloud, through its comprehensive portfolio that includes Apigee and machine learning capabilities, is able to provide FSIs the infrastructure they need to succeed in a highly competitive payments market that’s constantly evolving.Learn more about Google Cloud for financial services.Related ArticleRegistration is open for Google Cloud Next: October 12–14Register now for Google Cloud Next on October 12–14, 2021Read Article
Quelle: Google Cloud Platform

3. September 2021

da Agency

Traffic Director explained!

If your application is deployed in a microservices architecture then you are likely familiar with the networking challenges that come with it. Traffic Director helps you run microservices in a global service mesh. The mesh handles networking for your microservices so that you can focus on your business logic and application code, and that doesn’t need to know about underlying networking complexities. This separation of application logic from networking logic helps you improve your development velocity, increase service availability, and introduce modern DevOps practices in your organization.Click to enlargeHow does a typical service mesh work in Kubernetes?In a typical service mesh you deploy your services to a Kubernetes cluster.Each of the services’ Pods has a dedicated proxy (usually Envoy) running as a sidecar container alongside the application container(s).Each sidecar proxy talks to the networking infrastructure (a control plane) that is installed in your cluster. The control plane tells the sidecar proxies about services, endpoints, and policies in your service mesh.When a Pod sends or receives a request, the request is intercepted by the Pod’s sidecar proxy. The sidecar proxy handles the request, for example, by sending it to its intended destination.The control plane is connected to each proxy and provides information that the proxies need to handle requests. To understand the flow, if application code in Service A sends a request, the proxy handles the request and forwards it to Service B. This model enables you to move networking logic out of your application code. You can focus on delivering business value while letting the service mesh infrastructure take care of application networking.How is Traffic Director different?Traffic Director works similarly to the typical service mesh model, but it’s different in a few very crucial ways. Traffic Director provides: A fully managed and highly available control plane. You don’t install it, it doesn’t run in your cluster, and you don’t need to maintain it. Google Cloud manages all this for you with production level SLOs. Global load balancing with capacity and health awareness, and failovers.Integrated security features to enable a zero-trust security posture. Rich control plane and data plane observability features.Support for multi-environment service meshes spanning across multi-cluster Kubernetes, hybrid cloud, VMs, gRPC services, and more.In the example pictured here, Traffic Director is the control plane and the four services in the Kubernetes cluster, each with sidecar proxies, are connected to Traffic Director.Traffic Director provides the information that the proxies need to route requests. For example, application code on a Pod that belongs to Service A sends a request. The sidecar proxy running alongside this Pod handles the request and routes it to a Pod that belongs to Service B.Multi-cluster Kubernetes: Traffic Director supports application networking across Kubernetes clusters. In this example, it provides a managed and global control plane for Kubernetes clusters in the US and Europe. Services in one cluster can talk to services in another cluster. You can even have services that consist of Pods in multiple clusters. With Traffic Director’s proximity-based global load balancing, requests destined for Service B go to the geographically nearest Pod that can serve the request. You also get seamless failover; if a Pod is down, the request automatically fails over to another Pod that can serve the request, even if this Pod is in a different Kubernetes cluster.How does Traffic Director work across hybrid and multi-cloud environments?Whether you have services in Google Cloud, on-premises, in other clouds, or all of these, your fundamental application networking challenges remain the same. How do you get traffic to these services? How do these services communicate with each other?Traffic Director can route traffic from services running in Google Cloud to services running in another public cloud and to services running in an on-premises data center. Services can use Envoy as a sidecar proxy or a proxyless gRPC service. When you use Traffic Director, you can send requests to destinations outside of Google Cloud. This enables you to use Cloud Interconnect or Cloud VPN to privately route traffic from services inside Google Cloud to services or gateways in other environments. You can also route requests to external services reachable over the public internet.How does Traffic Director support proxyless gRPC and VMs?Virtual machines: Traffic Director solves application networking for VM-based workloads alongside Kubernetes-based workloads. You simply add a flag to your Compute Engine VM instance template, and Google seamlessly handles the infrastructure set up, which includes installing and configuring the proxies that deliver application networking capabilities.As an example, traffic enters your deployment through External HTTP(S) Load Balancing to a service in the Kubernetes cluster in one region and can then be routed to another service on a VM in a totally different region.gRPC: With Traffic Director, you can easily bring application networking capabilities such as service discovery, load balancing, and traffic management directly to your gRPC applications. This functionality happens natively in gRPC, so service proxies are not required—that’s why they’re called proxyless gRPC applications. For more information, see Traffic Director and gRPC—proxyless services for your service mesh.For a more in-depth look into Traffic Director check out this post and documentation. For more #GCPSketchnote, follow the GitHub repo. For similar cloud content follow me on Twitter @pvergadia and keep an eye out on thecloudgirl.dev.Related ArticleImprove gRPC service availability and efficiency with Traffic DirectorMake your proxyless gRPC services with Traffic Director more reliable and efficient with the new capabilities: Retry and Session Affinity.Read Article
Quelle: Google Cloud Platform

For decades, many of us have been building a future where we could be connected while apart. COVID made that necessary. Turns out I hate it.