Cloud Computing Köln

Cloud modernization: Cultural and workplace adoption

Genuine digital transformation requires cloud modernization strategies that involve and affect people, processes and technology. In part one of this two-part series, I focused on cloud-based technologies that enable organizations to modernize infrastructures, platforms and applications.
This time around, I’ll examine the people aspect of cloud modernization and include some thoughts on process. I’ll cover:

Why it’s necessary to refresh and reskill your workforce
Why organizational restructuring is important
How to reengineer people and process
How to measure employee value in an era of transformation

The most effective digital modernization initiatives are holistic efforts that coordinate people, processes and technologies to improve business outcomes.
Refresh and reskill the workforce
Running IT operations in a cloud environment requires a different set of skills and knowledge than a traditional application development world. This is because application and platform architectures are so dissimilar. Therefore, different engineering practices and design patterns will become relevant.
Consider the microservices architecture, in which a single application is made up of many small, loosely coupled and independently scalable and deployable components. If one service goes down, the same service can pop up 10 different times. Or what about 12-factor application methodologies for building cloud-based services — developers and designers need to understand these and ingrain them into the design.
Concepts like these weren’t that relevant in traditional application development. Understanding of a traditional infrastructure doesn’t necessarily translate to a cloud environment. For a cloud modernization initiative to succeed, enterprises must teach employees how to design, test and deploy native cloud-ready applications — or hire new employees who can.
The cloud model also calls for consuming more and more best-of-breed software-as-a-service (SaaS) capabilities provided and managed by third-party vendors. This also exacerbates the notion of consolidated service-level agreements and integrated service management skills in a multicloud environment. These are very hard-to-find skills.
Restructure the organization
The notion of development best practices and operational excellence isn’t new. So why are concepts like DevSecOps so highly talked about now? The answer has more to do with organization than technology.
Five years from now, we may be laughing at the technology we have today. But whatever technology we’re using, we’ll want development and operations teams to be tightly integrated. In the microservices architecture, you own the end-to-end lifecycle of the service or domain. That’s very different from how traditional infrastructure IT teams work.
Cloud computing is increasingly managed by self-sustaining independent teams, each with their own specialties and organized around billing, claims or similar domains. There’s a squad lead. There’s a business analyst. There are a few designers and a few developers. There are probably some testers. There’s a DevOps engineer, or maybe a site reliability engineer (SRE). Each is part of the total squad — and squads can be replicated. As the industry matures, it’ll continue to trend toward that model.
Another trend in organizational restructuring is the growing adoption of centers for enablement. Centers of excellence or competencies are nothing new; centers for enablement are more hands-on and dynamic, focusing not on process but on performance and reuse of assets.
Adopt new rules and process reengineering
Site reliability engineering is all about building highly resilient applications and platforms. If a service suddenly goes down, other services remain working because they are independent. So, if a feature on an airline app stops working, users can still look at current flights or their airline bonus points because the problem is isolated.
The widespread use of automation and robotics has spawned a discipline called AIOps, which is revolutionizing service management. Enterprises initially took a reactive approach to monitoring systems and handling events. With new technology available, enterprises can be proactive about monitoring and management. AIOps allows organizations to be prescriptive: They can know what your systems and instrumentation will look like six months from now because the AI perceives trends and patterns.
Measure people and performance
In a traditional IT development, developers are evaluated using metrics such as the number of defects in a kilo line of code (KLOC). But is this metric relevant in cloud-based development? Wouldn’t a more valuable metric be the amount of time from ideation to deployment? And what about the percentage of a developer’s time spent on building automation, or the number of reusable IT assets produced by individuals or squads? The idea is to use metrics that truly measure business value.
In a nirvana stage, mean time to recover a system should trend closely to time taken from ideation to deployment. This means the method and processes used for new requirements are exactly the same as those being used for bug fixes or other types of defects. They’re all treated as items in a prioritized list and will be consumed, built, packaged and deployed in exactly the same way.
Half measures simply won’t cut it. Digital modernization requires a cloud-first and automation-first strategy that emphasizes coordination between people, processes and technologies.
Learn more about IBM organizational change management services, as well as how guidance, migration, modernization, cloud-native application development and managed services from IBM professionals can help your journey to cloud.
The post Cloud modernization: Cultural and workplace adoption appeared first on Cloud computing news.
Quelle: Thoughts on Cloud

