Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Cloud Native bei PostFinance: Praxisbeispiele i...

DevOpsBern
November 08, 2024

Cloud Native bei PostFinance: Praxisbeispiele in a Nutshell

DevOpsBern

November 08, 2024
Tweet

More Decks by DevOpsBern

Other Decks in Technology

Transcript

  1. © 2024, Amazon Web Services, Inc. or its affiliates. Christian

    Nicoll Senior Solutions Architect Amazon Web Services Cloud Native bei PostFinance: Praxisbeispiele in a Nutshell Tobias Pautz Solutions Architect PostFinance
  2. Why using the Public Cloud? • Many software vendors use

    nowadays cloud technologies, to stay competitive there is a need to adapt cloud technologies by PostFinance. • Innovation speed: Quick usage of the latest technologies in the market, faster time-to- market. • Flexible and scalable usage of infrastructure resources (e.g. GPUs for DataScience tasks).
  3. Customer challenge • We invested in the last decade significantly

    in the modernization of our On-Prem stack. “Cloud Agnostic” / Open-Source solutions like Kubernetes, PostgreSQL or Hashicorp Vault are used. • We are working on an EXIT concept which would allow us to migrate workloads to a different service provider. • The key question is to which degree we should use cloud native or cloud agnostic services. 4
  4. Speak about the same terms 5 Business Capabilities Business Applications

    Technical Capabilities Services / Tools Examples • Lead management • Commissions • Customer Credit Rating • Customer Relationship Management • Customer Campaign Management • Market Data Analysis • Payments Processing • Fraud Detection • Employee Benefits • … Examples • Salesforce.com • bsi.crm • SAP • … or custom-built solutions Examples • Container management • Data Streaming • Secrets management • CI/CD pipelines • Monitoring • Relational database • Key-/Value database • Log management • API Gateway • Web Application Firewall • Identity & Access Management • Hypervisor • Function-as-a-Service • … Examples • Kubernetes • RedHat Openshift • Apache Kafka • ArgoCD • Splunk • Oracle • … or Cloud Native solutions • AWS Secrets Manager • AWS Lambda • Amazon DynamoDB • Amazon API Gateway • …
  5. Definitions Cloud native is the software approach of building, deploying,

    and managing modern applications in cloud computing environments. Modern companies want to build highly scalable, flexible, and resilient applications that they can update quickly to meet customer demands. To do so, they use modern tools and techniques that inherently support application development on cloud infrastructure. These cloud-native technologies support fast and frequent changes to applications without impacting service delivery, providing adopters with an innovative, competitive advantage. (Source: https://aws.amazon.com/what-is/cloud-native/) Cloud agnostic refers to a cloud design strategy in which applications, tools, and services are designed to migrate seamlessly between multiple cloud platforms or between on-premises and cloud in a hybrid model without disruption of service. Some of the tenets of a cloud-agnostic approach are to support seamless portability independent of the underlying operating system, to ensure limited disruption of the workloads in migration, and to limit the risk of application downtime while enhancing cost efficiencies. (Source: https://tanzu.vmware.com/cloud-agnostic) 6
  6. Blurred lines – Stop binary thinking 7 Cloud native Cloud

    agnostic AWS Lambda Amazon DynamoDB Kubernetes AWS-managed Open Source (and compatible) AWS Partner Offerings PostgreSQL Amazon Kinesis Apache Kafka Confluent Platform RedHat OpenShift Cloud agnostic commercial Amazon RDS for Oracle Confluent Cloud on AWS Amazon RDS for PostgreSQL Amazon Elastic Kubernetes Service (EKS) Amazon Managed Streaming for Apache Kafka (MSK) RedHat OpenShift Service on AWS Amazon Elastic Container Service Amazon Bedrock
  7. Understand your architectural options 9 Digital Highlander Digital Twins Digital

    Siblings Number of services 1 2 Number of platforms 1 2
  8. Digital Highlander 10 Cloud On-Prem Cloud On-Prem Service Consumer Consumer

    Consumer On-Prem based Cloud based Consumer Consumer Service Consumer Examples: 1) Core-systems / Mainframe 2) Central Workload Automation (like BMC Control-M) Examples: 1) Machine Learning service (like Amazon Q Developer) 2) Object Storage (like Amazon S3 / Glacier) Digital Highlander Digital Twins Digital Siblings Number of services 1 2 Number of platforms 1 2 Idea: The capability is implemented by exactly one service that is deployed in one platform, either on-prem or in the Cloud. Workloads on other platforms do connect on-demand (like REST calls) to the corresponding service. Opportunities: 1) Simplicity as there is no data replication needed 2) Reduced costs (licenses, infra, workforce) as there are generally fewer service instances needed Threats: 1) Increased network latency and costs due to cross- platform calls 2) Potential organizational bottleneck teams 3) Higher impact radius when installing new releases
  9. Digital Twins Idea: Same service is deployed in different platforms,

    either in isolation or both services are connected (like Leading/Follow or Active/Active). Opportunities : 1) Reuse of existing workforce knowledge 2) Higher level of isolation for each platform Threats: 1) Set of potential service candidates will be restricted by on-prem stack (“Common Denominator”) 2) Management effort for running both services 3) Data replication costs 4) Adoption of operational processes (e.g. logs must be consumed from two sides) 11 Cloud On-Prem Cloud On-Prem Service Consumer Consumer Isolated Connected Consumer Service Consumer Service Service Examples: 1) Secrets Management (like Hashicorp Vault) 2) RDBMS (like PostgreSQL) Examples: 1) Message broker services (like Apache ActiveMQ and RabbitMQ) 2) Data Streaming (like Apache Kafka) Digital Highlander Digital Twins Digital Siblings Number of services 1 2 Number of platforms 1 2
  10. Digital Siblings Idea: Two different services are used for the

    same technical capability. While the services will mostly operate independently there could be also a smaller integration line between them. Opportunities: 1) Use the services which best fit on the specific platform 2) Highest level of isolation for each platform 3) Network costs optimization Threats: 1) Management effort for running both services 2) Adoption of operational processes (e.g. logs must be consumed from two sides) 12 Cloud On-Prem Cloud On-Prem Service Consumer Consumer Isolated Connected Consumer Service Consumer Service Service Examples: 1) Virtualized desktops (like Amazon WorkSpaces and Oracle VirtualBox) 2) Web Application Firewall (like AWS WAF or F5 BIG-IP) Examples: 1) Data streaming (like Amazon Kinesis and Apache Kafka) 2) Workflow automation (like AWS Step Functions) Digital Highlander Digital Twins Digital Siblings Number of services 1 2 Number of platforms 1 2
  11. What do we choose @PostFinance? -When to choose which type?

    -Is it better to use a cloud-native only approach or a cloud-agnostic approach? -What impacts the decision to go cloud- native or cloud-agnostic? 13 Digital Siblings Digital Highlander Digital Twins
  12. Digital Highlander @PostFinance (On-Prem based) 14 Situation: No secure internet

    access from within the cloud Action: Choose the Highlander, use the central internet egress Result: Secure Internet access in the cloud by routing through central on-prem internet egress Target: Be able to use secure internet communication in the cloud Digital Highlander Digital Twins Digital Siblings Number of services 1 2 Number of platforms 1 2 Cloud On-Prem Service Consumer Consumer Consumer
  13. Digital Highlander @PostFinance (Cloud based) 15 Situation: No State-of-the-Art (proprietary)

    LLMs available Action: Choose the Highlander, go with Amazon Bedrock! Result: Timely newest LLM-models -> quick time to market Target: A method to use latest LLMs without buying massive infrastructure Digital Highlander Digital Twins Digital Siblings Number of services 1 2 Number of platforms 1 2 Cloud On-Prem Consumer Consumer Service Consumer
  14. Digital Twins @PostFinance (Isolated) 16 Situation: Skilled Kubernetes Operating Team,

    no centrally managed deployment zone in the cloud Action: Choose the Twins, go with Kubernetes (Amazon EKS)! Result: Independent Kubernetes Clusters for on-prem and cloud, serving application needs Target: A secure, centrally manageable hosting zone for applications Cloud On-Prem Service Consumer Consumer Service Digital Highlander Digital Twins Digital Siblings Number of services 1 2 Number of platforms 1 2
  15. Digital Twins @PostFinance (Connected) 17 Situation: Only 2 DC-Setup for

    Kafka on-prem: Security finding for low resiliency Action: Choose the Twins, Run Kafka Stretched Cluster on EC2! Result: High Resiliency at lower cost compared to running a third on-prem DC (only PoC Setup right now) Target: Increase Resiliency with a 3rd DC Cloud On-Prem Service Consumer Consumer Service Digital Highlander Digital Twins Digital Siblings Number of services 1 2 Number of platforms 1 2
  16. Digital Siblings @PostFinance (Isolated) Situation: Missing No-SQL Storage solution for

    the cloud 18 Action: Use Amazon DynamoDB (Cloud) and MongoDB (on-prem) Result: Capable solutions for each environment Target: Have a highly scalable solution to use in the cloud Digital Highlander Digital Twins Digital Siblings Number of services 1 2 Number of platforms 1 2 Cloud On-Prem Service Service Consumer Consumer
  17. Digital Siblings @PostFinance (Connected) 19 Situation: Logging method needed for

    cloud and on-prem Action: Choose the Siblings, go with Splunk (central logging) and Amazon CloudWatch (can be used if needed for cloud)! Result: Single access point for all logs on Splunk (on-prem), detailed analytics for cloud logs with Amazon CloudWatch Target: Have flexibility for logging, but have also one central place to lookup on-prem and cloud event logs Digital Highlander Digital Twins Digital Siblings Number of services 1 2 Number of platforms 1 2 Cloud On-Prem Service Service Consumer Consumer
  18. Choose the best match for each battle 20 -Analyze the

    status quo and the target -Consider costs, effort of setup, long term strategy, existing setup & expertise → No one size fits all. Decide per use case. → Keep your Exit strategy in mind
  19. Patchwork or Best of Breed? 21 H Cloud On-Prem H

    S T T H H H T T H H H T T T T S S H H S Services Patterns H Digital Highlander T Digital Twin S Digital Sibling 1 2 3 n What alternatives exists to this balanced approach?
  20. Alternative approaches 22 Keep it completely Cloud-agnostic Consequence: 1. Don’t

    use the Cloud Native services 2. Buy the services through ISV offerings or build them on your own. 3. Significant loss of speed, innovation, integration and agility ➔ The Cloud will be reduced to “Just another Data Center” Go completely Cloud-native Consequence: 1. Does increase the dependency to the Cloud Service Provider and the “pressure” on the Exit strategy 2. Steeper learning curve and requires a multiple platform management ➔ Rank Productivity over Portability
  21. Create a holistic Exit strategy • Technology is only one

    aspect of the Exit strategy, include further domains like workforce (Skills) or contractual aspects. • Maintain an inventory of Business Applications and which technical capabilities they are using. • Create workload-level specific exit plans and adjust the level of detail depending on the business criticality of the workloads. 23
  22. Don’t mix different concepts Exit strategy (REPLACE services) 24 Timeline:

    Months to years Trigger: Commercial changes, stop of business (e.g. bankruptcy) Disaster Recovery (RESTORE services) Timeline: Minutes to hours Trigger: Natural disasters, Technical failures, Human mistakes High availability (PREVENT the loss of services) Timeline: Milliseconds to seconds Trigger: Component failures, Network issues
  23. The usage of Cloud Native Services can be fully inline

    with your Exit strategy 1. Understand the business requirements of your workload 2. Create different architectural options 3. Evaluate the architecture against your requirements 4. Decide & Realize 25
  24. Wrap-up • There is no one size fits all and

    evaluate your different technical capabilities • Come from concrete Business drivers, like business ideas or upcoming renewals • Portability is only one of many Non- Functional Requirements • Measure your progress by the effective business value created (“Analysis Paralysis”) • Ask your Solutions Architect 26
  25. © 2024, Amazon Web Services, Inc. or its affiliates. Thank

    you! Tobias Pautz [email protected] Did you like the talk? Yes, then share your feedback No, then share your feedback Christian Nicoll [email protected]