DOCSLIB.ORG

7 Key Considerations for Microservices-Based Application Delivery Ensuring the Success of Your Cloud-Native Journey

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
7 Key Considerations for Microservices-Based Application Delivery Ensuring the Success of Your Cloud-Native Journey White Paper 7 key considerations for microservices-based application delivery Ensuring the success of your cloud-native journey By Lee Calcote and Pankaj Gupta Citrix | 7 key considerations for microservices-based application delivery 2 The role of application delivery in 3. Choosing the perfect proxy your cloud-native journey 4. Securing your applications and APIs 5. Enabling CI/CD and canary deployment with As digital transformation is changing how your advanced traffic steering organization conducts business, it is also changing 6. Achieving holistic observability how your products and services are delivered. The infrastructure and practices by which your software is 7. Managing monoliths and microservices continuously deployed and operated—your application A thorough evaluation of these seven considerations delivery—is the fulcrum of your organization’s is best done with specific tasks and goals in mind. digital transformation. Likely you are progressing Depending on the size and diversity of your organization, on your cloud-native journey—that is, transitioning you may need to account for a variety of stakeholders’ from monolithic to container-based microservices needs—that is, tasks and goals that differ based on role architectures with the goal of achieving agility, and responsibility. portability, and on-demand scalability. Kubernetes is the platform of choice for many companies, providing In context of application delivery, we’ll survey the the automation and control necessary to manage most common roles with a generalized view of their microservices-based applications at scale and with responsibilities and needs as stakeholders. To help high velocity. facilitate a general understanding, we’ve grouped some roles when responsibilities overlap across multiple teams: The network is part and parcel to each and every service request in your microservices-based application. • Platform: Platform teams are responsible for Therefore, it may come as no surprise that at the core deploying and managing their Kubernetes of application delivery is your application delivery infrastructure. They are responsible for platform controller, an intelligent proxy that accelerates and governance, operational efficiency, and developer manages application delivery. With no standard agility. The platform team is the connective tissue definition of what an application delivery controller among various teams like DevOps, SREs, developers, does, the capabilities of intelligent proxies vary broadly. and network operations teams and therefore must In this white paper, we’ll explore application delivery address and balance the unique needs of a diverse controllers as they relate to your architecture choices, group of stakeholders, or influencers, when choosing your use of container platforms, and open source tools. cloud-native solutions. • DevOps: DevOps teams are responsible for continuously deploying applications. They care about 7 key considerations for faster development and release cycles, CI/CD and microservices-based application automation, and canary and progressive rollout. • SREs: Site reliability engineers must ensure delivery application availability. They care about observability, Before embarking on your cloud-native journey, it’s incident response, and postmortems. SREs often essential to critically assess your organization’s act as architects for the DevOps team and are often readiness so you can choose the solutions that extensions of or directly belong to DevOps teams. best fit your business objectives. There are seven • Developers: Development teams are responsible key considerations to address when planning your for application performance and are focused on microservices-based application delivery design: ensuring a seamless end-user experience, including troubleshooting, and microservices discovery and 1. Architecting your foundation the right way routing. Application performance and troubleshooting 2. Openly integrating with the cloud-native ecosystem is a shared responsibility among multiple teams. Citrix | 7 key considerations for microservices-based application delivery 3 • NetOps: Network operations teams are responsible being redrawn. Be aware that the individuals who fill for ensuring stable, high-performing network these roles typically go through a period of adjustment connectivity, resiliency, security (web application that can be unsettling until they adapt. firewalls and TLS, for example), and are commonly Your cloud-native infrastructure should be as focused on north-south traffic. They care about accommodating as possible to you, your team, and your establishing networking policies and enforcing collective responsibilities and process, so we encourage compliance; achieving management, control, and you to seek solutions that address the needs of all your monitoring of the network; and gaining visibility for the stakeholders. Significantly, this includes evaluating purpose of resources and capacity planning. different architectural models that are best suited to • DevSecOps: DevSecOps teams care about ensuring a the purpose. While every organization doesn’t travel strong security posture and rely on automated tools to the same road to cloud-native, every journey starts orchestrate security for infrastructure, applications, with initial architectural decisions—decisions that have containers, and API gateways. DevSecOps works substantial bearing on your path to cloud native. very closely with NetOps to ensure a holistic security posture. 1. Architecting your foundation the Each role has nuanced responsibilities. Whether you right way have a single person or entire teams assigned to these roles, each role’s function needs to be accounted for. Cloud native novices and experts alike find that designing their application delivery architectures is the It’s important to note that these stakeholders are most challenging part of building microservices. Your undergoing a transformation in their responsibilities— architectural choices will have a significant impact or at least a transformation in the way that they on your cloud-native journey. Some architectures will perform their responsibilities. Depending upon your provide greater or fewer benefits while others will prove organization’s size and structure, your stakeholders may less or more difficult to implement. or may not have clearly defined lines of accountability among roles. As you adopt a cloud-native approach to Whether you are a cloud-native pro or a novice, your application deployment and delivery, you may find that selection of the right application delivery architecture the once-defined lines have blurred or that they are Diverse stakeholders have unique needs Platform team Platform governance, operational efficiency, developer agility DevOps Developers SRE NetOps DevSecOps Faster release and User experience, Application availability, Network policy and Application and deployment cycles, troubleshooting, observability, incident compliance; manage, infrastructure security, CI/CD and automation, microservice discovery, response, postmortems control, and monitor container security and canary and progressive and routing network; resource and API gateways, and rollout capacity planning automation Citrix | 7 key considerations for microservices-based application delivery 4 will balance the tradeoff between the greatest benefits • Open source tools integration and the simplicity needed to match your team’s skill set. • Service mesh and Istio integration Figure 1 highlights four common application delivery • IT skill set required architecture deployment models. Learn more about the evaluation criteria. Tip: Traffic directions Let’s examine each of the four deployment models. North-south (N-S) traffic refers to traffic between clients outside the Kubernetes cluster and services inside the cluster, while east-west (E-W) traffic Two-tier ingress refers to traffic between services inside the Two-tier ingress is the simplest architectural model Kubernetes cluster. to deploy to get teams up and running quickly. In this deployment model, there are two layers of ADCs for Each of the deployment models in Figure 1 come with N-S traffic ingress. The external ADC (at Tier 1), shown their list of pros and cons and are typically the point in green in Figure 2, provides L4 traffic management. of focus of different teams. So how do you choose the Frequently, additional services are assigned to this right architecture for your deployment? Given the needs ADC and can include web application firewall (WAF), of your stakeholders and the many specifics involved secure sockets layer/transport layer security offload in managing both north-south (N-S) and east-west (SSL/TLS) functionality, and authentication. A two-tier (E-W) traffic, it is critical to assess the four different ingress deployment model is often managed by the architectures with respect to the following areas: existing network team (which is familiar with internet- facing traffic), and it can also be used as an ADC for • Application security other existing applications simultaneously. • Observability The second ADC (Tier 2), shown in orange in • Continuous deployment Figure 2, handles L7 load balancing for N-S traffic. • Scalability and performance It is managed by the platform team and is used within Figure 1: Citrix architectures for microservices-based application delivery Citrix ADC High Citrix ADC Citrix ADC (CPX) Pod Pod Citrix ADC (CPX) Service Proxy Service Proxy Citrix ADC Pod Pod Citrix ADC Pod Pod Service Proxy
Load more