Microservices-Based Application Delivery with Citrix and Red Hat OpenShift

This is a guest post by Pushkar Patil. He is a Principal Product Manager, at Citrix Systems, Inc.
 
Citrix is thrilled to have recently achieved Red Hat OpenShift Operator Certification (Press Release). This new integration simplifies the deployment and control of the Citrix Application Delivery Controller (ADC) to a few clicks through an easy-to-use Operator.
Before we dive into how you can use Citrix Operators to speed up implementation and control in OpenShift environments, let me cover the benefits of using the Citrix Cloud Native Stack and how it solves the challenges of integrating ingress in Kubernetes.
Benefits of Citrix Cloud Native Stack
 
A purpose built software stack addressing the needs of various stakeholders like Developers, DevOps, DevSecOPs, SREs and Cluster Admin. The picture below shows the components of the stacks.

Citrix ADC is a feature-rich, application delivery controller that enhances the delivery and security of your microservices applications. Some of the key benefits include:
Production Grade Ingress 
Citrix ADC is proven to work at scale, providing features like advanced load balancing, TLS termination, L3-L7 protocol optimizations, and redundancy solutions to the internet’s largest web properties and thousands of enterprises.
Flexible
Citrix ADC support architecture flexibility – Citrix has a complete array of ADC form factors for every environment (physical, virtual, containerized, bare metal and cloud) for inside and outside your cluster. 
Agile
Better Developer experience – Citrix ADC uses CRDs to deliver features like Content Rewrite/Responder and now uses operators to improve lifecycle management of Citrix Ingress Controller and Citrix ADC CPX
Monitoring 
Citrix Cloud Native Stack readily integrates with open source tools like Prometheus, Grafana, Kibana and many more.
Deep visibility and Troubleshooting 
Citrix ADM with Service Graphs provides actionable insight into the health and performance of applications and offers proactive troubleshooting for any issues.
Automated
Citrix ADC provides a REST API (NITRO) which integrates with an automation framework, e.g. Ansible, Puppet, Chef etc. This allows application development and DevOps teams to enable allocation of new ADC services, on-demand as part of their application deployment workflow. The teams can develop application templates for advanced ADC functionality with simplified configuration specific to an individual application.
Elastic
Pooled Capacity provides the ability to share ADC capacity across all Citrix ADC form factors across a datacenter and/or cloud, to ease migration of workloads
 
Challenges running Ingress in OpenShift:
 
Kubernetes as an  application development and deployment platform is excellent, but getting requests into and out of the cluster does present challenges. Shortcomings include:
Migrating legacy applications to OpenShift
Previously, applications were written to use the TCP/UDP networking protocols. Kubernetes ingress objects don’t support TCP, TCP-SSL or UDP 
Failover handling
Because the ingress is the access point for traffic to the cluster,  it should continue to serve customers without any downtime if a disaster results in the cluster being unavailable.
Consistent ingress on premises and in the cloud
Microservices can be deployed on-prem and on public cloud and having inconsistent ingress mechanisms across locations adds complexity to operations.              
External access from/to outside OpenShift cluster
The ability to seamlessly integrate into existing networking fabrics without additional hops or network re-architecture increases efficiency
Security configuration
Ability to support security with SSL, mTLS is of great significance when it comes to Ingress solutions. 
Rolling upgrades
To upgrade without disruption is vital for production environments
How Citrix ADC makes OpenShift ingress easier to implement
Citrix Operators are a secret sauce which enable automation and lifecycle management of Citrix ADC and Citrix Ingress Solution for OpenShift clusters.  It wraps the logic for deploying and operating a Citrix ADC operations using Kubernetes construct. More specifically, Citrix Operators directly address the challenges of ingress within Kubernetes. 
Citrix Operators enable:

Deployment of the Citrix ADC and Ingress controller quickly and easily, for serving micro-services applications, including support for TCP/UDP protocols along with HTTP/HTTPS.
Citrix ADC to scale elastically and handle fail-over events without disruption.
Deployment of the Citrix Cloud Native Stack on any OpenShift Platform (OpenShift products) in any environment to bring a consistent approach to ingress.
Automation of security configuration with certificate and key management using Let’s Encrypt, or any other cert and key management application. 
Deployment in production OpenShift environments because it is tested and supported through Red Hat and Citrix. 
Citrix ADC and Ingress Controller to do software update automatically without disruption to the traffic. 

 
How do I use the Citrix operators?
Here we go through steps to use OpenShift Citrix Ingress Operator to configure Citrix ADC VPX in virtual machine form factor and resides outside the cluster. 
The rest of this blog describes the features of Citrix Operators that can be used to deploy and operate Citrix ADC in cloud-native environments.
Citrix Operator installation for Red Hat OpenShift overview:
There are 4 common ingress deployment models which customers commonly use with the Citrix Stack:
Two-Tier ingress – A CPX is deployed in a cluster behind the Citrix appliance to act as a DevOps friendly abstraction layer. This deployment needs CIC and CPX operator. 
Unified Ingress – The Citrix appliance is outside the cluster serving micro-services. This deployment would just need CIC operator.
Service-Mesh Lite – Provision a CPX instance(s) through which all microservices will communicate and one can have granular traffic management between your apps. This deployment needs both CIC and CPX operator.
Service Mesh – Citrix ADC can be injected as sidecar proxy to your applications and as a gateway to service mesh cluster.  This is not currently covered with Operators. We will be creating an operator in the future for this architecture.

CIC Operator
CPX Operator

Single Tier
Yes
No

Dual Tier
Yes
Yes

ServiceMesh lite
Yes
Yes

ServiceMesh
No
No

 
To learn more about the pros and cons of these deployment choice watch this CNCF webinar https://www.youtube.com/watch?v=OhWYoYAHukA
Here are the steps for using Unified Ingress deployment. There is a video that cover 2-tier ingress at the end of this blogs.
Steps 
Prerequisites

Access to the OpenShift Container Platform web console.

Procedure

Log in to the OpenShift Container Platform web console.
Navigate to Catalog → OperatorHub.
Type Citrix into the filter box to locate the Citrix Operator.
Click the Citrix Operator to display information about the Operator.
Click Install.
On the Create Operator Subscription page, select All namespaces on the cluster (default). This installs the Operator in the default openshift-operators project and makes the Operator available to all projects in the cluster.
Select the alpha Update Channel.
Select the Automatic Approval Strategy.
Click Subscribe.
The Subscription Overview page displays the Citrix Operator’s installation progress.

 
Once install is complete
Go to a project where you want to host CIC

Navigate to Installed Operators
Click on installed Citrix Ingress Controller  
In the Overview tab -> Create New
Edit nsIP field to point to Citrix ADC and update the license field to “yes”
Click create
Navigate to Workload -> Deployment and find the deployment of CIC
Verify the CIC pod is running and is connects to Citrix ADC upstream

 
Exposing Application:

Create service of application: Navigate to Networking > Services > Create Service
Create ingress for apache application: Navigate to Networking > Ingress > Create Ingress
Update VIP of Citrix ADC in the ingress configuration and apply

 
Get started by viewing this Technical Video to deploy 2-tier architecture using Operators: https://youtu.be/TqSJ6z7wIw0 

The post Microservices-Based Application Delivery with Citrix and Red Hat OpenShift appeared first on Red Hat OpenShift Blog.
Quelle: OpenShift