Recommended publications
  • Open Virtualization Infrastructure for Large Telco: How Turkcell Adopted Ovirt for Its Test and Development Environments
    Open Virtualization Infrastructure for large Telco: How Turkcell adopted oVirt for its test and development environments DEVRIM YILMAZ SAYGIN BAKTIR Senior Expert Cloud Engineer Cloud Systems Administrator 09/2020 This presentation is licensed under a Creative Commons Attribution 4.0 International License About Turkcell ● Turkcell is a digital operator headquartered in Turkey ● Turkcell Group companies operate in 5 countries – Turkey, Ukraine, Belarus, Northern Cyprus, Germany ● Turkcell is the only NYSE-listed company in Turkey. ● www.turkcell.com.tr 3 Business Objectives ● Alternative solutions compatible with Turkcell operational and security standards ● Dissemination of open source infrastructure technologies within the company ● Competitive infrastructure with cost advantage 3 The journey of oVirt 4 The Journey of oVirt 3. Step three 1. Research & 2. Go-Live 3. Go-Live 4. Private Cloud 5. Go-Live Development Phase-1 Phase-2 Automation RHV 5 Research & Development ● Motivation Factors ○ Cost 1. Research & ○ Participation Development ○ Regulation ○ Independence ○ Expertise ● Risk Factors ○ Security ○ Quality ○ Compliance ○ Support ○ Worst Practices 6 Research & Development ● Why oVirt? ○ Open Source licensing 1. Research & ○ Community contribution Development ○ The same roadmap with commercial product ○ Support via subscription if required ○ Adequate features for enterprise management ○ Rest API support 6 Research & Development ● Difficulties for new infra solution ○ Integration with current infrastructure 1. Research & - Centralized Management Development - Certified/Licensed Solutions - Integration Cost ○ Incident & Problem Management - 3rd Party Support - Support with SLA ○ Acquired Habits - Customer Expectations - Quality of IT Infrastructure Services 6 Research & Development ● What we achieved ○ Building of PoC environment 1. Research & ○ V2V Migration Development ○ Upgrade Tests starting with v.4.3.2 ○ Functional Tests ○ Backup Alternative Solutions 6 Go-Live Phase-1 ● Phase-1 contains : ○ Building of new oVirt platform with unused h/w 2.
    [Show full text]
  • Red Hat Enterprise Linux 7 Libreswan Cryptographic Module Version 7.0 and Version Rhel7.20190509 FIPS 140-2 Non-Proprietary Security Policy
    Red Hat Enterprise Linux 7 Libreswan Cryptographic Module version 7.0 and version rhel7.20190509 FIPS 140-2 Non-Proprietary Security Policy Version 1.3 Last update: 2021-05-03 Prepared by: atsec information security corporation 9130 Jollyville Road, Suite 260 Austin, TX 78759 www.atsec.com ©2021 Red Hat®, Inc. / atsec information security corporation Page 1 of 23 This document can be reproduced and distributed only whole and intact, including this copyright notice. Red Hat Enterprise Linux 7 Libreswan Cryptographic Module FIPS 140-2 Non-Proprietary Security Policy Table of contents 1 Introduction ........................................................................................................................... 3 2 Cryptographic Module Specification ...................................................................................... 4 2.1 Module Overview ......................................................................................................... 4 2.2 FIPS 140-2 Validation ................................................................................................... 5 2.3 Modes of Operation ...................................................................................................... 6 3 Cryptographic Module Ports and Interfaces ........................................................................... 7 4 Roles, Services and Authentication ....................................................................................... 8 4.1 Roles ...........................................................................................................................
    [Show full text]
  • Clouder Documentation Release 1.0
    Clouder Documentation Release 1.0 Yannick Buron May 15, 2017 Contents 1 Getting Started 3 1.1 Odoo installation.............................................3 1.2 Clouder configuration..........................................4 1.3 Services deployed by the oneclick....................................6 2 Connect to a new node 9 3 Images 13 4 Applications 15 4.1 Application Types............................................ 15 4.2 Application................................................ 16 5 Services 21 6 Domains and Bases 25 6.1 Domains................................................. 25 6.2 Bases................................................... 27 7 Backups and Configuration 31 7.1 Backups................................................. 31 7.2 Configuration............................................... 33 i ii Clouder Documentation, Release 1.0 Contents: Contents 1 Clouder Documentation, Release 1.0 2 Contents CHAPTER 1 Getting Started In this chapter, we’ll see a step by step guide to install a ready-to-use infrastructure. For the example, the base we will create will be another Clouder. Odoo installation This guide will not cover the Odoo installation in itself, we suggest you read the installation documentation on the official website. You can also, and it’s probably the easier way, use an Odoo Docker image like https://hub.docker.com/ _/odoo/ or https://hub.docker.com/r/tecnativa/odoo-base/ Due to the extensive use of ssh, Clouder is only compatible with Linux. Once your Odoo installation is ready, install the paramiko, erppeek and apache-libcloud python libraries (pip install paramiko erppeek apache-libcloud), download the OCA/Connector module on Github and the Clouder modules on Github and add them in your addons directory, then install the clouder module and clouder_template_odoo (this module will install a lot of template dependencies, like postgres, postfix etc...).
    [Show full text]
  • Citrix ADC SDX 12.1
    Citrix ADC SDX 12.1 Citrix Product Documentation | docs.citrix.com September 21, 2021 Citrix ADC SDX 12.1 Contents Introduction 3 Release Notes 3 Getting Started with the Management Service User Interface 3 Data governance 9 Introduction to Citrix ADM service connect for Citrix ADC SDX appliances 11 Single bundle upgrade 14 Upgrading a Citrix ADC instance 17 Manage and Monitor the SDX appliance 19 Creating SDX Administrative Domains 25 Managing RAID Disk Allocation on 22XXX Series SDX Appliances 27 SDX Licensing Overview 31 SDX Resource Visualizer 34 Manage interfaces 35 Jumbo Frames on SDX Appliances 38 Configuring SNMP on SDX Appliances 52 Configuring Syslog Notifications 58 Configuring Mail Notifications 59 Configuring SMS Notifications 59 Monitoring and Managing the Real‑Time Status of Entities Configured on an SDX Appliance 60 Monitoring and Managing Events Generated on Citrix ADC instances 65 Call Home Support for Citrix ADC instances on an SDX Appliance 73 System Health Monitoring 75 Configuring System Notification Settings 79 © 1999–2021 Citrix Systems, Inc. All rights reserved. 2 Citrix ADC SDX 12.1 Configuring the Management Service 80 Configuring Authentication and Authorization Settings 84 Configuring the External Authentication Server 89 Configuring Link Aggregation from the Management Service 94 Configuring a Channel from the Management Service 95 Access Control Lists 96 Set up a cluster of Citrix ADC instances 102 Configuring Cluster Link Aggregation 104 Configuring SSL Ciphers to Securely Access the Management Service
    [Show full text]
  • Deploying Netapp HCI for Red Hat Openshift on RHV HCI Netapp September 23, 2021
    Deploying NetApp HCI for Red Hat OpenShift on RHV HCI NetApp September 23, 2021 This PDF was generated from https://docs.netapp.com/us-en/hci- solutions/redhat_openshift_deployment_summary.html on September 23, 2021. Always check docs.netapp.com for the latest. Table of Contents Deploying NetApp HCI for Red Hat OpenShift on RHV . 1 Deployment Summary: NetApp HCI for Red Hat OpenShift on RHV . 1 1. Create Storage Network VLAN: NetApp HCI for Red Hat OpenShift on RHV. 1 2. Download OpenShift Installation Files: NetApp HCI for Red Hat OpenShift on RHV . 2 3. Download CA Certificate from RHV: NetApp HCI for Red Hat OpenShift on RHV . 4 4. Register API/Apps in DNS: NetApp HCI for Red Hat OpenShift on RHV . 5 5. Generate and Add SSH Private Key: NetApp HCI for Red Hat OpenShift on RHV. 7 6. Install OpenShift Container Platform: NetApp HCI for Red Hat OpenShift on RHV . 8 7. Access Console/Web Console: NetApp HCI for Red Hat OpenShift on RHV . 10 8. Configure Worker Nodes to Run Storage Services: NetApp HCI for Red Hat OpenShift on RHV. 11 9. Download and Install NetApp Trident: NetApp HCI for Red Hat OpenShift on RHV . 13 Deploying NetApp HCI for Red Hat OpenShift on RHV Deployment Summary: NetApp HCI for Red Hat OpenShift on RHV The detailed steps provided in this section provide a validation for the minimum hardware and software configuration required to deploy and validate the NetApp HCI for Red Hat OpenShift on RHV solution. Deploying Red Hat OpenShift Container Platform through IPI on Red Hat Virtualization consists of the following steps: 1.
    [Show full text]
  • 8. IBM Z and Hybrid Cloud
    The Centers for Medicare and Medicaid Services The role of the IBM Z® in Hybrid Cloud Architecture Paul Giangarra – IBM Distinguished Engineer December 2020 © IBM Corporation 2020 The Centers for Medicare and Medicaid Services The Role of IBM Z in Hybrid Cloud Architecture White Paper, December 2020 1. Foreword ............................................................................................................................................... 3 2. Executive Summary .............................................................................................................................. 4 3. Introduction ........................................................................................................................................... 7 4. IBM Z and NIST’s Five Essential Elements of Cloud Computing ..................................................... 10 5. IBM Z as a Cloud Computing Platform: Core Elements .................................................................... 12 5.1. The IBM Z for Cloud starts with Hardware .............................................................................. 13 5.2. Cross IBM Z Foundation Enables Enterprise Cloud Computing .............................................. 14 5.3. Capacity Provisioning and Capacity on Demand for Usage Metering and Chargeback (Infrastructure-as-a-Service) ................................................................................................................... 17 5.4. Multi-Tenancy and Security (Infrastructure-as-a-Service) .......................................................
    [Show full text]
  • Paas Solutions Evaluation
    PaaS solutions evaluation August 2014 Author: Sofia Danko Supervisors: Giacomo Tenaglia Artur Wiecek CERN openlab Summer Student Report 2014 CERN openlab Summer Student Report 2014 Project Specification OpenShift Origin is an open source software developed mainly by Red Hat to provide a multi- language PaaS. It is meant to allow developers to build and deploy their applications in a uniform way, reducing the configuration and management effort required on the administration side. The aim of the project is to investigate how to deploy OpenShift Origin at CERN, and to which extent it could be integrated with CERN "Middleware on Demand" service. The student will be exposed to modern cloud computing concepts such as PaaS, and will work closely with the IT middleware experts in order to evaluate how to address service needs with a focus on deployment in production. Some of the tools that are going to be heavily used are Puppet and Openstack to integrate with the IT infrastructure. CERN openlab Summer Student Report 2014 Abstract The report is a brief summary of Platform as a Service (PaaS) solutions evaluation including investigation the current situation at CERN and Services on Demand provision, homemade solutions, external market analysis and some information about PaaS deployment process. This first part of the report is devoted to the current status of the process of deployment OpenShift Origin at existing infrastructure at CERN, as well as specification of the common issues and restrictions that were found during this process using different machines for test. Furthermore, the following open source software solutions have been proposed for the investigation of possible PaaS provision at CERN: OpenShift Online; Cloud Foundry; Deis; Paasmaster; Cloudify; Stackato; WSO2 Stratos.
    [Show full text]
  • Red Hat Openshift Container Platform 3.6
    RED HAT OPENSHIFT CONTAINER PLATFORM 3.6 DATASHEET KEY BENEFITS OVERVIEW • Deliver your latest innova- Red Hat® OpenShift Container Platform helps organizations develop, deploy, and manage exist- tion to market faster and stay ing and container-based applications seamlessly across physical, virtual, and public cloud infra- ahead of your competition. structures. Built on proven open source technologies, Red Hat OpenShift Container Platform helps application development and IT operations teams modernize applications, deliver new services, and • Accelerate application accelerate development processes. development by giving your developers and system admin- RED HAT OPENSHIFT CONTAINER PLATFORM istrators the tools they need FOR APPLICATION DEVELOPMENT TEAMS to get the job done. OpenShift Container Platform provides developers with an optimal platform for provisioning, build- • Use a secure, enterprise- ing, and deploying applications and their components in a self-service fashion. With automated grade, container-based workflows like our source-to-image (S2I) process, it is easy to get source code from version control platform with no vendor systems into ready-to-run, docker-formatted container images. OpenShift Container Platform inte- lock-in. grates with continuous integration (CI) and continuous delivery (CD) tools, making it an ideal solution • Support DevOps and depart- for any organization. ment-wide collaboration. FOR I.T. OPERATIONS OpenShift Container Platform gives IT operations a secure, enterprise-grade Kubernetes that pro- Red Hat OpenShift Online vides policy-based control and automation for applications. Cluster services, scheduling, and orches- is a public cloud application tration provide load-balancing and auto-scaling capabilities. Security features prevent tenants from platform that lets you quickly compromising other applications or the underlying host.
    [Show full text]
  • Openshift Vs Pivotal Cloud Foundry Comparison Red Hat Container Stack - Pivotal Cloud Foundry Stack
    OPENSHIFT VS PIVOTAL CLOUD FOUNDRY COMPARISON RED HAT CONTAINER STACK - PIVOTAL CLOUD FOUNDRY STACK 3 AT A GLANCE PIVOTAL CF OPENSHIFT • ●Garden and Diego • ●Docker and Kubernetes • ●.NET and Spring • ●.NET, Spring and JBoss Middleware • ●Only Cloud-native apps (including full Java EE) • ●Container security on Ubuntu • ●Cloud-native and stateful apps • ●Deployment automation • ●Enterprise-grade security on • ●Open Core Red Hat Enterprise Linux • ●Pivotal Labs consulting method • ●Complete Ops Management • ●100% Open Source 5X PRICE • ●Red Hat Innovation Labs consulting method BRIEF COMPARISON PIVOTAL CF OPENSHIFT GARDEN & DIEGO DOCKER & KUBERNETES • ●Garden uses OCI runC backend • ●Portable across all docker platforms • ●Not portable across Cloud Foundry distros • ●IP per container • ●Containers share host IP • ●Integrated image registry • ●No image registry • ●Image build from source and binary • ●Private registries are not supported • ●Adoption in many solutions • ●No image build • ●Adoption only in Cloud Foundry 11 NO NATIVE DOCKER IN CLOUD FOUNDRY Converters Are Terrible Cloud Foundry is based on the Garden container runtime, not Docker, and then has RunC and Windows backends. RunC is not Docker, just the lowest runtime layer Docker Developer Experience Does Not Exist in PCF PCF “cf push” Dev Experience does not exist for Docker. In Openshift v3 we built S2I to provide that same experience on top of native Docker images/containers Diego Is Not Kubernetes Kubernetes has become the defacto standard for orchestrating docker containers.
    [Show full text]
  • Forrester: Multicloud Container Development Platforms, Q3 2020
    LICENSED FOR INDIVIDUAL USE ONLY The Forrester Wave™: Multicloud Container Development Platforms, Q3 2020 The Eight Providers That Matter Most And How They Stack Up by Dave Bartoletti and Charlie Dai September 15, 2020 Why Read This Report Key Takeaways In our 29-criterion evaluation of multicloud Red Hat-IBM, Google, And Rancher Lead The container development platform providers, we Pack identified the eight most significant ones — Forrester’s research uncovered a market in which Canonical, D2iQ, Google, Mirantis, Platform9 Red Hat-IBM, Google, and Rancher are Leaders; Systems, Rancher, Red Hat-IBM, VMware — VMware, D2iQ, and Platform9 Systems are and researched, analyzed, and scored them. Strong Performers; and Mirantis and Canonical This report shows how each provider measures are Contenders. up and helps infrastructure and operations Dev Experience, Distributed Operations, And professionals select the right one for their needs. Ecosystem Integrations Are Key Differentiators As developers and technology teams race to meet the demand for cloud-native applications, developer experience and development services, distributed infrastructure operations, and rich ecosystem partnerships and integrations will dictate which platform providers will lead the pack. This PDF is only licensed for individual use when downloaded from forrester.com or reprints.forrester.com. All other distribution prohibited. FORRESTER.COM FOR INFRASTRUCTURE & OPERATIONS PROFESSIONALS The Forrester Wave™: Multicloud Container Development Platforms, Q3 2020 The Eight Providers
    [Show full text]
  • Ensure the Secure, Reliable, Delivery of Citrix Workspace to Any User
    White Paper Ensure the Secure, Reliable, Delivery of Citrix Workspace to Any User, Over Any Network Citrix ADC improves the Citrix Virtual Apps and Desktops experience for both end users and IT administrators Citrix | Ensure the Secure, Reliable Delivery of Citrix Workspace 2 Application and desktop application traffic. Without end-to-end visibility, it is extremely difficult to troubleshoot performance virtualization have dramatically problems. Proponents of application and desktop improved end-user productivity virtualization need to overcome these challenges in order to protect and extend the gains they have and data security. They have made in simplifying the end-user experience, also simplified the work of IT increasing the reliability of application performance, strengthening security, and improving management administrators and decreased of IT resources. overall computing costs. Yet the Citrix ADC specifically addresses these challenges. flexibility businesses need to Citrix ADC brings together the capabilities of application ensure they are competitive means delivery controllers (ADCs) and secure remote access (in the case of this white paper, for access IT must now consider: to Citrix Workspace powered by Citrix Virtual Apps and Desktops). The goal of Citrix ADC is to ensure • How to ensure the security posture is extended to compliance to the endpoint by enabling the secure, the endpoint in order to maintain compliance. IT reliable delivery of applications and virtual desktops to must manage secure access across all the different any user, anywhere. This white paper provides a brief use cases while deploying applications securely to overview of Citrix ADC and how it addresses these users on any device, over any network.
    [Show full text]
  • FIPS 140-2 Non-Proprietary Security Policy
    Citrix Systems, Inc. Citrix ADC VPX Software Version: 12.1.51.152 FIPS 140-2 Non-Proprietary Security Policy FIPS Security Level: 1 Document Version: 0.12 Prepared for: Prepared by: Citrix Systems, Inc. Corsec Security, Inc. 851 Cypress Creek Road 13921 Park Center Road, Suite 460 Fort Lauderdale, FL 33309 Herndon, VA 20171 United States of America United States of America Phone: +1 954 267 3000 Phone: +1 703 267 6050 www.citrix.com www.corsec.com FIPS 140-2 Non-Proprietary Security Policy, Version 0.12 September 30, 2020 Table of Contents 1. Introduction ..........................................................................................................................................4 1.1 Purpose .....................................................................................................................................................4 1.2 References ................................................................................................................................................4 1.3 Document Organization ...........................................................................................................................4 2. Citrix ADC VPX .......................................................................................................................................5 2.1 Overview ...................................................................................................................................................5 2.2 Module Specification ................................................................................................................................6
    [Show full text]