Contents of this page is copied directly from IBM blog sites to make it Kindle friendly. Some styles & sections from these pages are removed to render this properly in 'Article Mode' of Kindle e-Reader browser. All the contents of this page is property of IBM.

Page 1|Page 2|Page 3|Page 4

A Global Replication Service Solution Using IBM Power Virtual Server Cloud

5 min read

By:

Val Besong, Senior Product Marketer
 Chhavi Agarwal, Software Developer
 Imranuddin Kazi, STSM, Chief Architect - IBM PowerVC
 Anu Jalan, Senior Developer, Power Cloud IaaS Development

The Global Replication Service reflects IBM’s commitment to enabling business continuity planning, operational excellence and cost optimization with IBM Power Systems Virtual Server.

Data replication is key to business resiliency because simply put, data drives decision-making. Data informs and feeds into mission-critical processes, analytics, systems and, ultimately, business insights. Organizations must guarantee that it is constantly available and accessible to users in near real-time. As enterprises develop across geographies and platforms, replication enables them to scale in tandem with their expanding data requirements while maintaining performance.

Solution overview

IBM Power Systems clients run mission-critical workloads. To guarantee business continuity in uncertain conditions, a secure, highly available and disaster-recovery solution is necessary. Global Replication is a valuable feature for high availability and disaster recovery because it keeps your data offsite and away from the premises. If the primary instance is destroyed by a catastrophic incident—such as a fire, storm, flood or other natural disaster—your secondary data instance will be secure off-premises, allowing you to retrieve data. Data replication off-premises is far less expensive than duplicating and keeping data in your data centre.

IBM Power Systems Virtual Server now brings a Global Replication solution that provides the replication capability to your workloads by maintaining the benchmarks for Recovery Time Objective (RTO) and Recovery Point Objective (RPO):

Global Replication Service (GRS) is based on well-known, industry-standard IBM Storwize Global Mirror Change Volume Asynchronous replication technology. Global Replication Service on IBM Power Virtual Server exposes cloud the application programming interface (API)/command line interface (CLI) to create and manage replication enabled volumes.

The benefits of Global Replication on Power Virtual Server include the following:

  • Maintain a consistent and recoverable copy of the data at the remote site, created with minimal impact to applications at your local site.
  • Efficiently synchronize the local and remote sites with support for failover and failback modes, helping to reduce the time that is required to switch back to the local site after a planned or unplanned outage.
  • Replicate more data in less time to remote locations.
  • Maintain redundant data centres in distant geographies for rapid recovery from disasters.
  • Eliminate costly dedicated networks for replication and avoid bandwidth upgrades.

The feature is currently enabled in two data centres: DAL12 and WDC06:

IBM also provides the automation toolkit for GRS.

This tutorial focuses on two ways to use the new GRS API/CLI to build the disaster recovery solution:

  • Setting up replication from scratch
  • Setting up replication using existing volumes
Set up for Global Replication Services

The data centres for IBM Power Virtual Server are set up to have all the required configuration needed to offer replication capabilities. Supported storage controllers Tier1/Tier3 will be pre-configured to use Global Mirror Change Volume (GMCV) replications. Global Replication Services (GRS) provide the replication at the storage level by making use of IBM Storwize GMCV asynchronous replication technology. In this case, the first initial sync copies the entire data from master to auxiliary; going forward, only the delta changes are synchronized with the periodic interval of 500sec. This means the maximum RPO will be around 15 minutes.

Upon every creation of replicated volumes, four copies of volumes are created across two sites:

  1. Master volume on site1.
  2. Master change volume on site1 to store the delta changes.
  3. Auxiliary volume on site2.
  4. Auxiliary change volume on site2 to update the delta changes.

The solution uses a remote copy consistency group to ensure that the data spread across multiple volumes is consistent while it is copied across the remote site. Also, it helps to switch the replication direction is there is a planned and unplanned disaster. GRS API/CLIs can be used to create and manage replicated volumes and consistency groups.

IBM Power Virtual Server has DAL12/WDC06 data centres enabled to use Global Replication Services APIs. This means that if you are using DAL12 as a primary site, you will have auxiliary volumes created on WDC06. Similarly, if you are using WDC06 as a primary site, you will have auxiliary volumes created on DAL12. The site where volumes are created or enabled for replication is the primary site.

Once we have the volumes replicated at both primary and secondary steps, we can use the steps outlined in the section below on disaster recovery workflow to bring up the standby VM using the replicated volumes.

Disaster recovery workflow

As an example, let’s say we have an AIX VM running an Oracle DB application workload and the DAL12 data centre serving as the primary site, and we need to enable the global replication for the data volumes to recover the Oracle database:

Below are the steps to enable the replication of your application workload running on the primary site and make it ready to trigger failover/failback:

  • Create/enable the volume replication (it will create replicated volumes on both sites).
  • Create the volume group (this will create the replicated consistency group in the storage backend).
  • Update the volume group. Add the replication-enabled volumes to the volume group.
  • Switch to the secondary site.
  • Onboard auxiliary volumes. Now aux volumes and volume groups will be visible to site2.
  • Provision standby VM and attach aux volumes.
  • VM is ready for failover/failback.
Failover/failback

In case of disaster (i.e., primary site failure or storage failure), you will lose access to the storage volumes, and they will be marked as ERROR. The replication relationship will be disconnected, and consistency group will move to “consistent-disconnected.” The volume group primary role will be assigned as blank.

In this situation, no new replication operations are allowed, as replication is broken. You can only access existing workloads by powering on the standby VM and auxiliary replication volumes from the secondary site after giving them read access. This is accomplished by following the steps below:

  • Access auxiliary volumes on primary site failure.
  • Failover or switch volume group role to secondary.
  • Failback to primary site. 
Disabling the replication

Disabling the replication means deleting the auxiliary volume from the remote site. Before disabling the replication, make sure that it is not associated with any group. Since there are two sites, we should follow the below procedure for disabling the replication.

  • Remove the volumes from the volume-group from the primary site.
  • Disable the replication of a volume.
  • Remove the volumes from the volume-group from the secondary site.
  • Delete the auxiliary volume from secondary site.
Bill and charging

You are charged from the location where you create a replication-enabled volume. No charges for the auxiliary volume from the remote site.

The volume of size X GB is charged based on following two components:

  • The master volume is charged 2x size based on its Tier under the existing part numbers for Tier 1 and Tier 3.
  • Replication capability cost is charged $Y/GB under a new part number "GLOBAL_REPLICATION_STORAGE_GIGABYTE_HOURS" that is independent of volume tier.

Upon a site failure due to a catastrophe, metering is not available from the failed site. The auxiliary volumes are charged from remote site for its 2x size based on its tier. There is no replication capability cost for any replication-enabled volume.

Conclusion

The introduction of the Global Replication Service reflects our commitment to enabling business continuity planning, data centre efficiency, operational excellence and cost optimization with IBM Power Systems Virtual Server.

Business continuity planning keeps your business running with reliable failover solutions, including backup, high availability and disaster recovery. Data centre optimization accelerates time to value, business expansion and worldwide growth by optimizing your data centre. Operational excellence and cost optimization reduce operational costs, improve service and response times, and ensure off-hours coverage.

References

Please refer to the following resources for additional information:

Val Besong

Senior Product Marketer

 Chhavi Agarwal

Software Developer

 Imranuddin Kazi

STSM, Chief Architect - IBM PowerVC

 Anu Jalan

Senior Developer, Power Cloud IaaS Development

=======================

Managing Worker Nodes with Terraform Cloud

1 min read

By:

Attila László Tábori, Software Developer
 Zoltán Illés, Software Developer

Learn how to migrate your worker pools to a new operating system like Ubuntu 20.

In the following example scenarios, you will learn how to use Terraform to migrate your worker nodes to a new Ubuntu version (e.g., from Ubuntu 18 to Ubuntu 20) and change your default worker pool to use different worker nodes.

Migrating to a new Ubuntu version with Terraform

To migrate your worker nodes to a new Ubuntu version, you must first provision a worker pool that uses a newer Ubuntu version. Then, you can add worker nodes to the new pool and finally remove the original worker pool.

  1. We begin with the following example cluster configuration. This cluster contains an Ubuntu 18 worker pool called oldpool: 
    resource "ibm_container_vpc_cluster" "cluster" {
...
}

resource "ibm_container_vpc_worker_pool" "oldpool" {
cluster          = ibm_container_vpc_cluster.cluster.id
worker_pool_name = "ubuntu18pool"
flavor           = var.flavor
vpc_id           = data.ibm_is_vpc.vpc.id
worker_count     = var.worker_count
...
operating_system = "UBUNTU_18_64"
}
  2. Next, add a worker pool resource for your Ubuntu 20 workers. In the following example, a temporary new_worker_count variable is introduced to control the migration: 
        resource "ibm_container_vpc_worker_pool" "oldpool" {
count = var.worker_count - var.new_worker_count == 0 ? 0 : 1

cluster          = ibm_container_vpc_cluster.cluster.id
worker_pool_name = "ubuntu18pool"
flavor           = var.flavor
vpc_id           = data.ibm_is_vpc.vpc.id
worker_count     = var.worker_count - var.new_worker_count
...
operating_system = "UBUNTU_18_64"
}


resource "ibm_container_vpc_worker_pool" "newpool" {
count = var.new_worker_count == 0 ? 0 : 1

cluster          = ibm_container_vpc_cluster.cluster.id
worker_pool_name = "ubuntu20pool"
flavor           = var.flavor
vpc_id           = data.ibm_is_vpc.vpc.id
worker_count     = var.new_worker_count
...
operating_system = "UBUNTU_20_64"
}
  3. Start the migration by gradually increasing the new_worker_count variable. In the following example, the new_worker_count is set to 1: 
    terraform plan -var new_worker_count=1
    terraform apply -var new_worker_count=1
  4. Review the following actions that are performed when you change the worker count: 
        # ibm_container_vpc_worker_pool.newpool[0] will be created
+ resource "ibm_container_vpc_worker_pool" "newpool" {
+ cluster                 = "<clusterid>"
+ flavor                  = "bx2.4x16"
+ id                      = (known after apply)
+ labels                  = (known after apply)
+ operating_system        = "UBUNTU_20_64"
+ resource_controller_url = (known after apply)
+ resource_group_id       = (known after apply)
+ secondary_storage       = (known after apply)
+ vpc_id                  = "<vpcid>"
+ worker_count            = 1
+ worker_pool_id          = (known after apply)
+ worker_pool_name        = "ubuntu20pool"

+ zones {
+ name      = "<zone_name>"
+ subnet_id = "<subnet_id>"
}
}

# ibm_container_vpc_worker_pool.oldpool[0] will be updated in-place
~ resource "ibm_container_vpc_worker_pool" "oldpool" {
id                      = "<oldpoolid>"
~ worker_count            = 3 -> 2
# (9 unchanged attributes hidden)

# (1 unchanged block hidden)
}

Plan: 1 to add, 1 to change, 0 to destroy.
  5. Verify that the new worker pool and the new worker(s) have been created and the old worker pool is scaled down.
  6. Finish the migration by setting the new worker pool's worker count to the same value as the old one before the migration. As a best practice, always review your changes using the terraform plan command: 
    terraform plan -var new_worker_count=3
    terraform apply -var new_worker_count=3
    ...

Terraform will perform the following actions:

# ibm_container_vpc_worker_pool.newpool[0] will be updated in-place
~ resource "ibm_container_vpc_worker_pool" "newpool" {
id                      = "<newpoolid>"
~ worker_count            = 2 -> 3
# (9 unchanged attributes hidden)

# (1 unchanged block hidden)
}

# ibm_container_vpc_worker_pool.oldpool[0] will be destroyed
- resource "ibm_container_vpc_worker_pool" "oldpool" {
- cluster                 = "<clusterid>" -> null
...
}

Plan: 0 to add, 1 to change, 1 to destroy.
  7. Verify that the old worker pool has been deleted.
  8. Remove the old worker pool resource and the temporary changes from the Terraform script: 
    resource "ibm_container_vpc_cluster" "cluster" {
...
}

resource "ibm_container_vpc_worker_pool" "newpool" {
cluster          = ibm_container_vpc_cluster.cluster.id
worker_pool_name = "ubuntu20pool"
flavor           = var.flavor
vpc_id           = data.ibm_is_vpc.vpc.id
worker_count     = var.worker_count
...
operating_system = "UBUNTU_20_64"
}
Changing the default worker pool

Begin by defining the worker pool as its own resource.

While you are changing the default worker pool, a backup worker pool is required if the change includes a `ForceNew` operation. If you update the default worker pool without not having a separate worker pool with existing workers already added, your cluster will stop working until the worker replacement is finished.

  1. Create the resource similar to the following example: 
    resource "ibm_container_vpc_cluster" "cluster" {
...
}


resource "ibm_container_vpc_worker_pool" "default" {
cluster           = ibm_container_vpc_cluster.cluster.id
flavor            = <flavor>
vpc_id            = <vpc_id>
worker_count      = 1
worker_pool_name  = "default"
operating_system  = "UBUNTU_18_64"
...
}
  2. Import the worker pool: 
    terraform import ibm_container_vpc_worker_pool.default <cluster_id/workerpool_id>
  3. Add the following lifecycle options to ibm_container_vpc_cluster.cluster so changes made by the ibm_container_vpc_worker_pool.default won't trigger new updates and won't trigger ForceNew. Note that the events that trigger ForceNew might change. Always run terraform plan and review the changes before applying them: 
        resource "ibm_container_vpc_cluster" "cluster" {
...
lifecycle {
ignore_changes = [
flavor, operating_system, host_pool_id, secondary_storage, worker_count
]
}
}
  4. In this example, we modify the operating system of the default worker pool and set the worker count to two. Note that updating the worker count would normally resize the worker pool, but since we changed the operating system, a new worker pool is created. Making this change on a cluster resource would trigger the ForceNew option on the cluster itself and would result in a new cluster being created. However, since we defined the worker pool resource separately, new workers are created instead: 
    resource "ibm_container_vpc_worker_pool" "default" {
cluster           = ibm_container_vpc_cluster.cluster.id
flavor            = <flavor>
vpc_id            = <vpc_id>
worker_count      = 2
worker_pool_name  = "default"
operating_system  = "UBUNTU_20_64"
...
}
  5. Run terraform plan to review your changes: 
    terraform plan
  6. Apply your changes to replace your Ubuntu 18 worker nodes with Ubuntu 20 worker nodes: 
    terraform apply
  7. Verify your changes by listing your worker nodes: 
    ibmcloud ks worker ls -c <cluster_id>
  8. After updating the default worker pool, pull your changes into the current state and remove the lifecycle operations you added earlier: 
    terraform state pull ibm_container_vpc_cluster.cluster
  9. Then, remove the ibm_container_vpc_worker_pool.default resource so it is no longer managed: 
    terraform state rm ibm_container_vpc_worker_pool.default
  10. Remove the lifecycle options that you added earlier from cluster resource.
Conclusion

In the previous examples you learned how to do the following.

  • Migrate your worker pools to a new operating system, such as Ubuntu 20.
  • Make changes to the default worker pool while using a backup pool to prevent downtime.

For more information about the IBM Cloud provider plug-in for Terraform, see the Terraform registry documentation.

For more information about IBM Cloud Kubernetes Service, see the docs.

For more information about Red Hat OpenShift on IBM Cloud, see the docs.

 

Attila László Tábori

Software Developer

 Zoltán Illés

Software Developer

=======================

Six Questions for Banks to Ask Cloud Providers Cloud

1 min read

By:

Rachel Zarrell, Content Strategist

Finding the ideal cloud solution for financial industries.

There’s no doubt that you’ve been told about the flexibility and efficiency of having a public cloud environment for your workloads. However, if you’re in the financial industry, there is often unease around putting data and assets in the cloud. While banks may want the advantages of a hybrid cloud, they also need assurance they can protect their assets and maintain compliance with industry and regulatory requirements.

Can you avoid new risks by staying with your current system? Sure—if you don’t mind falling behind your competitors. While there are myriad benefits to on-prem, a hybrid environment can only enhance your ability to keep up with new business demands.  Plus, you get to tap into the new cloud tools that help you demonstrate regulatory compliance.

With most hyperscalers, you’re on the hook for your cybersecurity and meeting regulatory demands. Building these processes becomes the highest priority, and innovation gets put on the back burner. But what if you didn’t have to build security protocols into your cloud because they were baked right in? It’s possible for your cloud platform to help you maintain resiliency and spur innovation while enabling compliance and security. It starts with asking the right questions.

Critical questions to ask cloud providers on running regulated workloads in the cloud

Just a few quick questions can help you understand whether your cloud platform is attuned to the needs of your regulated workloads.

 Here are six we recommend starting with:

  1. What is the level of security and trust? Is there security and trust across the entire environment, with policies and controls that enable continuous compliance? Are the controls being continuously, automatically monitored and enforced?  
  2. How much flexibility is provided? Does the cloud platform provide flexibility to adjust quickly and easily when regulatory requirements change across industries and geographies? Can it scale up across new cloud locations and expand into new markets and still meet regulations? Is the security controls framework up to the industry standard?
  3. How much control is there? Do you retain complete control of data, encryption, security, intellectual property and mission-critical systems? Is your data so secure that even your provider can’t access it?
  4. Are hybrid environments available? Is there portability and consistency across private and public environments? Can you run both classic virtualized workloads and containerized applications side by side?
  5. Who are your ecosystem partners? Is there a supporting ecosystem that includes independent software vendors (ISVs) and SaaS providers for services you are looking for (e.g., disaster recovery and high availability)? Are the ISVs vetted by the cloud provider through a rigorous validation process and held to the same security standard as the cloud?
  6. How is governance decided? Who is driving the governance and change management? Are policy provisions made for continuous updates relative to changing regulatory requirements?
The answer: IBM Cloud for Financial Services

These six questions can help guide you to the right cloud solution for your regulatory needs. If you’re looking for a flexible cloud with high levels of security controls and a zero-trust policy that enables hybrid environments and a vetted ecosystem of vendors, we have the answer.

To help banks host mission-critical workloads while adhering to their security and compliance regulations, we built the IBM Cloud for Financial Services. This solution makes it so that banks can deploy mission-critical workloads with confidence while addressing up-to-date regulatory compliance, security and data sovereignty.

 IBM Cloud for Financial Services was designed in collaboration with some of the world’s largest banks to streamline operations, increase efficiencies, reduce risk, decrease compliance costs and accelerate revenue growth. It offers the flexibility and efficiency of public cloud, but with the added security measures that regulated industries need. Among the highlights are IBM’s fourth-generation confidential computing capabilities and “Keep Your Own Key” encryption, in which partners and their customers can retain control of their data and transact in a highly secured environment. Additionally, our built-in security and compliance controls are engineered to help partners and customers accelerate innovation, unlock new revenue opportunities, and decrease the cost of compliance while fostering a growing ecosystem.

To learn more on how financial institutions can drive innovation and growth with a focus on security, resiliency and compliance, visit our IBM Cloud for Financial Services page.

Rachel Zarrell

Content Strategist

=======================

How the IBM CIO Organization Uses IBM Edge Application Manager to Enable Global Video Streaming Cloud

2 min read

By:

Rob High, IBM Fellow, VP & CTO, Networking & Edge Computing
 Hakan Sonmez, Product Strategy Leader

Learn how the IBM CIO team reduced the time spent on deploying ECDN endpoint software to local edge servers from days to hours with IBM Edge Application Manager (IEAM).

The IBM CIO organization addresses the IT needs of more than 200,000 IBM employees distributed over more than 150 countries. One of the IT use cases addressed by the CIO team is global video caching and streaming to IBM employees.

Tens of thousands of IBM employees in IBM offices around the globe watch videos on-demand every day posted on the IBM intranet. These videos are intended for internal audiences only, and therefore cannot be posted on a publicly accessible video streaming platform, so the IBM CIO team uses IBM Watson Video platform to host and stream these videos.

Streaming these videos each time from their original storage location in a data center in the United States to international locations is inefficient and costly due to internet link usage costs. Therefore, the video content is cached in 40+ local IBM offices and data centers around the globe. To cache this video content, each local edge server should be provisioned with the IBM Watson Media video platform’s Enterprise Content Delivery Network (ECDN) endpoint software.

Installing ECDN software manually to edge servers is a time-consuming process. Moreover, it is difficult to monitor and manage lifecycle of the ECDN workloads after installation. There is no single pane of glass to monitor the edge workloads. Manual software upgrades through scripts are time consuming.

IBM Edge Application Manager: Solutions and benefits

The IBM CIO organization has started using IBM Edge Application Manager (IEAM) software to install ECDN endpoints to the local servers around the globe. Installing ECDN software and provisioning new local servers takes much less time and manual effort when using IEAM.

Additionally, with IEAM, it is much easier to monitor the performance of ECDN software and do batch upgrades of the software.

Through using IEAM, the IBM CIO team has reduced the time spent on deploying ECDN endpoint software to local edge servers from days to hours. Moreover, the CIO team has also reduced costs by moving some of the operations in-house; previously, they worked with an external service provider to deploy endpoint software to edge servers.

More about IEAM

IEAM is a modern edge compute management and orchestration solution that helps organizations to deploy and manage the lifecycle of their containerized edge workloads in a simple, secure and scalable way. Global video streaming is only one of the use cases that can be addressed by IEAM. IEAM addresses numerous different edge computing use cases—including retail, manufacturing, transportation, banking and more—where workloads are widely distributed on heterogenous IT environments.

Learn about how the IBM Systems Manufacturing organization uses IEAM for the quality inspection when manufacturing state-of-the-art IBM Z series mainframe servers.

Learn more and get started Rob High

IBM Fellow, VP & CTO, Networking & Edge Computing

 Hakan Sonmez

Product Strategy Leader

=======================

Accelerating TensorFlow Inference on IBM z16 Artificial intelligence Cloud

3 min read

By:

Elpida Tzortzatos, IBM Fellow - CTO AI for zSystems and z/OS

How to leverage the IBM-zDNN-Plugin for TensorFlow.

AI brings incredibly transformative capabilities that enterprise clients are interested in leveraging. The ability to get new insights out of their data and applications represents a massive opportunity.

However, artificial intelligence (AI) is also a very complex and continuously developing space. With the exciting opportunities comes the need to invest resources to develop skills on the latest technologies and techniques that are in use in the industry. At its core, AI software is driven by a rich and diverse open-source ecosystem that supports multiple phases of the model lifecycle. This includes the ability to provide highly optimized training and inference capabilities that can accelerate time to value.

As we’ve worked with enterprise clients, it’s become clear that they recognize and embrace the use of open source in their AI projects and have developed advanced skills in popular frameworks like TensorFlow. To enable our clients to leverage these skills in IBM Z and IBM LinuxONE environments, IBM has focused on ensuring the most exciting and popular open-source AI is available on our systems with the same look and feel as other commonly used environments.

IBM is also focusing on ensuring models are seamlessly optimized for IBM Z and LinuxONE when deployed for production use. Through technologies like the Open Neural Network Exchange and the IBM Z Deep Learning Compiler, we provide simple portability and optimized inference that can leverage our newest capabilities, including the IBM z16 and LinuxONE on-chip AI accelerator (the IBM Integrated Accelerator for AI). 

Recently, we announced the general availability of new capabilities that enable TensorFlow to directly leverage the on-chip AI inference accelerator featured in IBM z16 and LinuxONE Emperor 4.

What is the IBM-zDNN-Plugin for TensorFlow?

TensorFlow is one of the most popular AI Frameworks in existence, with over 171K Github stars, 150K+ active contributors and over 87K Github forks. It is an open-source framework that supports the entire machine-learning lifecycle—from model development through deployment.  TensorFlow also has a robust extended ecosystem that can help augment your AI projects.

A few weeks back, we introduced the ibm-zdnn-plugin for TensorFlow. Not only have we optimized it to run on the IBM Z and LinuxONE platforms, but also to leverage IBM z16’s on-chip Integrated Accelerator for AI. As a result, customers can bring in TensorFlow models trained anywhere and seamlessly deploy them on the IBM Z platform closer to where their business-critical applications run.

This enables real-time inferencing across a massive number of transactions with negligible latency. As one example (of many), this can give customers the ability to screen all their credit card transactions for fraud (in real time) and react quickly enough to prevent the fraud from happening in the first place.

On IBM zSystems and LinuxONE, TensorFlow has the same ‘look and feel’ as any other platform. Users can continue to build and train their TensorFlow models on the platform of their choice (x86, Cloud or IBM zSystems). TensorFlow models trained on other platforms are portable to IBM Z and LinuxONE with ease.

We’re leveraging TensorFlow community’s PluggableDevice architecture and developed an IBM Z focused pluggable device that leverages IBM Integrated Accelerator for AI on IBM z16.

How to get started

You can begin leveraging the power of IBM-zDNN-Plugin for TensorFlow with very little effort. Getting started is a simple process:

  • Build and train the TensorFlow model using the platform of your choice.
  • Install TensorFlow 2.9 and IBM z Deep Neural Network Library:
    • Container images with pre-built and pre-installed TensorFlow core 2.9 have been made available on the IBM Z and LinuxONE Container Registry.
    • Others can build and install TensorFlow from source by following the steps here.
  • Install IBM-zDNN-Plugin from The Python Package Index (PyPI).
  • On IBM z16 or LinuxONE Emperor 4 system, TensorFlow will transparently target the Integrated Accelerator for AI for several compute-intensive operations during inferencing with no changes necessary to TensorFlow models.

Our recent technical blog has further details and points to a simple example that you can leverage to guide you on getting started.

Useful resources Elpida Tzortzatos

IBM Fellow - CTO AI for zSystems and z/OS

=======================

Top 4 Reasons Why IBM Security QRadar EDR Is the EDR Solution for You Security

6 min read

By:

Pooja Parab, Brand and Content Strategist

As cyber attackers become adept at evading detection and encrypting organizations’ data quickly, EDR solutions like IBM Security QRadar EDR may help security teams spot “early warning signs.”

Navigating an evolving threat landscape has become difficult as attackers become faster and stealthier. According to the IBM Threat Intelligence Index 2023 report, the time to execute ransomware attacks dropped by 94% over the last few years; what once took months now takes attackers mere days. With attackers moving faster, organizations need to take a proactive approach.

The problem: Endpoint detection challenges in cybersecurity

A surge in remote work trends post-pandemic led to a rapid increase and interconnectivity of endpoints. This new-normal way of working brought on its own set of cybersecurity challenges. There has been an increase in advanced threat activity and a rise in the sheer volume of alerts that security teams need to investigate (which often turn out to be false positives, resulting in major alert fatigue).

Already overtaxed security teams are left with little to no time to respond. Therefore, securing your endpoints against advanced zero-day threats can be challenging without the right endpoint detection and response (EDR) tools to avoid costly business delays.

The fix: Amplifying your cybersecurity with EDR solutions

Security teams should up the ante by having a strong endpoint security solution to offer a swift and decisive comeback. Why endpoint security? Simple. Because endpoint protection ensures the threat is contained before the devices get infected or encrypted by ransomware. It also provides support during various stages of the incident response lifecycle and supercharges gaps left by traditional antivirus solutions with enhanced detection, visibility and control before widespread malware or ransomware damage occurs.

The need: Accelerating your response to threats and improving efficiency within the SOC teams

Quick endpoint detection and malware reporting can reduce the overall impact of an attack and ultimately save both time and expenses. To create effective response solutions to cyberattacks, defenders can use EDR tools to do the following:

  1. Leverage AI and security automation to speed response to threats.
  2. Improve efficiency within the Ops teams to save both time and expenses.
  3. Get high-fidelity alerts that help reduce analyst workloads.
  4. Gain deep visibility into all processes and applications running on all endpoint devices.

Sophisticated (yet easy-to-use) EDR solutions like IBM Security QRadar EDR can help with all these aspects. Let’s find out how.

1. Leverage AI and security automation to speed response to threats

IBM QRadar EDR leverages exceptional levels of automation using artificial intelligence (AI) and machine learning (ML) to secure endpoint threats—helping detect and remediate known and unknown threats or fileless attacks in near real-time.

Let’s see IBM QRadar EDR in action to learn more about its detection and automated response to malware.

IBM QRadar EDR dashboard

IBM QRadar EDR provides an alert overview of your endpoint ecosystem.

Unlike complicated dashboards, the IBM QRadar EDR dashboard is designed to offer a minimalist and simplified view for ease of use. The home screen always provides a high-level overview of alerts, showing the state of all your endpoint devices.

An alert is triggered

The behavioral tree triggers an alert on detecting any anomalies.

IBM QRadar EDR helps identify anomalous activities like ransomware behavior quickly. In the case of any behavioral anomalies, an alert is automatically triggered. The top left of the screen shows the severity of the alert (medium, in this case). The right side shows more information about the alert as to the cause for the trigger point of the alert, the endpoints involved and how the threat maps to the MITRE ATT&CK framework.

Investigating the alert

Security teams can quickly analyze if the threat is malicious or benign by clicking Alert details.

To speed up response, analysts can click on the alert details page to quickly analyze whether the threat is malicious or benign and determine if it’s a false positive. This helps reduce alert fatigue as analysts don’t waste their time and energy filtering through thousands of lines of event logs to try to identify the exact path of what went wrong.

Visual storyline is automatically created as an attack unfolds.

For every alert, a behavior tree that provides a full alert and attack visibility is created. This user-friendly visual storyline provides a chronological storyboard of the attack. For instance, which applications and behaviors triggered the alert, how the attack unfolds, etc. Security teams can easily view the breadth of the threat activity on a single screen, helping them take quick decisions.

Detailed behavioral analytics and full attack visibility

Full attack visibility ensures analysts understand the scope of the attack and respond accordingly.

Clicking on the circles in the behavioral tree functionality shows detailed information about the applications that were launched. While nothing may seem alarming at this point, certain attacks that are launched via signed applications can bypass antivirus or firewall software.

Simple behavior tree visualization for alert prioritization

Analysts can easily prioritize their search when looking for an alert.

To speed analysts’ investigation further, IBM QRadar EDR shows the threat activity through a simple behavior tree visualization with circles and hexagons. Circles denote applications and hexagons are behaviors. For each shape, there are different colors. Red denotes severe risk, orange for medium risk and yellow for low risk. These colors signify severity and help security teams prioritize their search when looking for an alert.

2. Improving efficiency within the operations teams with IBM QRadar EDR

Efficiency within the operations teams can be greatly improved through the ease and speed that EDR security tools like IBM QRadar EDR can remediate threats, terminate processes or isolate infected devices. IBM QRadar EDR also supports forensic analysis and reconstruction of the root cause of the attack. This helps Ops teams to remediate threats and regain business continuity quickly.

Remediating and isolating threats with IBM QRadar EDR

Quick view showing how many other endpoints were affected by the malicious activity.

Once a threat is analyzed and deemed malicious, the analyst can access containment controls to triage, respond and protect by creating a blocklist policy to prevent the threat from running on other endpoints.

Security teams can also view the number of compromised endpoints to find out if the threat was isolated or recurring. The threats can then be terminated, and infected endpoints can be completely isolated from the network no matter where the end-user is (e.g., Singapore, the U.S., the UK, Africa, etc.). If the endpoint is connected to the server, the malware can be terminated and blocklisted in real-time.

Preventing similar threats in the future

Analysts can create workflows to counteract similar threats.

IBM QRadar EDR allows you to create workflows to act against specific threats. That way, these plans can be triggered autonomously when a similar threat is detected in the future.

It also provides options to select any dropped executables, filesystem, or registry persistence and remove them. You can select the endpoints you’d like to isolate as part of this remediation plan and close the alert.

3. Get high-fidelity alerts that help reduce analyst workloads

IBM QRadar EDR can provide high-quality alerts and help reduce investigation time from minutes to seconds with threat intelligence and analysis scoring. Analysts can identify potential cyber threats with metadata-based analysis to expedite triage. Moreover, the threat-hunting capabilities of IBM QRadar EDR enable real-time, infrastructure-wide search for indicators of compromise (IOC), binaries and behaviors. 

Threat classification to help reduce false positives

Cyber Assistant learns from analyst decisions and helps reduce alert fatigue.

Once an alert is closed, it’s critical that the analyst classifies the threat as malicious or benign because Cyber Assistant—an AI-powered alert management system within the endpoint protection platform—continuously learns from analyst decisions.

It collects data and uses AI to constantly learn from threat patterns to assess similar threats. If the new threat shows a similar telemetry of above 85% or more, it utilizes its learned behaviors to make an assessment.

Cyber Assistant retains this intellectual capital to help reduce false positives. This means high-alert fidelity and lowering analysts’ workloads to reduce alert fatigue and improve efficiency within the security teams.

4. Gain deep visibility into all processes and applications running on all endpoint devices

Businesses need to have deep visibility into their entire endpoint estate—including laptops, desktops, IoT, mobile devices, tablets, etc.—to protect their assets and indicate the presence of attackers in the event of a cyberattack.

NanoOS—a lightweight agent that sits outside the operating systems in the hypervisor layer—is designed to be undetectable, making it invisible to attackers and malware because it cannot be altered, shut down, or replaced.

Security teams can also take advantage of NanoOS to invisibly track the attackers’ movements for as long as possible to understand their objectives until the security team shuts down access. Then, the IBM QRadar EDR security solution can be deployed to clean up compromised devices without downtime.

Conclusion

An effective endpoint security solution like IBM Security QRadar EDR can help cybersecurity teams identify weak spots. Endpoint detection and response (EDR) solutions aren’t the sole protection mechanism for threat detection, but they should still be the initial mechanism along with an extended detection and response (XDR) security solution to detect suspicious behavior.

IBM QRadar EDR offers easy integration with QRadar SIEM, empowering organizations with a more secure defense system that unifies protect, detect and response capabilities to improve IT security against advanced cyberattacks.

IBM QRadar EDR provides a 24x7 managed detection and response (MDR) service that acts as an extension of your security team to ensure the endpoint threat is contained and remediated as soon as it’s detected.

Next steps Explore more Pooja Parab

Brand and Content Strategist

=======================

Application-Centric Networking for the Modern Enterprise Era Cloud Networking

3 min read

By:

Murali Gandluru, VP, Product Strategy and GTM, Software Networking

The modern enterprise has applications and services that are distributed across on-prem, multicloud and intelligent edge environments.

By 2025, 75% of the enterprise data will be created and processed at the edge. The enterprise application users are themselves becoming mobile with the hybrid work paradigm gaining ground.

These drastically shifting needs of applications and users are not addressable with traditional models of networking, including traditional SDN solutions. This leads to increased pressure on the NetOps and CloudOps teams. Without the ability to provision networking for applications at a granular level, and with limited means to drive policy in a dynamic environment, NetOps teams are losing their ability to maintain granular control of the network and respond to the dynamic needs of the applications.

Understanding the obstacles in the way

The Enterprise Line of Business (LoB)’s DevOps teams are required to keep their applications performant and reliable to enable a superior experience for their customers and employees. This makes the connectivity paradigm across applications and services as important as the applications themselves. However, the NetOps teams are often involved late in the application development cycle, causing networking to be an after-thought.

Our customers have told us that delays in deployments are often caused by these three IT connectivity challenges:

  1. Multi-dimensional connectivity: Complex workflows between DevOps, NetOps and SecOps teams are causing delays in provisioning granular connectivity between applications and services, often taking weeks to complete the network provisioning.
  2. Network agility: DevOps teams demand the same level of agility that they are used to in the compute and storage domains. Network automation often is not at the same level of maturity as compute and storage and falls short of meeting the expectations.
  3. Lack of visibility caused by silos: The Ops teams often work in silos, and their performances metrics and SLAs are independent from each other. This leads to complex and long troubleshooting times when application performance degrades.
Are we ready for a DevOps friendly, application-centric connectivity?

By reconsidering connectivity from an application context, one can solve the above challenges and enable the DevOps teams to achieve their connectivity in a self-service fashion, under the overarching policy control of the NetOps and SecOps teams. With this approach, one can seamlessly integrate connectivity provisioning as an additional step in the CI/CD pipeline, enabling DevOps teams to imagine network as another cloud resource. This results in a simple, scalable, seamless and secure application-level connectivity across any environment—on-prem, edge or cloud.

This model also makes policy administration uniform across all facets of IT, thereby greatly simplifying the administration of policy and resulting in enhanced security.

Reimagining networks in the context of applications and integrating NetOps with DevOps and SecOps, results in significant benefits to the enterprise user, including the following:

  • Seamless auto-discovery across applications and infrastructure resources.  
  • Single centralized management and policy control with clear mapping between business context and underlying network constructs.
  • The ability to make the network “follow the application” when services move across locations.
  • Elimination of silos between different Ops teams.
  • “Built-in” zero-trust security architecture owing to the ability to operate and connect at an individual microservice level, drastically reducing the attack-surface.
  • Simplification of networks owing to the clear separation of application-level connectivity and security policies at the overlay, thereby resulting in a highly simplified underlay
Join the early access program

At IBM, we are committed to helping our customers solve some of networking’s biggest challenges. Explore the hybrid cloud topic and join the waitlist to learn how we can work together.

Murali Gandluru

VP, Product Strategy and GTM, Software Networking

=======================

Myths and Truths in Today’s Hybrid Cloud World Cloud

3 min read

By:

Kathryn Guarini, IBM Chief Information Officer

Exploring the crucial role of IBM zSystems in IBM’s hybrid cloud environment.

Sometimes peers in the industry talk about “getting off the mainframe” or question whether the enduring IBM zSystems platform continues to provide differentiated value to their businesses. Public clouds, edge solutions and distributed technologies all play an important role as part of a hybrid cloud environment. Nevertheless, IBM zSystems remains essential to many large-scale enterprise IT environments—and certainly to IBM’s own—as it delivers the performance, resilience, security, sustainability and efficiency required for business-critical workloads.

Here, I’ll dispel some myths and clarify the important role that IBM zSystems plays in IBM’s hybrid cloud environment today and for the future.

Myth: The mainframe is no longer core to IBM’s own enterprise IT portfolio or strategy

Truth: The IBM zSystems platform plays a central role in our hybrid cloud strategy, and at IBM, we are massive users of the platform today. This is not just because we manufacture and sell zSystems, but because it is simply the best platform for the job. We run nearly 600 applications with at least one component on IBM zSystems, including more than 65% of all financially significant applications. Critical quote-to-cash, finance and HR applications run on z/OS, z/VM and Linux on zSystems. These include IBM’s integrated enterprise resource planning (iERP) solution, our global credit system, our accounting information warehouse, our global logistics system and our common ledger system.

Myth: The mainframe is expensive

Truth: The total cost of ownership (TCO) of applications running on IBM zSystems can be lower than moving to other platforms given the high utilization, long lifetime and backward compatibility of the platform. Using a technology business management (TBM) approach, we are actively demonstrating that applications running on zSystems can have lower TCO, better performance and improved security in a modern operating environment. As many of our clients have also experienced, using existing capacity on IBM zSystems also helps reduce public cloud expense. Plus, we’re combining that with “intelligent workload placement,” moving containerized application workloads across architectures to optimize performance, sustainability and cost. This is the essence of a modern, efficient hybrid cloud.

Myth: Modern applications don’t run on the mainframe

Truth: Modern applications run on IBM zSystems securely, cost effectively and with energy efficiency. Red Hat OpenShift and Red Hat Enterprise Linux on IBM zSystems—together with continuous integration and continuous deployment (CI/CD) pipelines and Infrastructure as Code—make it an attractive and modern environment that leverages agile developer skill sets.

Myth: If “cloud” is the destination, we should move applications off the mainframe

Truth: No! As part of any hybrid cloud environment, application workloads need to be in the best place for the operating requirements that balance dimensions like sustainability, performance, agility, reliability and cost. Infrastructure as Code, transparent operating system patching with no application downtime, increased security, improved reliability and lower environmental impacts are just some areas where IBM zSystems excels. Add to this CI/CD pipelines for applications on IBM zSystems, and it looks a lot like what’s being done on other cloud architectures.

Myth: We need specialized and antiquated skills to use the mainframe

Truth: Modern tools reduce the need for specialized skills to support legacy technologies that are still used by some business applications. In fact, modern technologies and tools like Python, YAML, Java, Kubernetes and Ansible all run on IBM zSystems. Skills for these are needed across our team (and the industry) to ensure common development approaches fully leverage the power of IBM zSystems. These modern skills, combined with the industry-leading capabilities of the platform, allow for all the benefits expected of a key component of a modern hybrid cloud operating environment.

Myth: The mainframe is old

Truth: Do you consider a 2023 Ferrari old? Me neither. While a hallmark of the IBM mainframe is backward compatibility, the latest generation IBM z16—and IBM LinuxONE 4 for Linux-only environments—is packed with every latest innovation you can imagine. These include an embedded AI processor, pervasive encryption and quantum-safe cryptography. Today’s IBM zSystems have the performance, availability and security trusted by banks, insurance companies, airline reservation systems and retailers worldwide for their proven transaction processing capability and resilience.

Learn more about IBM zSystems

Let me be clear: IBM zSystems is, and will continue to be, a first-class citizen in IBM’s hybrid cloud environment. It provides the modern, differentiated capabilities we need along with unique qualities of service with a competitive TCO, making it a strong value proposition for IBM and our clients.

Check out our page to learn more about IBM zSystems.

Kathryn Guarini

IBM Chief Information Officer

=======================

What Can IBM X-Force Do For You? Security

3 min read

By:

Mitch Mayne, Public Information Officer, IBM X-Force

The Threat Intelligence Index helps you identify threats to your network. X-Force can help protect against them.

For some time, cybersecurity thought leaders have predicted that when it comes to attacks, the question is one of “when” and not “if.” They weren’t wrong. In fact, attacks have evolved beyond even that prediction and present a chronic problem for organizations, impacting not only IT but threatening business operations themselves.

Charles Henderson, Head of IBM Security X-Force offered a blunt (but accurate) perspective in an op-ed in 2021: "Assume that as a hacker, I'm already in, finding my way to your most prized possessions. What you actually need to trouble yourself with is, what can you do to stop me?"

The mindset shift

This is a mindset shift. It is strategic, not defeatist. Organizations must realize although there is no constant state of security, they can be prepared. While this will look different for every organization, it starts with knowing precisely what your most critical data is and where it resides. That knowledge needs to be coupled with an understanding of who has access to it, who could get access to it and who really needs that access. It’s about cutting off unnecessary pathways that an adversary could exploit.

 The mindset shift means security must be viewed as a journey, not a destination. 

But now the good news: IBM X-Force supports organizations at every stage of their security journey. By leveraging not only an attacker’s mindset, but the same tools, techniques and practices attackers use, X-Force uncovers high risk vulnerabilities and helps clients remediate them before attackers can find them:

Comprised of X-Force Red offensive security services, X-Force IR defensive security services and X-Force Threat Intelligence services, IBM X-Force provides a continuum of cybersecurity support that helps organizations stay head of global threats, reduce attacker impact and make Intelligence-driven decisions. Here’s how.

X-Force Red offensive security services for proactive support

X-Force Red is focused on identifying, prioritizing and remediating exploitable vulnerabilities that expose the most important assets to cyber attackers. It offers the following:

  • Penetration testing to find and fix exploitable vulnerabilities impacting your organization’s most important networks, hardware and people.
  • Vulnerability management to prioritize the highest-risk vulnerabilities for remediation.
  • Adversary simulation to uncover and fix gaps in an organization’s incident response programs.
X-Force IR defensive security services for reactive support

Organizations need to detect, contain and recover from attacks. X-Force incident response (IR) defensive security provides preparedness and 24x7 emergency IR services to prepare teams to prevent or quickly respond to future attacks, whether on-prem, cloud-based or in hybrid-cloud environments. From full cyber-crisis management to assessments and simulations to put plans into practice, X-Force offers a range of defensive incident response services.  

For organizations interested in a “whole-of-business” framework to help all business functions act in unison during a crisis, X-Force’s cyber-crisis management helps prepare executive teams with a program assessment, full plan development and a set of executive playbooks for individual roles and scenario responses. Drills are customized to executives and offered as tabletop exercises and immersive simulation exercises.

At the program level, X-Force can assess various aspects of your cybersecurity program and landscape to deliver tailored insights that drive priority improvements. Assessments include an incident response program, a threat intelligence program, strategic threat, active threat and ransomware readiness. X-Force can also search the dark web to provide organization-specific key findings and recommendations.

When it comes to plans and playbooks, X-Force experts can analyze your existing materials—making strategic recommendations for improvement—or develop new plans and playbooks as needed. Organizations can test their incident response plan against multiple scenarios through tabletop exercises with cyber range capabilities. Security teams learn how to act against real cyberattacks in a simulated, state-of- the-art environment that tests skills, processes and leadership competence.

X-Force Threat Intelligence services

Make security decisions based on threat research from global security intelligence experts who provide industry-leading analysis. For organizations looking to enrich their threat analysis, X-Force can aggregate incident detection and response using threat group profiles, malware analysis reports, malware detection rules and threat activity insights extracted from near-real-time threat intelligence.

To optimize threat intelligence detection and sharing, X-Force can automate threat intelligence from internal and external data sources through an ecosystem of security tool integrations and open-source intelligence (OSINT) feeds to help your team detect and share threat data faster. By combining expertise with threat intelligence, X-Force simplifies threat intelligence management by designing, building and operating an automated cyber threat platform that delivers up-to-the-minute threat data to help organizations stay ahead of attacks.

Learn more and get started with IBM X-Force Mitch Mayne

Public Information Officer, IBM X-Force

=======================

IBM Security Randori: A Leading Attack Surface Management Solution in Action Security

3 min read

By:

Sanara Marsh, Director, Product Marketing

How an attack surface management solution like IBM Security Randori can provide clarity to your cyber risk.

With the rapid adoption of hybrid cloud models and the support of a remote workforce, it is becoming increasingly apparent that digital transformation is impacting the ability of organizations to effectively manage their enterprise attack surface. The IBM Security X-Force Threat Intelligence Index 2023 found that 26% of attacks involved the exploitation of public-facing applications. Additionally, ESG’s 2022 State of Attack Surface Management report revealed that seven in ten organizations have been compromised via an unknown, unmanaged, or poorly managed internet-facing asset in the past year. As a result, external attack surface management was the number one investment priority for large enterprises in 2022

In this demo blog, we will show how a leading attack surface management (ASM) solution like the IBM Security Randori is designed to bring clarity to your cyber risk. Randori is a unified offensive security platform that offers an ASM solution and continuous automated red teaming (CART). Read on to see how Randori can enhance your security posture.     

Exploring your attack surface

To start, let’s look at Randori Recon, which is designed to ensure rapid time-to-value with no agents and an easy-to-use interface. Randori’s discovery process takes a center-of-mass-out approach, using various parsing techniques to attribute assets connected to your organization, thus delivering high-fidelity discovery of your attack surface. Based on the assets discovered, Randori Recon then applies risk-based prioritization based on adversarial temptation combined with your unique business context to provide insights that facilitate action.

With greater asset visibility and useful business context, Randori feeds its findings into your desired security workflows. Unlike many ASM products, Randori offers native bi-directional integration with other tools, including Jira, IBM Security QRadar, Qualys, Tenable and many others.

These integrations are becoming increasingly important as digital attack surfaces expand and workflows like vulnerability management are stretched to their limits.

A common customer use of Randori’s integrations is feeding discovered shadow IT into an exposure management solution like Tenable. This provides a holistic view of the organization’s footprint and useful information that might help significantly reduce the total number of vulnerabilities that should be addressed, as shown above.

Assessing which target assets to investigate

Next, let’s look at the Randori dashboard. On the left-hand side of the dashboard, we see ACTIVE ASSETS, which displays an inventory of your IPs, hostnames and networks. Many ASM solutions display this information alone, but viewing assets this way often contributes to alert fatigue and leaves the administrator without the context needed to adequately address the identified risk. To help address this, Randori focuses on correlating identified hostnames, IPs and CVEs into a single ascertainable Target (i.e., an attackable piece of software).

As seen below, administrators are immediately notified upon login that four targets require prompt action. The dashboard also shows high-priority target investigations that include newly identified unknown or shadow IT assets:

The total number of IP addresses and hostnames is too high for console administrators to tackle quickly. Instead of focusing on assets that are not critical to your services, Randori helps prioritize the targets that need attention first.

The Targets tab seen here offers a consolidated view of your digital footprint to help you determine what to investigate:

To provide administrators with the context needed to drive action, you will have access to the IPs, hostnames, characteristics and CVEs associated with a single target (rather than multiple repetitive and unnecessary pathways). This method helps to reduce alert redundancy and drive faster action:

As seen above, on any target identified, the Randori platform provides a distinct discovery path designed to provide administrators the clarity required to understand how and why this target is attributed to the organization.

Investigating high-priority target assets

Now, let's look closer at how to investigate this target. We notice that the target has a High association. Naturally, we want to understand what’s driving this severity:

What you’re seeing above is based on Randori Recon’s patent-pending Temptation Target model. Considering exploitability, applicability and enumerability, the model is designed to calculate how tempting a target will be to an adversary. This prioritization algorithm helps level up your security program:

Based on the target identified, the IBM Randori platform also provides categorical guidance (as shown here) that outlines some steps your organization can implement to help improve resiliency:

Get started with the IBM Security Randori platform

As a unified offensive security platform, IBM Security Randori is designed to drive resiliency through high-fidelity discovery and actionable context in a low-friction manner.

If you would like to see or learn more about how your organization can benefit from the IBM Security Randori platform, please sign up for a free Attack Surface Review or visit our page.

Read the full IBM Security X-Force Threat Intelligence Index 2023 and check out Security Intelligence's piece, "Backdoor Deployment and Ransomware: Top Threats Identified in X-Force Threat Intelligence Index 2023." View the Threat Intelligence Index Action Guide for insights, recommendations and next steps.

Sanara Marsh

Director, Product Marketing

=======================

Introducing Solution Tutorials for IBM Cloud for VMware as a Service Cloud

4 min read

By:

Bryan Buckland, Senior Technical Staff Member
 Sami Kuronen, Senior Cloud Solution Architect
 Mike Nelson, Cloud Solutions Architect

Two new solution tutorials to help you get started with IBM Cloud for VMware as a Service.

IBM Cloud for VMware as a Service (VMwaaS) is an exciting new addition to the IBM Cloud for VMware Solutions portfolio. VMwaaS is an IBM-managed service based on the VMware Cloud Director platform that allows enterprises to deploy virtual data centers built on dedicated IBM Cloud Bare Metal servers. This offering supplies the ease of a managed service combined with the security and performance of dedicated hardware.

VMwaaS also provides a great opportunity to take advantage of the advancements made in the last few years by VMware and the community to leverage Terraform in provisioning your infrastructure with code.

Overview

These two initial tutorials will guide you on the basic setup of a VMware as a Service – Single Tenant instance and show you how to create a virtual data center and its network, compute, and storage assets using the VMware Cloud Director Console and Terraform.

Topics covered include the following:

  • How to create virtual data center (VDC) networks inside your virtual data center
  • How to create virtual machines and attach them to your virtual data center network
  • How to configure network address translation (NAT) and firewall (FW) rules on your virtual data center edge gateway
Before you begin

These tutorials assume that you already have a VMware as a Service - Single Tenant instance (site) deployed and that you have deployed at least one virtual data center on your instance. You can manage the lifecycle of director sites and virtual data centers by using either the VMware as a Service console or REST API.

Tutorial 1: Creating a virtual data center in a VMware as a Service using the VMware Cloud Director Console

The first tutorial is called “Creating a virtual data center in a VMware as a Service using the VMware Cloud Director Console.” The following diagram presents an overview of solution to be deployed using VMware Cloud Director Console:

This tutorial is divided into the following steps:

  1. Log in to the instance's VMware Cloud Director Console and deploy virtual data center networks.
  2. Create virtual machines.
  3. Create IP Sets and Static Groups.
  4. Create NAT rules.
  5. Create firewall rules.
  6. Connect to the virtual machine using integrated web console.
  7. Connect to the virtual machine through the Internet and validate connectivity.
Tutorial 2: Creating a virtual data center in a VMware as a Service with Terraform

The second tutorial—“Creating a virtual data center in a VMware as a Service with Terraform”—focuses on deploying a similar topology, but using a provided Terrafom template:

The flow for this tutorial is as follows:

  1. Use the IBM Cloud Console to create a virtual data center in your single tenant instance. Your instance may have one or more virtual data centers, so you can have a dedicated virtual data center for testing purposes.
  2. When the first virtual data center is created, an edge gateway and external networks are created automatically. External networks provide you with Internet access and an IP address block of `/29` with six usable public IP addresses. Subsequent virtual data centers have the option of using a dedicated (performance) or shared (efficiency) edge gateway.
  3. Terraform templates are used to create virtual data center networks, virtual machines and firewall and network address translation rules. The creation is fully controlled though variables. Terraform authenticates to the VMware Cloud Director API with a user name and password. Access tokens will be supported in the near future.
  4. Three virtual data center networks are created: two routed (`application-network-1` and `db-network-1`) and one isolated (`isolated-network-1`). Routed virtual data center networks are attached to the edge gateway while an isolated virtual data center network is a standalone network. You can create more networks based on your needs.
  5. A jump server (`jump-server-1`) is created with the Windows 2022 operating system. This virtual server is attached to `application-network-1`. You can access the virtual machine though the VM console or by using RDP though the DNAT rule created on the edge gateway.
  6. One example virtual machine (`application-server-1`) is created on the `application-network-1`. `Application-server-1` has an additional disk for logging. You can create more VMs or disks based on your needs.
  7. One example virtual machine (`db-server-1`) is created on the `db-network-1` and `isolated-network-1` with two separate vNICs. The `db-server-1` has two additional disks for data and logging. You can create more VMs or disks based on your needs.
  8. Source NAT (SNAT) and destination NAT (DNAT) rules are created for public network access. SNAT to public internet is configured for all routed networks and DNAT is configured to access the application server.
  9. Firewall rules are provisioned to secure network access to the environment. To create firewall rules, Static Groups and IP Sets are created for networks and individual IP addresses.
Key benefits

IBM Cloud for VMware as a Service provides a great combination of flexible deployment models, security and performance of dedicated hardware and combined with highly available management plane and ease of use VMware Cloud Director. The capability to create multiple virtual data centers lets you to virtually isolate your teams’ or business units’ workloads and allows these teams to operate and manage their workloads individually. Through the advancements made by VMware and the community, you can also leverage Terraform to provision your VMware Infrastructure with Code from day one.

Further resources

IBM Cloud for VMware as a Service (VMwaaS) gives you the benefits of simplified VMware management, dedicated instance, compute flexibility and scale to meet your workload demands.

Bryan Buckland

Senior Technical Staff Member

 Sami Kuronen

Senior Cloud Solution Architect

 Mike Nelson

Cloud Solutions Architect

=======================

IBM's Metastore aaS: There Is No Lake without Metadata Database

5 min read

By:

Torsten Steinbach, Distinguished Engineer & CTO, Big Data in Cloud

Exploring the expanded capability in IBM Cloud to build and manage cloud data lakes on IBM Cloud Object Storage.

In particular, it explains the role of table metadata and how the IBM Cloud Data Engine service delivers this important component for your data lake.

We recommend you also watch the replay of the recent webinar for “Modernize your Big Data Analytics with Data Lakehouse in IBM Cloud” as well as the accompanying demo video to see the broader ecosystem in which this capability fits.

Context

It's not breaking news that metadata is a major element that needs to be managed for data and analytics solutions. Most people immediately associate data governance with this subject, and this is well justified because this is the type of metadata that ensures easy discoverability, data protection and tracking of the lineage for your data

However, metadata comprises more factors than just data governance. Most importantly, it also includes the so-called technical metadata. This is information about the schema of a data set, its data type and statistical information about the values in each column. This technical metadata is especially relevant when we talk about data lakes because unlike integrated database repositories such as RDBMS — which have built-in technical metadata — the technical metadata is a separate component in a data lake that needs to be set up and maintained explicitly.

Often, this component is referred to as the metastore or the table catalog. It’s technical information about your data that is required to compile and execute analytic queries — in particular, SQL statements.

The recent trend to data lakehouse technology is pushing technical metadata to be partially more collocated and stored along with the data itself in compound table formats like Iceberg and Delta Lake. However, this does not eliminate the need for a dedicated and central metastore component because table formats can only handle table-level metadata. Data is typically stored across multiple tables in a more or less complex table schema, which sometimes also includes information about referential relationships between tables or logical data models on top of tables as so-called views.

For these reasons, every data lake requires a metastore component or service. The most widely established metastore interface that is supported by a broad set of big data query and processing engines and libraries is the Hive Metastore. As the name reveals, its origin are in the Hadoop ecosystem. However it is not tied to or depending on Hadoop at all anymore, and it is frequently deployed and consumed in Hadoop-less environments, such as in a cloud data lake solution stack.

The metadata in a Hive Metastore is just as important as your data in the data lake itself and must be handled accordingly. This means that its metadata must be made persistent, highly available and included in any disaster recovery setup.

IBM launches IBM Cloud Data Engine

In our ongoing journey to expand IBM Cloud's built-in data lake functionality, we launched the IBM Cloud Data Engine in May 2022. It expands the established serverless SQL processing service (formerly known as IBM Cloud SQL Query) by adding a fully managed Hive Metastore functionality.

Each serverless instance of IBM Cloud Data Engine is now also a dedicated instance and namespace of a Hive Metastore that can be used to configure, store and manage your table and data model metadata for all your data lake data on IBM Cloud Object Storage. You don’t have to worry about backups — the Hive Metastore data is highly available as part of the entire Data Engine service itself. The serverless consumption model of Data Engine also applies to the Hive Metastore function, which means that you are only charged for actual requests. There are no standing costs for having a Data Engine instance with metadata in its Hive Metastore.

This seamlessly integrates with the serverless SQL-based data ingestion, data transformation and analytic query functions that IBM Cloud Data Engine inherits from the IBM Cloud SQL Query service:

But Data Engine can now also be used as a Hive Metastore with other big data runtimes that you deploy and provision elsewhere. For instance, you can use the Spark runtime services in IBM Cloud Pak for Data with IBM Watson Studio or IBM Analytics Engine to connect to your instance of Data Engine as the Hive Metastore that serves as your relational table catalog for your Spark SQL jobs. The following diagram visualizes this architecture:

Using Data Engine with Spark aaS in IBM Cloud

Using Data Engine as your table catalog is very easy when you use built-in Spark runtime services in IBM Cloud and IBM Cloud Pak for Data. The required connectors to Hive Metastore of Data Engine are already deployed there out of the box. The following few lines of PySpark code set up a SparkSession object that is configured with your own instance of IBM Data Engine:

instancecrn = <your Data Engine instance ID>
apikey = <your API key to access your Data Engine instance>
from dataengine import SparkSessionWithDataengine
session_builder = SparkSessionWithDataengine.enableDataengine(instancecrn, apikey)
spark = session_builder.appName("My Spark App").getOrCreate()

You can now use the SparkSession as usual; for instance, to get a listing of the currently defined tables and to submit SQL statements that access these tables:

spark.sql('show tables').show()
spark.sql('select count(*), country from my_customers group by country').show()
Using Data Engine with your custom Spark deployments

When you manage your own Spark runtimes, you can use the same mechanisms as above. However, you have to first set up the Data Engine connector libraries in your Spark environment,

Install the Data Engine SparkSession builder
  1. Download the jar file for the SparkSession builder and place it in a folder in the classpath of your Spark installation (normally you should use the folder "user-libs/spark2").
  2. Download the Python library to a local directory on the machine of your Spark installation and install it with pip: 
    pip install --force-reinstall <download dir>/dataengine_spark-1.0.10-py3-none-any.whl
Install and activate the Data Engine Hive client library
  1. Download the Hive client from this link and store it in a directory on your machine where you run Spark.
  2. Specify that directory name as an additional parameter when building the SparkSession with Data Engine as the catalog: 
    session_builder = SparkSessionWithDataengine.enableDataengine(instancecrn, apikey, pathToHiveMetastoreJars=<directory name with hive client>)

For more details, please refer to the Hive Metastore documentation of Data Engine. You can also use our Data Engine demo notebook that you can also download for local usage in your own Jupyter notebook environment or in the Watson Studio notebook service in Cloud Park for Data.

In chapter 10 of the notebook you can find a detailed setup and usage demo for Spark with Hive Metastore in Data Engine. You can also see a short demo of that Notebook at minute 14:35 here in the aforementioned demo video for the “Modernize your Big Data Analytics with Data Lakehouse in IBM Cloud” webinar.

Conclusion

With the new Hive Metastore as a Service capability in IBM Cloud described by this article, you get a central element for state-of-the-art data lakes in IBM Cloud delivery fully out of the box. There is no Day 1 setup or Day 2 operational overhead that you have to plan for. Just go and set up a serverless cloud-native data lake by provisioning an IBM Cloud Object Storage instance for your data and a Data Engine instance for your metadata.

Then, you can start ingesting, preparing, curating and using your data lake data with Data Engine service itself or with your custom Spark applications, Analytics Engine service, Spark runtimes in Watson Studio or your completely custom Spark runtime anywhere, connected to the same data on Object Storage and the same metadata in Data Engine.

Learn more about IBM Cloud Data Engine.

Torsten Steinbach

Distinguished Engineer & CTO, Big Data in Cloud

=======================

Automate Hybrid Cloud Infrastructure Provisioning with Terraform and Ansible Cloud

4 min read

By:

Malarvizhi Kandasamy, Senior Software Engineer
 Sashant Kanungo, Lead Cloud Developer

How to use cloud automation tools like Terraform and Ansible for disposable infrastructure.

In the traditional on-premises infrastructure provisioning model, engineers have to physically set up the IT infrastructure and configure the servers and networks. In the past, infrastructure provisioning and management had been a manual, time-consuming, inconsistent and error-prone process. 

With the advent of cloud computing, infrastructure management has been revolutionized. Within minutes, you can quickly build and dispose of cloud infrastructure solutions on demand; this is called disposable infrastructure. Disposable infrastructure is the process of automating the provisioning, configuring, deployment and tearing down of cloud infrastructure and services.

Many system administrators may have the following questions: 

  • How do I dispose of my infrastructure at the click of a button? 
  • How do I quickly set up my infrastructure in a new region? 
  • How do I configure my systems and ensure that they are all consistent with the same configurations?

The answer to all these questions is Infrastructure as a Code.

What is Infrastructure as Code?

Infrastructure as Code (IaC) automates the provisioning of infrastructure, enabling your organization to develop, deploy and scale cloud applications with greater speed, less risk and reduced cost.

Using IaC, you're basically treating your infrastructure components like software, which would address the problems related to scalability, high availability, agility and efficiency in infrastructure management. There are many cloud automation tools available in the market for IaC, including Terraform, AWS CloudFormation, Azure Resource Manager, Google Cloud Deployment Manager, Ansible, Chef, Puppet, Vagrant, Pulumi, Crossplane and more.

Using Terraform and Ansible

In this blog post, we are using Terraform and Ansible for cloud automation. In a public cloud, you can provision the infrastructure resources using Terraform (.tf* files), and run Ansible playbooks (.yml files) to automate configurations to install dependencies, deploy your applications and code against those provisioned resources.

The diagram below depicts a scenario using Terraform to provision the infrastructure and Ansible for configuration management in an IBM public cloud:

Customer use cases

The following are some of the customer use cases that use Terraform and Ansible for hybrid cloud infrastructure provisioning automation:

  1. F5 load balancer’s Active/Passive capability for a Virtual Network Function (VNF) high availability solution.
  2. Interconnecting on-prem network with the IBM Cloud network using a Virtual Private Network (VPN) gateway.
  3. Interconnecting on-prem network with the IBM Cloud network using Transit Gateway (TG) and Domain Name Service (DNS).
  4. Interconnecting on-prem network with the IBM Cloud network using a Strongswan VPN tunnel.

Let’s see each of these automated one-click deployment use cases in detail. The Terraform and Ansible examples provided below are for IBM Cloud.

Use case 1: F5 load balancer’s Active/Passive capability for a Virtual Network Function (VNF) high availability solution

In this use case, we provision and configure Virtual Server Instances (VSIs), applications and other network resources that utilize the F5 load balancer’s Active/Passive capability. The following is the cloud architecture diagram for this use case:

You can see that there is a F5 Active/Passive load balancer that has Management, Internal and External IPs for the Active/Passive pair. In the solution, we need to update the routing table—Custom Route’s next hop with the External IP of the current active F5 load balancer. When the active F5 load balancer goes to stand-by, we need to invoke a custom application that fetches the routes from cloud (RIAAS Endpoint) and updates the next hop with the active F5 load balancer.  

See the Terraform and Ansible code for this use case here.

Use case 2: Interconnecting on-prem network with the IBM Cloud network using a Virtual Private Network (VPN) gateway

This is a hybrid cloud network use case. The following is the cloud architecture diagram for this use case:

Here, you can see that two different clouds are interconnected using a VPN gateway connection. In a Virtual Private Cloud (VPC1), a three-tier application with a frontend, application and Cloudant database is deployed in a Red Hat OpenShift Kubernetes cluster with VPC available in multiple zones.

To expose an app in a VPC cluster, a layer 7 multizone Application Load Balancer (ALB) for VPC is created. The application is load balanced with a Private VPC Application Load Balancer. Since the ALB is private, it is accessible only to the systems that are connected within the same region and VPC1.

When you connect to a virtual server in the VPC network (VPC2), you can access your app through the hostname that is assigned by the VPC to the Application Load Balancer service in the format 1234abcd-<region>.lb.appdomain.cloud.

See the Terraform and Ansible code for this use case here.

Use case 3: Interconnecting on-prem network with the IBM Cloud network using Transit Gateway (TG) and Domain Name Service (DNS)

The following is the cloud architecture diagram for this use case:

Here, you can see that two different networks in the cloud are interconnected using a Transit Gateway connection. In Classic Infrastructure, a three-tier application with a frontend, application and Cloudant database is deployed in an IBM Cloud Kubernetes Service cluster with Classic available in multiple zones. To expose an app in a IBM Cloud Kubernetes Service cluster, a layer 4 Network Load Balancer (NLB) is created. The application is load balanced with a Private Network  Load Balancer. Since the NLB is private, it is accessible only to the systems that are connected within the Classic Network.

When you connect to a virtual server in a VPC network, you can access your app in Classic  through the static IP that is assigned to the Network Load Balancer service.

See the Terraform and Ansible code for this use case here.

Use case 4: Interconnecting on-prem network with the IBM Cloud network using a Strongswan VPN tunnel.

This use case also includes deploying a private NLB and accessing the application deployed in IBM Cloud Kubernetes Service from VPC. This is a hybrid cloud network use case, and the following is the cloud architecture diagram:

See the Terraform and Ansible code for this use case here.

Conclusion

You now have a basic understanding of how cloud automation tools are used for disposable infrastructure. You can try running the sample code mentioned in above use cases to set up hybrid cloud infrastructure using Terraform and Ansible.

Malarvizhi Kandasamy

Senior Software Engineer

 Sashant Kanungo

Lead Cloud Developer

=======================

Optimize Azure App Service with IBM Turbonomic Automation

3 min read

By:

Spencer Mehm, Product Marketing Manager

Announcing support for Azure App Service plans.

As public cloud expenditure continues to rise to a forecasted total of USD 591.8 billion in 2023, FinOps initiatives have gained momentum for organizations across industries. In fact, expenditure has been scrutinized to the extent that 81% of IT leaders have been directed to reduce cloud spending by the C-suite. In an effort to support our customers, IBM Turbonomic Application Resource Management has continued to build on its cloud and Platform-as-a-Service (PaaS) optimization capabilities.

IBM Turbonomic now supports Azure App Service

For cloud engineers and administrators running applications hosted on Azure App Service and struggling to control costs, IBM Turbonomic provides continuous optimization you can safely automate to get the most out of your PaaS investments. IBM Turbonomic provides dynamic vertical scaling—so App Service plans (ASPs) are never overprovisioned—while also automatically eliminating unused ASPs.

Upon implementing these new capabilities for our customers, IBM Turbonomic has delivered immediate and tangible outcomes, including one customer in the healthcare industry that was able to reduce their annual Azure App Service costs by 27% without compromising application performance.

What is Azure App Service?

Azure App Service is a fully managed Platform-as-a-Service (PaaS) that allows users to quickly deploy and run enterprise-ready web and mobile applications for any platform or device on scalable and reliable cloud infrastructure. This service comes with built-in infrastructure maintenance and security patching. App Service users pay for the compute resources they provision based on the App Service Plan pricing tier they select.

How can IBM Turbonomic optimize Azure App Service?

Let’s see how IBM Turbonomic provides continuous optimization so applications hosted on Azure App Service always perform at the lowest cost.

Dynamic vertical scaling

IBM Turbonomic automatically generates vertical scaling actions for Azure App Service plans. Vertically scaling an Azure App Service plan is accomplished by changing the instance type to increase or decrease the resources allocated to each virtual machine underlying the plan. Through dynamic vertical scaling, IBM Turbonomic can now ensure Azure App Service plans are always appropriately sized to optimize performance at the lowest cost. The screenshots below show the Action Center where Turbonomic customers can execute scaling actions. The Action Details of an App Service plan scaling actions are also illustrated:

Action Center

Action Details

Deleting an unused plan

IBM Turbonomic can continuously identify and delete “wasted” Azure App Service plans. A “wasted” App Service plan is a plan that was created, but has no applications actively drawing resources from it. By reducing their Azure App Service plan count through automated wasted plan remediation, customers can achieve significant savings and eliminate unused resources.

Below, you can find the Action Center where these actions are executed and the Action Details for this action type:

Action Center

Action Details

Achieve FinOps goals through trustworthy automation

As the discipline of FinOps continues to build momentum, organizations will turn to a variety of solutions to close the gap between their forecasted and actual cloud spend. While popular cloud cost-management strategies like budgeting, forecasting and cost allocation provide valuable insight, they often leave engineers and administrators guessing when and where to take action to reduce cost. For organizations looking to maximize their return on PaaS investments, IBM Turbonomic provides a proven path that will enable engineers to execute and automate cost optimization actions, delivering tangible outcomes both immediately and continuously.

Learn more about IBM Turbonomic Application Resource Management.

Spencer Mehm

Product Marketing Manager

=======================

Centralize Communication Through a VPC Transit Hub-and-Spoke Architecture Cloud

2 min read

By:

Powell Quiring, Offering Manager

Check out our new tutorial to learn how to centralize communication through a VPC transit hub and spoke.

A Virtual Private Cloud (VPC) provides network isolation and security in the IBM Cloud. A VPC can be a building block that encapsulates a corporate division (e.g., marketing, development, accounting) or a collection of microservices owned by a DevSecOps team. VPCs can be connected to an on-premises enterprise and each other. A new two-part solution tutorial covers the concepts and implementation of the transit hub-and-spoke architecture.

At a high level, the architecture might look like the following diagram:

Hub-and-spoke architecture.

Traffic will pass through the hub as it flows from enterprise to spoke or even spoke to spoke. IBM Cloud service instances can be created in the hub and used by the enterprise and spokes. The hub will contain a Network Function Virtualization (NFV) firewall-router instance for fine-grain routing control and packet inspection. You can choose a firewall-router from the catalog:

Data flow through a firewall-router.

Each of the VPCs has its own addressable entities. This includes microservices and IBM Service Instances. A Virtual Private Endpoint gateway (VPE) provides private and secure access to a service like IBM Cloud Databases for Redis. DNS entries for these entities can be managed through the IBM Cloud DNS Service.

DNS for microservices and VPEs.

We’re excited to bring you a new, two-part solution tutorial: Part 1 covers the concepts and implementation of the transit hub-and-spoke architecture and Part 2 routes more traffic through a HA firewall-router and implements VPE with DNS. The companion GitHub repository contains a complete implementation divided into small layers.

It can be informative to just read through the tutorial to obtain an understanding of the architecture. To get hands-on experience, you can provision the layers as instructed in the tutorial and use the IBM Cloud Console to view the resources and see the details. The tutorial even describes how to invoke a test suite to verify connectivity and interpret the results.

Topics include the following:

  • Transit Gateway to connect Direct Link 2.0 and VPCs
  • VPC zone-based routing
  • Resolving firewall-router asymmetric routing issues
  • Virtual Private Endpoint Gateways for local access to cloud resource instances within a VPC
  • DNS name resolution of IBM Cloud Service instances
Summary and next steps

This blog post and the accompanying solution tutorial show how you can use a hybrid cloud to place resources where they are most desirable. You can combine secure IBM Cloud Infrastructure as a Service (IaaS) components with your existing environment to create a platform for cloud and on-premises. Use your existing firewall-router technology in the cloud to meet your compliance needs, and optimize for your business—not your cloud provider.

Get started with Part 1 and Part 2 of our new solution tutorial, “Centralize communication through a VPC transit hub and spoke architecture.”

If you have feedback, suggestions or questions about this post, please email me or reach out to me on Mastodon (@powellquiring@mastodon.social), LinkedIn or Twitter (@powellquiring).

Powell Quiring

Offering Manager

=======================

A Quick Tour of IBM Event Endpoint Management Automation Integration

5 min read

By:

Salma Saeed, Product Manager, IBM Event Endpoint Management

Exploring IBM Event Endpoint Management and its capabilities.

There are some typical questions asked by application developers who are getting started with using events:

  • How can I discover events that others in my company already have that I would find useful?
  • When I find topics I want to use, how can I understand the data that is on them?
  • How can I start using these topics as efficiently as possible?

The simple answer to all the above? IBM Event Endpoint Management.

What is IBM Event Endpoint Management?

IBM Event Endpoint Management is already in the market, making the discovery and management of events just as easy as APIs. When working alongside IBM API Connect, it offers discovery and self-service access to both APIs and events together in one portal as part of the IBM Cloud Pak for Integration. 

IBM Event Endpoint Management is comprised of three functionalities:

  • API Manager: Document and manage APIs for internal and external use.
  • Developer Portal: Share, discover and subscribe to synchronous and asynchronous APIs through a company branded portal.
  • Event Gateway: Enforce runtime policies to secure and control access to Kafka topics hosted on backend Kafka clusters.

In the last few years, there’s been a lot of traction around AsyncAPI, which is emerging as an industry standard on how to describe topics as events. AsyncAPI is the specification we use to document a whole Apache Kafka system—describing the brokers, topics, topic data and things like contact information for the owner of the events. When combined with the Developer Portal and Event Gateway service of IBM Event Endpoint Management, you can describe, document, publish and socialise your clusters, whilst enabling self-service access.

Using IBM Event Endpoint Management

Let’s start our story with Shavon. Shavon is looking for a solution to document topics quickly. She wants to provide other teams in her company self-service access and the ability to re-use these events in new projects—this is where IBM Event Endpoint Management steps in.

API Manager allows Shavon to document the topics and produces a high-quality AsyncAPI document. This can immediately be published to the Event Gateway service and the Developer Portal, where others will be able to discover the event API. 

Now we will switch perspective to Andre, an application developer working on an exciting new project. In the Developer Portal, Andre will be able to see a wide range of APIs available to him—a catalog of synchronous and asynchronous APIs, all in the same place. He will be able to browse and find the exact information he is looking for.

Andre can click on the event API Shavon published to see if it is a good fit for his application. The data presented to him is that of the AsyncAPI that Shavon authored. Andre can find out more about the event API thanks to Shavon authoring the technical information. It provides a description of what the event represents and her contact details so that Andre can get in touch if needed.

The Developer Portal also generates code snippets to show an example use of the event API and example payload information (if a schema was provided by Shavon). From here, Andre will be able to see the data that is available and can quickly understand and decide if this is what he needs for his application. Andre can sign up and use this application by simply clicking a button to get access. He goes through the quick flow in which he chooses the level of service he would like from this event API and associates it with his existing application. With just a couple of clicks, he has now signed up to use this event API.

Using IBM Event Endpoint Management, in the space of a few moments, Andre discovers an event API which he didn’t know existed previously and signs up to use it, all without Shavon needing to generate any additional credentials or approve access for Andre.

Having signed up to the event API, Andre can now make use of it. The Developer Portal will update all generated code snippets to include his application. There are different libraries available for him to choose from: Java, kafka-console-consumer, kafkaJS, node-rdkafka and kafkacat. All the configuration Andre needs to get started will be templated into the code snippet, using the library of his choosing. This means he can just copy and paste the generated code into his chosen editor where he will be able to run a real application against IBM Event Endpoint Management, securely accessing Shavon’s cluster and the events it contains.

Just as Andre discovered this application in the Developer Portal, others can also discover the same events and make use of them to fit their use cases and needs. IBM Event Endpoint Management can be used to document, socialise and enable self-service access to any Kafka distribution, from any vendor.

It is very quick and easy to discover and make use of events, as we have been doing with APIs for some time now. Shavon described her Kafka cluster in the API Manager and published it to the Developer Portal. Andre was able to make use of this in his application and securely access that cluster through the Event Gateway.

Streamline the discovery and management of events with IBM Event Endpoint Management

IBM Event Endpoint Management helped Shavon describe topics with minimal overhead for others to re-use. It also provided Andre a single place to effortlessly discover topics that others have shared, understand them and start using them without having to negotiate access. This has been done through the four D’s:

  • Description: API Manager allows you to describe your AsyncAPI in a way that provides enough information for another developer, such as Andre, to make use of them. This covers technical details, documentation of what the events represent and contact details to get in touch with the owner of those events.
  • Discovery: The Developer Portal—which can be customised to mirror the look and feel of your company—is a single catalog that displays all the APIs and events available in an organised and searchable way. Developers can easily choose the correct API or event required for their use case.
  • Decentralised: From the Developer Portal, Andre can get self-service access to any of the events available to him. Shavon, the owner of the AsyncAPI, can specify controls and protections.
  • Decoupled: The Event Gateway provides an isolation point to prevent unintended interaction between Andre and other application developers using the same events as well as providing interface versioning.
Learn more Salma Saeed

Product Manager, IBM Event Endpoint Management

=======================

What’s the Real Cost of Running Your Apps in the Cloud? Cloud Hosting Migration

3 min read

By:

JD Wells, WW Sales Leader - IBM Cloud VMware Solutions

IBM is offering a no-cost VMware application migration assessment from Akasia.

The cloud, as we know it, is really a vast collection of clouds. There are big clouds, small clouds, public clouds, private clouds, clouds with bare metal servers and those with shared virtual machines. This hybrid multicloud environment is the path forward for most companies, because not all clouds are well suited to each type of workload. Choosing the wrong cloud platform or migration path can cost an organization a lot of time and money after they’ve already migrated their workloads. No wonder, then, that some organizations are finding the cloud to be less cost-effective than they first imagined.

Cloud cost modeling helps organizations get a handle on workload migration costs before they migrate. There are several modeling tools available. Ideally, these tools should not only accelerate the cost-discovery process but also provide multiple cloud options and various migration scenarios. One tool that stands out is Akasia. It’s simple to use, requires very little up-front effort (e.g., no configuration or provisioning is required) and provides detailed cost analyses of various migration scenarios, including the major cloud providers: AWS, Azure, GCP, VMware Cloud and IBM Cloud.

Akasia analyzes your current workload environment and provides a CapEx and OpEx TCO analysis from the infrastructure and usage, based on workload consumption. It provides right-size recommendations across cloud providers, sized to the specific usage.

Akasia’s cloud cost modeling methodology does the following:

  • Delivers insight into current and future cloud costs with very little effort on the part of IT teams
  • Quantifies costs in a way that allows organizations to accurately project budgets
  • Factors workload efficiency into the equation
  • Calculates workload costs by VM, operating system and resources
  • Maps out your operating systems and charts a recommended migration path
How can I save money migrating my VMware workloads?

One of the biggest challenges facing organizations today is how to maintain secure and performant systems while also deploying new capabilities without disrupting current workloads. This can be problematic for VMware IT teams because not every cloud platform provides full and open access to the VMware vSphere platform in the same way that customers are accustomed to on-premises. For example, organizations may need to buy new VMware, OS or software licenses due to new requirements or limitations and may find that older OS versions are simply not available.

These types of pitfalls are important to identify early in the migration planning process. This is one of the big reasons why IBM and Akasia have partnered together to help organizations plan and assess their VMware workload migrations. IBM Cloud for VMware Solutions is uniquely suited to VMware workloads, a distinction that the Akasia cost-modeling tool understands because of its depth of insight.

For example, because IBM Cloud for VMware offers a larger selection of hardware configurations than any other public cloud platform, organizations have more flexibility to right-size their VMware workloads. In addition, IBM doesn’t meter for private network usage, which is a cost factor that Akasia rightly takes into consideration since it can add up to a lot of extra money at the end of the day. And only IBM Cloud for VMware supports both VSAN and NFS storage, so organizations can scale compute and storage independently rather than having to add servers every time they need more storage.

Follow 200 companies and get your FREE cloud assessment

With Akasia, organizations can ensure they begin their cloud journey on the right foot with realistic expectations around cost savings and performance. Whether you’re starting out on your cloud journey, struggling to migrate mission-critical workloads or just wondering if you’re getting the best value from your cloud provider, a cloud cost assessment from Akasia can help you find the best “home” for business applications in a multicloud world.

For a limited time, IBM is offering a no-cost VMware application migration assessment from Akasia.

JD Wells

WW Sales Leader - IBM Cloud VMware Solutions

=======================

Top 10 Tips for Migrating Your ECM System to the Cloud Cloud Migration

6 min read

By:

Alan Pelz-Sharpe, Research Director, Deep Analysis

Migrating your enterprise content management (ECM) system to the cloud can be a painless process with these tried-and-true tips.

Don't believe the hype! If you think you're the only one with an expensive, old on-premises document management system that can't be improved and moved, you're wrong.

Many organizations feel caught in a bind—they want to migrate to something more effective but migrating a legacy system to the cloud fills them with fear. They’ve heard that it may all go wrong or be expensive, complicated and risky. Ten years ago, those were valid concerns, but today, a migration to the cloud is much more straightforward than you may imagine. It also typically brings a wide range of immediate benefits, including lower costs, increased security, the elimination of tiresome maintenance and updates, and easy access to content—anywhere and anytime.

In short, the move is much easier to make than most realize, and the benefits make it well worth the effort. We know this because Deep Analysis has advised many large and small organizations over the years on how to migrate document management and ECM systems to the cloud. In this blog post, we share some simple and well-proven top tips to ensure success for your organization.

A three-step process to a successful migration

First, it’s important to note that successful migration is a three-step process: preparation, migration and optimization. We call this the 60-20-20 plan, as that is how you divide your time:

  • 60% of your time will be spent in planning and preparing to decommission your legacy system.
  • 20% will encompass the actual migration process.
  • 20% will be used to optimize the modern system to accommodate and leverage the migrated content.

But how much time is needed in total? If the plan we suggest here is followed correctly, it may be only a few days or weeks for a simple system, or longer for more complex and extensive legacy systems. Either way, no migration project should last longer than a few months (except for extreme examples, which you likely want to avoid anyway). So, keep in mind that when preparing to migrate to the cloud and transform your business, you will spend most of your time preparing and optimizing, bringing far more value to a migration project than simply lifting and shifting files.

But before doing any of that, it is often best to start with a clean sheet. If you are planning to move to the cloud, why not try it out first by deploying a new application? That way, you can get your new application up and running and become familiar with working in the cloud before migrating your older applications and data. Start with something small. You likely have a list of new apps you were planning to build and deploy, so pick a relatively simple, quick win from the list, and by deploying that, you will also set yourself up for a successful future legacy migration.

Top 10 tips for migrating document management and ECM systems to the cloud
  1. Ensure any migration project is business-led: Though migrating a legacy system to a new, more modern environment requires technical expertise, any such effort should always be business-led. The migration’s success depends on thoroughly understanding your future requirements and mapping the move to meet those needs.
  2. Avoid the lift and shift: Don't just move everything from an old system to a new system. Lifting and shifting is a common mistake. The small effort required to define some simple rules regarding what you need in your new system is worth it. Anything that does not meet that new need should be disposed of or moved to a secure, low-cost separate location. It is your chance to clean house, and you will reap the rewards.
  3. Be brutal: It's an urban myth that you need to keep everything forever. You don't; nor should you. What you will almost certainly find in any legacy is an opportunity to put rules and procedures in place so that the same legacy data mountain problem does not recur. Keeping everything forever is a major compliance and legal risk when you have a legal obligation to destroy some data after set periods of time. A system migration is an opportunity to essentially automate that work moving forward.
  4. Prepare your new system for success: Never migrate content from one location to another before optimizing the new system for that content. New structures, metadata and locations must be defined for the incoming content. This is not difficult to do, but many skip the step and end up with another useless mountain of inaccessible content residing in a newer system.
  5. Start small: Don't move everything in one go; transfer a small but representative quantity of content first and ensure that everything works fine. Alternatively, start with a brand-new application to gain a quick win and become comfortable with the system. Check that the content runs correctly in its new home and ends up in the right place. As you test a few small batches, you may want to make adjustments before moving to larger batches. Again, a steady, step-by-step approach will deliver dividends.
  6. Learn from your past mistakes: Take this opportunity to put rules and procedures in place to avoid another legacy data mountain problem. Don't repeat the mistakes of yesterday by again hoarding and failing to manage information assets. When you migrate from a legacy system to modern architecture, you will clear out a lot of junk, add controls where there were none and start to work more efficiently.
  7. Document the process: Though there is no need to write a lengthy detailed report, do document what you have done and why. Common sense tells us that at some point, someone in your organization will pop out of the woodwork and complain that their old system isn't working anymore. Be sure you have documented what happened, why and the steps you took in the migration. This ensures continuity of service if and when the people who run and use the system move on, and it will provide a record of lessons learned and a playbook for future migrations.
  8. Plan for governance surprises: Old legacy systems will contain unexpected—and at times unpleasant—surprises. Most typically, they will reveal information assets that should never have been there in the first place. Be sure to have a basic plan to consider compliance, privacy, security and regulatory issues that may govern the information and your organization.
  9. Integrate with other systems: Sometimes, you may only move a pile of information into a lower-cost and easier-to-access location. But often, you will want to use that information more effectively in the future. So, think about how that information is leveraged and how it will be integrated into your remaining systems and processes.
  10. Expect the unexpected: If we have learned one thing over the years, it is that every migration delivers surprises. You might find scores of "personal" photographs, pieces of weird software, unreadable and corrupted files or locked folders within locked folders (often belonging to long-departed employees). You don't need to move these, but you do need to look out for them. Trust us, the unexpected can be the most memorable and, dare we say it, fun element of any migration project!

"Legacy" is a term used widely in the IT world; it refers to software and hardware that have been superseded by more efficient, cloud-based technology. Legacy systems are seen as difficult to replace. But in most cases, such systems and data stores can be relatively easily replaced. You can migrate anything of value from them and, in the process, reduce costs, increase efficiencies and improve your customer and employee experiences. The migration process does more than simply move you to a more modern system—it's an opportunity to clean house, reduce costs, and simplify.

So, let the migration begin.

Learn more about IBM Content Services

IBM Content Services is an IBM-managed, pre-configured set of content management capabilities that make it easier for you to get up and running quickly. Easily integrate content into your applications with an out-of-the-box user experience—ensuring that the right content can be quickly accessed by the right people. With IBM Content Services hosted on AWS, you can provision and get set up within minutes. See for yourself how IBM Content Services can help your organization improve employee and customer experiences, mitigate compliance risk and modernize your content management system while lowering your total cost of ownership (TCO).

Visit the IBM Content Services webpage to learn more about how to get started and to sign up for a 30-day free trial.

Alan Pelz-Sharpe

Research Director, Deep Analysis

=======================

Enhance Cloud Security by Applying Context-Based Restrictions Cloud Security

3 min read

By:

Henrik Loeser, Technical Offering Manager / Developer Advocate

Check out our new tutorial to learn how to enhance security for your IBM Cloud environment by utilizing context-based restrictions.

Context-based restrictions (CBRs) give account owners and administrators the ability to define and enforce access restrictions for IBM Cloud resources based on the context of the access request (e.g., network attributes). In an IBM Cloud account, both Identity and Access Management (IAM) policies and CBRs enforce access, so context-based restrictions can offer protection even in the face of compromised or mismanaged credentials or privileges.

To get you started with CBRs, we just published a new tutorial, “Enhance cloud security by applying context-based restrictions.” It helps you learn about CBRs to protect your cloud resources. The tutorial leverages our existing tutorial “Apply end-to-end security to a cloud application" and its sample code, and it also adds an extra layer of security. The diagram below shows the solution architecture of the existing security tutorial. The additional boxes with dashed, blue lines around some components denote CBRs implemented as context rules.

In this blog post, I’ll briefly introduce context-based restrictions. Then I’ll show you how to learn more and be able to implement, test and monitor CBRs with the help of our new tutorial:

Context rules governing access to services of the sample solution.

Overview: Context-based restrictions

IBM Cloud introduced context-based restrictions (CBRs) in late 2021. These restrictions work with traditional IAM policies to provide an extra layer of protection. This is because IAM policies are based on identity (e.g., user, service ID or trusted profile) while CBRs are based on the context of request (e.g., network addresses, originating services or accessed endpoint types).

A CBR rule governs access to a resource identified by its service name and type as well as by additional attributes. They can include the region, resource group and other service-specific properties. The attributes in a rule are mostly optional so that you could govern, for example, all IBM Key Protect for IBM Cloud instances together or target just a specific key ring in an identified Key Protect instance.

The context for a restriction is made up of network zones and service endpoints. You might want to define zones based on specific IP addresses or ranges or by configuring traffic originating from one or more VPCs or cloud services. With that, access to the sample Key Protect instance might only be allowed from, for example, a specific IBM Cloud Object Storage instance, a well-known range of IP addresses and only via the private endpoint.

Network zones can be used for the definition of multiple rules. Rules have an enforcement mode that is one of disabled, report-only or enabled.

New tutorial and sample code

You can use our recently published tutorial, “Enhance cloud security by applying context-based restrictions,” to meet the following objectives:

  • Learn about context-based restrictions to protect your cloud resources.
  • Define network zones to identify traffic sources for allowed and denied access.
  • Create rules that define context for access to your cloud resources.
  • Learn how to test and monitor context rules.

The tutorial walks you through the creation of CBR network zones and context rules with both the IBM Cloud console and Terraform code. The latter helps to establish security rules in an automated way. Once the rules are in place, next are testing and monitoring that they will work (reporting mode) or actually work (enforced mode).

To test, access resources covered by CBR rules via different origins and paths. Using the IBM Cloud Activity Tracker, you can see log entries for matching rules that are in report mode. Each log record has details on the context and the rule-based decision. That is, the log shows the request origin, involved network zones, the targeted service and if the rule would have rendered a “Deny” or “Permit.”

Once rules are enforced, after testing for at least a month, only denied access is reported. An Activitity Tracker log record for such an event is shown in the following screenshot. The tutorial provides guidance on how to find the relevant log records:

Log entry in IBM Cloud Activity Tracker showing denied access.

Conclusions

Context-based restrictions help to enhance cloud security. They add an extra layer of protection to your cloud resources and complement the existing Identity and Access Management policies. With our new IBM Cloud solution tutorial, you learn how to create network zones and context rules, how test and monitor them. Here are the resources to get you started:

If you have feedback, suggestions, or questions about this post, please reach out to me on Twitter (@data_henrik), Mastodon (@data_henrik@mastodon.social) or LinkedIn.

Henrik Loeser

Technical Offering Manager / Developer Advocate

=======================

Deploy Resources and Toolchains with Terraform Cloud DevOps

3 min read

By:

Henrik Loeser, Technical Offering Manager / Developer Advocate

The journey to modernize our delivery pipeline continues. Learn how we moved to a Tekton CI/CD pipeline that is deployed using Schematics-managed Terraform (Toolchain as Code).

The IBM Cloud solution tutorial Apply end-to-end security to a cloud application, like many, comes with code and a related GitHub repository. As a reader, you can either follow all the steps and manually create services and deploy the application, or you can take a shortcut and use an automation.

Over time, the automation changed from a classic toolchain with shell scripts in the pipeline to a Tekton-based pipeline with a Terraform-created toolchain. In this blog post, we provide an overview of the recently updated toolchain and how we got there:

A Terraform-created Tekton pipeline running.

Overview: History of a toolchain

The IBM Cloud solution tutorial Apply end-to-end security to a cloud application walks you through how to use some key IBM Cloud security services together. The tutorial uses a file-sharing application as an example. The application source code and an automation to easily deploy the app and required resources are provided in a related GitHub repository.

We first published the tutorial around the early days of the Tekton project—a powerful and flexible open-source framework for creating CI/CD (continuous integration/continuous delivery) systems. At that time, the IBM Cloud Continuous Delivery service only offered support for what, today, is called a classic delivery pipeline. Hence, our initial code included a pipeline-invoked shell script to create the required resources and to deploy the app. The toolchain was based on the Open Toolchain format.

About two years ago, we upgraded the deployment automation to use Terraform code managed in IBM Cloud Schematics to create the cloud services and a Tekton pipeline hosted in the Continuous Delivery service to build and deploy the container image with the application. The toolchain itself still was based on the Open Toolchain format.

Recently, we switched the toolchain creation to Terraform, too. You create an IBM Cloud Schematics workspace to manage the Infrastructure as Code (IaC) deployment. In the workspace, you configure how the Terraform code should create the services and the toolchain. The settings include the resource group, target region, namespace in the Container Registry, service plans, etc. Then, you apply the Terraform code and create the resources. When done, run the delivery pipeline (see screenshot above) and the app is online (see screenshot below):

File-sharing app provided by the IBM Cloud solution tutorial.

Get started

If you already know the tutorial and want to try out the updated code directly, head over to the GitHub repository and its README file. Make sure to meet the few documented prerequisites, then click the link to create the IBM Cloud Schematics workspace. During that creation process, the directory with the Terraform configuration files is read and evaluated. It includes two new files:

  • The resource configuration for the toolchain: toolchain.tf. It defines the toolchain, its integrations with GitHub to find the pipeline source code, the pipeline definitions and details on where to run in (spoiler: on a public worker).
  • The resource configuration for the toolchain properties: toolchain_environment.tf. It defines the input parameters for the Tekton pipeline and its tasks.

When you apply the Terraform plan in Schematics, it creates the service instances for the solution and the toolchain with the Tekton pipeline to build and deploy the app. As part of the latter, it reads the definition files for the Tekton pipeline. Running the pipeline is managed by the Continuous Delivery service. Follow the instruction to run the pipeline in order to build the container image with the app and to deploy it to the Kubernetes cluster.

Conclusions

It is interesting to see how the code for the automated deployment of resources for a single tutorial evolved. As developer, I always try to learn from others or to get hands-on experience on my own. In that sense, I invite you to either learn from the available updated code which I described above or to even utilize the toolchain to deploy the sample app yourself.

Feel free to open an issue in the repository if you run into problems with the updated deployment automation. If you have feedback, suggestions, or questions about this post, please reach out to me on Twitter (@data_henrik), Mastodon (@data_henrik@mastodon.social) or LinkedIn.

Henrik Loeser

Technical Offering Manager / Developer Advocate

=======================

IBM and Adobe Deliver Next-Gen Digital Transformation Cloud

4 min read

By:

Baan Slavens, Director - PM, IBM Sustainability Software
 Uday Kotla, Head of Product, Adobe Commerce

How can companies differentiate their customer experience with compelling and comprehensive digital commerce and order management capabilities?

Companies wishing to build up a loyal clientele invest significantly in personalized experiences, merchandising strategies, and optimized fulfillment and execution. By leveraging digital technology, companies can develop unique products and services that differentiate them from competitors and meet the changing needs of their customers. This leads to increased loyalty as engaged customers return to their favorite shopping destinations with a larger share of their wallets. Enter Adobe and IBM, partnering to create transformative next-generation digital customer experiences that engage and delight customers.

The Adobe and IBM Partnership

Adobe and IBM are two of the major players in the field of digital customer experience. Both companies offer a range of solutions designed to enhance the customer journey, including modern experience-building tools with compelling content, AI-driven personalization, and rich visual merchandising (coupled with accurate real-time inventory visibility and robust order management and fulfillment capabilities).

Adobe Commerce enables companies to create rich, personalized shopping experiences supporting all channels and business models on a single platform that is flexible, extensible and scalable. The platform leverages Adobe Sensei AI to optimize marketing and merchandising while allowing businesses to manage orders, products and customer data in one place. Adobe Commerce is part of the Adobe Experience Cloud and natively integrates solutions like Adobe Experience Platform, enabling businesses to gain insights into customer behavior and use real-time context to tailor their marketing efforts accordingly.

Companies around the world use Adobe Commerce to power their digital transformation initiatives, delivering rapid and high impact results. Take Alshaya Group, for example; with the help of Adobe Commerce and Adobe Consulting Services, the organization was able to successfully launch (in the span of 12 months) 30 new ecommerce sites and 2 mobile apps, resulting in a 268% YoY growth in online transactions. “Working with Adobe is a key part of the equation, helping us innovate together and make this change happen at pace,” said Marc van der Heijden, CTO of Alshaya Group.

IBM, on the other hand, offers a range of order management solutions through its IBM Sustainability Software portfolio. These solutions include IBM Sterling Order Management, which helps businesses manage orders across multiple channels and devices, and IBM Sterling Intelligent Promising, which helps businesses balance their inventory levels and reduce costs through accurate real-time promise and order scheduling. The Order Management suite helps manage orders from the point of purchase to delivery. It involves tasks like tracking orders, updating inventory levels and processing returns and exchanges. These capabilities are critical in order to ensure that customers receive their orders in a timely and accurate manner. IBM Sterling Order Management also picks the best locations from which to source product (with the least number of order splits) and thereby helps sustainable fulfillment operations and helps companies in their ESG goals.

IBM’s leadership in the Order Management space can be seen through ground-breaking innovation, especially in applying artificial intelligence and machine learning to sourcing and fulfillment decisions and, more importantly, showing real-time quantifiable ROI benefits. IHL recognized this approach of using a “Transparent AI” while highlighting IBM as the #1 leader in the 2022 IHL Order Management Market study.

Trust and visibility through an integrated solution

Together, IBM and Adobe have developed an integrated solution that helps businesses streamline and optimize their supply chain and order management processes—integrating them into the digital commerce experience. This includes everything from accurate real-time inventory management to robust order orchestration and exemplary customer service, augmented with tools to track and analyze customer data to improve the overall customer experience. The joint solution is especially relevant in a world where there is a need for a tight inter-connectedness between digital commerce and supply chain.

Knowing customer behavior and aligning supply strategies with expected customer demand is a critical foundation for modern merchandising strategies that provide relevant and localized assortments. Customers then dictate where and how they will purchase product, and this dramatically alters the inventory availability landscape, prompting the need for a strong order-management solution to anchor the digital customer experience.

With this combined solution, companies are able to incorporate supply chain health metrics—including inventory positions, velocity and demand—into real-time marketing and merchandising to optimally engage customers. This improves experiences and satisfaction by fulfilling on inventory promises while enabling companies to more effectively allocate marketing budgets. In addition, real-time recommendations and insights can be used to improve shopper engagegment as they pick up their orders in store or engage customer service representatives.

One of the key features of this solution is the flexibility to integrate with a wide range of existing systems and diverse operating models, including ecosystem partners and multiple formats. This enables businesses to power their current operations and realize immediate benefits while providing a platform to accelerate digital transformation and innovation.   

This ability to rapidly transform at pace was seen in action when retailers rolled out innovative initiatives to adjust and thrive in the new ‘normal’ of the pandemic. With salons and barbershops temporarily shutdown down, Sally Beauty Inc. saw an unprecedented demand from daredevil work-from-home shoppers choosing DIY kits to dye their hair purple.

“Thank goodness we have the IBM Sterling platform to help us keep ahead and respond quickly to marketplace demands.” - Sonoma Taylor, VP Solution Delivery, Sally Beauty Holdings, Inc.

A solution for today’s changing times

The partnership between Adobe and IBM has resulted in a powerful solution that integrates marketing and customer engagement with supply chain and order management processes, leading to increased efficiency and customer satisfaction. It is a prime example of how two companies with complementary skills have come together and created something greater than the sum of their parts.

Companies can choose from an extensive set of tools and journey maps available through IBM iX, the business design arm of IBM Consulting, to help plan out their transformation journey.

Both Adobe and IBM have also built a strong ecosystem of partners and system integrators with deep product and domain skills and focus on customer experience who can help businesses achieve rapid success and time to value. It’s time to talk to us and, together, make the change.

Learn more about how IBM is working with Adobe to enable enterprises to transform their digital commerce experience with the best digital experience tools, commerce components and order management tools.

Baan Slavens

Director - PM, IBM Sustainability Software

 Uday Kotla

Head of Product, Adobe Commerce

=======================

Why Open Source Turned Out to Be the Right Solution for Two Visionary Brands Cloud

4 min read

By:

Deepshikha Antes, Partner, Global Red Hat Strategic Partnership

How Shell and Raise Green collaborated with IBM Consulting to drive rapid transformation.

Maintaining a focus on innovation is top-of-mind for CTOs, especially while building an agile and customer-first tech ecosystem that delivers business value at a fast pace.

To facilitate transformation and implement new and emerging tech, we advise IT leaders to continually assess systems and evaluate whether they are meeting core business needs. CTOs need to unify disparate environments to ensure scalability for rapid growth while building on legacy tech investments.

In addition, IT executives in the energy sector are usually charged with not only leading their organization’s digital transformation but also with addressing urgent challenges related to sustainability, energy efficiency and renewable energy.

Below, let’s look at how two energy companies—one well-established, and one a startup—are collaborating with IBM® Consulting to open their hybrid cloud environment to drive growth and transform speed into value.

Open innovation, open technologies and open culture in just eight months for Shell plc

Shell plc, headquartered in London, England, is a group of energy and petrochemical companies that uses advanced technologies and takes an innovative approach to help build a sustainable energy future. Shell’s target is to become a net-zero emissions business by 2050. To further this goal, they chose to build a solution for the energy and resources industry that could simultaneously tackle sustainability, digital transformation and business growth.

Today, IT leaders look for a partner that understands their world and helps them successfully implement strategies with cutting-edge technologies into their business. Looking to speed innovation with frictionless, integrated on-premises and multicloud experiences, in 2020, Shell collaborated with IBM Consulting to create OREN, a digital mining optimization platform.

“OREN is an open platform for collaboration with different solutions,” says Grischa Sauerberg, Vice President of Sectorals Decarbonisation & Innovation at Shell. “Providers can bring their digital products and offer those to customers. But even more importantly, it also allows them to work together on end-to-end integrated digital solutions that help mining companies tackle the challenges they have around decarbonization.”

The team chose IBM Cloud® as the cloud service provider and the Red Hat® OpenShift® Platform for its hybrid cloud architecture so that OREN can run on other cloud platforms its customers require.

Shell employees and IBM consultants collaborated using the agile IBM Garage™ Methodology to rapidly co-create (design), co-execute (build) and co-operate (scale) the project. The combined team adopted DevOps principles to speed time to value and kept a steady cadence of agile ceremonies to maintain focus, taking OREN from concept to launch in just eight months.

As IT leaders shift focus from one-off initiatives to an urgent, purpose-driven imperative, they must embrace an open way of working. IBM Consulting is the partner for the new rules of modern business. We believe open ecosystems, open technologies, open innovation and open cultures are the key to creating opportunities and the way forward for modern business.

Raise Green's 10-week transformation

IT leaders seek to re-envision their IT and integrate existing environments to maximize the business value of all their cloud and infrastructure investments. That was the case for Raise Green—an emerging renewable energy brand—who needed to reduce complexity and costs in their IT investments while boosting tech adoption in all facets of their business.

As a startup in a regulated industry, Raise Green took 10 months to develop its first pilot project—a community solar power venture. To take its concept to the next level, the company chose to work with IBM because of IBM’s reputation as an established and trusted technology and solutions partner with experience in sustainability projects, climate data and the energy sector. Raise Green co-founders Franz Hochstrasser and Matthew Moroney spent a week in London co-creating solutions with teams from IBM iX® and IBM Garage to design a framework for digital transformation.

The solution was the Originator Engine, a digital platform designed to allow a person—regardless of experience or income—to navigate the complexities of solar project development. For example, the Originator Engine, running Red Hat OpenShift on IBM Cloud, can help disadvantaged communities profit directly from a clean energy project. Raise Green chose this container platform because of the open-source technology’s flexibility, which will allow the startup to extend its platform into other areas of sustainability, provide customizations and offer access to third parties.

IBM Consulting helps transformation projects succeed with an established method to pilot, accelerate and scale solutions together. With the help of IBM Garage and its end-to-end model to accelerate digital transformation, Raise Green streamlined and simplified the whole process of creating, funding and building a clean energy project from 10 months to an average of 10 weeks.

Transform together with a hybrid cloud open to innovation

In all, CTOs responsible for making hybrid cloud architecture environments that integrate seamlessly are in a pivotal time right now. Scaling to meet demands, managing risk and keeping up with rapidly changing technology are key steps to turn innovative ideas into business value. IBM can help you build and execute a hybrid cloud strategy, with everything from evaluating your current technology environment to partnering with our consulting team to co-create your strategy.

For CTOs who cannot rip and replace what they have but look for ways to enhance the value of existing applications, our breadth and depth of expertise with top-tier partners like Amazon Web Services, Microsoft Azure and Google Cloud—in addition to our own IBM Cloud, Power, Storage and Z mainframe infrastructure—can help you strategize, migrate, build and manage applications on your platform of choice with speed to value.

Lastly, for IT leaders who want to reduce the cost of maintain their existing infrastructure and create new ones on the cloud, Red Hat OpenShift powers freedom of choice: portability, reliability, resiliency and architectural flexibility on any type of cloud—public, private or on-prem.

Transform your business with IBM Consulting and Red Hat.

Download the full report: Strategic Application Modernization.

Deepshikha Antes

Partner, Global Red Hat Strategic Partnership

=======================

Transforming Telecom Tower Workflows with IBM Digital Twin Platform on AWS Artificial intelligence Automation

4 min read

By:

Alecio Binotto, Principal Architect, IBM Consulting
 Sanjay Panikkar, Platform Architect, IBM Consulting
 Nikhil Baxi, Solution Architect, IBM Consulting
 Praveen Velichety, Digital Twin Offering Lead, IBM Consulting
 Rabeela Janorious, Edge Computing Architect, IBM Consulting
 Dhana Vadivelan, Solutions Architecture Leader at AWS
 Fabio Oliveira, Sr. Partner Solutions Architect, AWS

How the IBM Digital Twin Platform can help telecom companies increase operational efficiency and reduce the time-to-market of service delivery.

Telecom tower companies strive to have the most current view of their complete tower portfolio “as is.” This affects not only a cost-effective maintenance plan, but mainly space optimization to improve tenancy ratio and leasing opportunities. Challenges include fragmented data in silos, low tenancy ratio per tower, increasing speed of technology upgrades (e.g., 5G rollouts), market pressure from new players, mergers and acquisitions (M&A) and high maintenance costs due to expenditures related to site visits, design, construction and infrastructure operations. Therefore, telecom companies are under pressure to increase operational efficiency and reduce the time-to-market of service delivery.

The IBM Digital Twin Platform—which combines digital thread, artificial intelligence (AI), IoT, edge, 3D representations and automation—has proven to be effective in addressing these challenges in their digital transformation journey.

A digital twin is a virtual model designed to accurately reflect a physical object/process. Data is collected about the object being studied, and the virtual model can be used to run simulations.

IBM Digital Twin for telecom towers

The key building blocks, workflow and open ecosystem of partners for our telecom tower solution include the following:

  • Tower scanning: Drones follow guided flight paths to capture high-resolution images of the tower asset.
  • 3D reconstruction: The solution uses 2D drone images to reconstruct a 3D realistic model of the tower, and information from photogrammetry services, equipment catalogs and intelligent equipment detection use AI to enrich the realistic model.
  • 3D business information modeling (BIM): The realistic reconstruction is automatically converted into an initial 3D BIM model and further improved using BIM model libraries. These models allow engineers to perform highly accurate design enhancements (e.g., add an antenna, dish or Remote Radio Unit (RRU) equipment from a BIM library) and perform different types of physical simulations (e.g., EMF-Electromagnetic Field and structural stability) through the digital twin application.
  • Ground cabinet monitoring: The solution can manage IoT/edge devices like HVAC, batteries, and energy consumption.
  • Lifecycle management: The solution provides ongoing lifecycle support of the built tower through its continuous monitoring and predictive maintenance capabilities.

Supporting the key building blocks is an integration layer to multiple enterprise systems for data exchange. This is the asset single source of truth through a digital thread layer composed of a standardized ontology model and orchestrated by a knowledge graph. AI models and analytics, weather services and additional IoT data further enrich the platform.

The figure below depicts the user interface for some use cases that encapsulate the building blocks described above:

Digital Twin built on Amazon Web Services (A­­WS)

The solution architecture comprises modular and loosely coupled services, and it is highly scalable and expansible through an open ecosystem and custom-developing services. Since the solution supports multiple customers of the tower company, each customer can only access and view information specific to their equipment through role-based access control and security features. We extensively use cloud-native AWS services to fulfill the needs of our AWS clients, as depicted by the diagrams below:

IBM Digital Twin for Telco Towers in its AWS implementation version.

Enterprise integration layer on AWS.

Benefits

The IBM Digital Twin Platform benefits not only engineering planning or maintenance teams, but also supports corporate strategy, including finance and sales. We believe it’s a foundation to improve tenancy ratio and, therefore, tower and company values. Those benefits are only possible when we implement a digital thread to bring fragmented data together in a collaborative environment (i.e., including partners and Mobile Network Operators (MNOs)).

Below are some statistics we continuously collect about our “scan to BIM to lifecycle” intelligent workflow. There is also the possibility of unlocking additional value with MNOs by having accurate “as-is” 3D views of the complete tower portfolio through regions of actuation:

Conclusion

In this post, we presented the IBM Digital Twin platform applied to the telecom tower industry on AWS. We discussed how the solution addresses key industry challenges and provided a technical overview of the solution, including accurate 3D tower models “as is” through a scan-to-BIM intelligent workflow, space optimization with digital twin as a design tool to help improve tenancy ratio, integration of siloed data in a single digital thread to facilitate faster decisions and minimize errors, and help with predictive maintenance considering IoT sensors of ground cabinets, among others.

The platform and its associated digital twin program is continuously evolving, especially together with our partner 5x5 Technologies, which produces realistic models based on drone scanning. As a result, IBM believes the solution could possibly deliver a 70-300% ROI for telecom clients that are implementing our digital twin methodology and solution. Our solution goes beyond telecom towers. It comprehends a range of sustainable critical infrastructures, such as wind and energy towers, telecom networks, energy grids, solar farms, manufacturing lines and smart cities composed of multiple critical infrastructures.

IBM Consulting has been ranked a leader by Everest Group in their inaugural report Digital Twin Services PEAK Matrix® Assessment 2022, and the IDC report Digital Twins — Transforming Supply Chains and Operations provides further information about the business benefits that you can achieve with IBM Consulting-owned digital twin services and offerings. For more information on how to engage with IBM, visit here.

Note: The claims and outcomes referenced in the blog are based on IBM's past engagements. Results may vary across clients.

Alecio Binotto

Principal Architect, IBM Consulting

 Sanjay Panikkar

Platform Architect, IBM Consulting

 Nikhil Baxi

Solution Architect, IBM Consulting

 Praveen Velichety

Digital Twin Offering Lead, IBM Consulting

 Rabeela Janorious

Edge Computing Architect, IBM Consulting

 Dhana Vadivelan

Solutions Architecture Leader at AWS

 Fabio Oliveira

Sr. Partner Solutions Architect, AWS

=======================

Mainframe Application Modernization with IBM Cloud and IBM zSystems Cloud

6 min read

By:

Hillery Hunter, GM & CTO IBM Cloud, IBM Fellow
 Skyla Loomis, Vice President, IBM Z Software
 Surya Duggirala, IBM Cloud Platform Engineering Guild Leader

Exploring a hybrid cloud strategy that includes IBM zSystems and IBM Cloud.

Digital transformation initiatives sweeping across industries like banking, insurance, healthcare, government and retail are driven by new consumer behavior, new regulations and a new way of doing business. Additionally, initiatives like open banking, open insurance and open data (among others) have the potential to create new revenue channels.

In many enterprises, mission-critical applications and core business transactions have been running successfully on IBM zSystems for years, if not decades. With enterprises globally looking to reduce time to market and increase their ability to respond quickly to market changes, it is time to look at embracing mainframe application modernization as part of the overall digital transformation agenda.

To retain the core strengths and attributes of IBM's mainframe platform and leverage the performance, resiliency, security and regulatory compliance programs of IBM Cloud, a hybrid cloud approach can help enterprises on their mainframe application modernization journeys. 

A hybrid cloud strategy that includes IBM zSystems and IBM Cloud offers many benefits, including innovative development practices that leverage an agile integrated DevOps approach, easier access to mainframe applications and data, the ability to address skills gaps with open tooling, and IT automation capabilities. IBM Cloud is designed for enterprise and regulated applications and offers innovative cloud security capabilities, such as confidential computing services and native zSystems dev/test support. Together, IBM Cloud and zSystems can help accelerate mainframe application modernization to improve agility, optimize costs and lower risk.

A tale of two teams

To run core business transactions on IBM zSystems, there is traditionally a dedicated development and operations team to support these applications, with the responsibility to run the day-to-day operations.

Apart from the above mainframe team, many enterprises now have a digital team under a Chief Digital Officer (CDO) to onboard new cloud-native technologies, tools and processes and help improve business agility, developer velocity and spur innovation through adoption of newer compute models — like the hybrid cloud deployment model.

Our objective is to help clients leverage IBM Cloud and zSystems together in a hybrid approach to do the following:

  • Show how organizations can come together to deliver transformation while continuing to run the business successfully.
  • Address challenges expressed by industry leaders while embarking on the mainframe application modernization journey.
  • Guide clients and partners through various solution architectures and best practices.
  • Demonstrate how to drive a common enterprise modernization approach across the organization.

Mainframe application modernization with IBM Cloud can be achieved in various dimensions; in this post, we will talk about the following:

  1. Improve business agility and provide a modern DevOps platform for mainframe applications with IBM Cloud.
  2. Secure mainframe applications and data in a hybrid multicloud platform.
  3. Simplify access to mainframe applications with an API strategy.
  4. Achieve greater sustainability with IBM LinuxONE and IBM Cloud.
1. Improve business agility and provide a modern DevOps platform for mainframe applications with IBM Cloud

IBM zSystems supports the latest development, operational tools and processes and features z/OS dev and test through IBM Wazi as a Service. IBM Cloud offers a fully functional mainframe through a high-performing IBM Z compute Virtual Server Instance (VSI) in IBM Cloud Virtual Private Cloud (VPC) that can be integrated with modern DevOps toolchains with built-in security and compliance features. It helps remove skills barriers, eliminates contention between multiple teams sharing on-premises-based IBM Z LPAR and spurs innovation in mainframe application development and test processes.

Enterprise DevOps solution architectures can be implemented on IBM Cloud to help set up an integrated DevOps pipeline suitable for both cloud-native distributed and mainframe applications. They can take advantage of many cloud services—like data and AI—to modernize mainframe applications. The security and compliance services available in IBM Cloud can protect and validate mainframe applications and data during the development phase.

Get started with a z/OS dev and test virtual server on IBM Cloud in under six minutes [1]

Enable continuous testing with an IBM zSystem in IBM Cloud that performs up to 15x faster [2]

2. Secure mainframe applications and data in a hybrid cloud platform

Application and data running on the IBM zSystems platform are often mission-critical to the business, and they require the highest levels of security available. As public cloud applications increasingly need to access mainframe applications and data, the expectation is for the same level of enterprise-grade security across a hybrid multicloud platform.

IBM Cloud is designed for enterprise and regulated workloads and has developed many security services based on IBM Z platform security features to support both IBM Cloud’s own platform architecture and offered as cloud services to clients. IBM Cloud Hyper Protect Crypto Services manages client in IBM Cloud, and it is FIPS 140-2 Level 4 certified, which is the industry’s highest certification for a Hardware Security Module (HSM) [3]. With the functionality of Keep Your Own Key (KYOK), even IBM Cloud administrators cannot access the keys; they are solely owned and managed by the clients, to help them protect sensitive mainframe assets in Cloud.

IBM Cloud’s security services can also be extended to hybrid-cloud-centric enterprise workloads through the Unified Key Orchestrator.

3. Simplify access to mainframe applications with an API strategy

An API-centric integration strategy is fundamental to mainframe application modernization. New cloud-native channel applications need access to mainframe applications and data, which hosts core business logic for many industries. The core mainframe applications like COBOL, CICS and IMS can be exposed through APIs. IBM Cloud offers a secure framework to manage the lifecycle of mainframe APIs for development and test through hybrid cloud. This is supported by the IBM Z and Cloud Modernization Stack running on IBM Cloud.

With a high-performing z/OS VSI provisioned in IBM Cloud VPC and integrated with CI/CD pipelines, IBM Cloud can provide a secure development and test environment to create new IBM Z-centric APIs, and it can use IBM Cloud for Financial Services features like the IBM Cloud Security and Compliance Center to validate the compliance requirements.

4. Achieve greater sustainability with IBM LinuxONE and IBM Cloud

Digital transformation continues to drive additional compute capacity, putting pressure on an organization’s sustainability objectives. Measuring carbon footprint through server and cloud-centric calculators and finding ways to reduce the footprint across the board is a key priority not only for cloud vendors, but also for enterprises. A focus on exploiting clean energy sources with efficient hardware and software technologies is becoming part of standard corporate responsibility. IBM Cloud offers IBM LinuxONE servers in their data centers to help reduce the carbon footprint and reduce the energy costs. An IBM LinuxONE server can save, on average, 59% per year in power consumption when compared to x86 systems running workloads with the same throughput.

Leverage the expertise of IBM Consulting

IBM Consulting offers a broad array of expertise to help our clients maximize value from their application investments and accelerate IBM zSystems and hybrid cloud modernization initiatives, including the solution architectures referenced here and many other zSystems modernization patterns.

Conclusion

To protect clients’ investments and help accelerate their digital transformation journey, IBM Cloud provides a set of hybrid solution architectures that will help remove the inhibitors in modernizing mainframe workloads.

IBM recommends a hybrid cloud approach to mainframe modernization, with IBM zSystems and IBM Cloud working together with seamless integration architectures. The four solution architectures described in this blog will help improve business agility, reduce time to market and help modernize development through an enterprise DevOps approach, help address sustainability challenges, address enterprise security concerns of hybrid multicloud platform, and help integrate cloud-native applications with mainframe applications.

Additional solution architectures around data and AI, IBM Cloud for Financial Services, refactoring mainframe applications, etc., will be discussed in future blog posts to give more guidance around mainframe application modernization through hybrid cloud.

Contact IBM Cloud Expert Labs for more implementation details or schedule a free consulting session with an IBM Consulting Expert.

 

[1] On average, creating an experimental IBM Cloud z/OS Virtual Server Instance (VSI) of a z/OS 2.4 stock image and a mz2o-2x16 VSI profile takes 1 minute, and it is ready for user login (SSH) in 5.5 minutes. Disclaimer: Measurements were done across two different IBM Cloud production sites using an experimental version of z/OS 2.4 stock image and a mz2o-2x16 VSI profile. Measurements were performed with Ansible automation based on the examples here. Results may vary.

[2] Applications compile faster on an experimental IBM Cloud z/OS Virtual Server Instance (VSI) than on IBM Z Development and Test (ZD&T) EE V13.3 running on the compared IBM Cloud x86 VSI — about 15x faster compilation of Java applications, about 12x faster compilation of C applications and about 8x faster batch compilations of COBOL/FORTRAN applications. Disclaimer: Performance results based on IBM internal tests running application compiles on an experimental IBM Cloud z/OS V2R4 Virtual Server Instance (VSI) with profile mz2o-2x16 versus on IBM ZD&T EE V13.3 running in an IBM Cloud x86 VSI with profile mx2-2x16. IBM ZD&T was running on Ubuntu 20.4 on a x86 Production VSI with a Cascade Lake Intel Xeon Platinum CPU @ 2.4GHz. Both z/OS VSI and ZD&T were configured with 2 vCPUs, 16GB memory, and 1 TB Block storage with 10 IOPS/GB. The following applications were compiled — a Java application that processes SMF records, a C application that processes IBM Z hardware diagnostic data, a COBOL application that creates and updates records on a file and a FORTRAN statistical application. Results may vary.

[3] Data security through the industry’s only FIPS 140-2 Level 4 HSMs protects data in IBM Cloud: https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-2.pdf

Hillery Hunter

GM & CTO IBM Cloud, IBM Fellow

 Skyla Loomis

Vice President, IBM Z Software

 Surya Duggirala

IBM Cloud Platform Engineering Guild Leader

=======================

Exploring Cold Start Time on IBM Cloud Code Engine with the Knative Quarkus Bench Cloud

3 min read

By:

Scott Trent, Research Staff Member

This post describes the use of the Knative Quarkus Bench to explore cold start times of serverless functions running on the IBM Cloud Code Engine.

Our previous blog posts have introduced running and tuning the performance of serverless functions on IBM Cloud Code Engine using the IBM Cloud port of the Knative Quarkus Benchmark.

A primary advantage of serverless functions is automatic and nearly transparent scalability of underlying computational resources, including scale-to-zero, which fully releases unused resources. The ability to only deploy and use resources when needed helps reduce total consumed resources, thereby reducing cost. It can also be considered an environmentally friendly approach by reducing energy consumption. However, intuitively, one would expect a serverless function that has not been used recently and has had its resources scaled to zero to take longer to respond to a request than one that has been recently used and thus has its resources currently available.

Base experiment

The following pseudocode demonstrates an experiment our team used to understand the actual impact scale-to-zero has on the response time for serverless functions in IBM Cloud Code Engine. (Details on deploying and deleting serverless applications and accessing the benchmark with curl can be seen in our first blog post.)

Experiment pseudocode:

For pauseTime in 0, 15, 30, 45, 60, 120, 180, 240, 300:
    Deploy sleep benchmark on IBM Cloud Code Engine
    Repeat five times:
        Pause pauseTime seconds, then access benchmark with curl command
    Delete sleep benchmark from IBM Cloud Code Engine

Running this experiment, we learned that without tuning, a warmed up serverless function that has been accessed within the past 60 seconds will respond on average in 0.22 seconds, and a cold serverless function that has not been accessed for over 60 seconds will respond on average in 17.2 seconds. This does seem reasonable, since in one case, the pod is running and available to reply to requests, and in the other case, a pod and other networking services must be deployed. There are certainly many use cases in which the advantage of resource and cost savings offered by scale-to-zero overcome the disadvantage of a potentially slower response time for cold requests.

Sample command to start Knative Quarkus Bench on IBM Cloud Code Engine for this experiment:

ibmcloud code-engine application create --name sleep --image ghcr.io/ibm/knative-quarkus-bench/graph-sleep:jvm

Sample command used to access and measure sleep bench response time:

$ URL=$(ibmcloud ce app list | grep sleep | tr -s ' ' | cut -d ' ' -f 3)
$ /usr/bin/time curl -s -w "\n" -H 'Content-Type:application/json' -d '"0"' -X POST ${URL}/sleep
Experimental verification of tuning

Next, we experimented with tuning to support use cases where slow cold requests are not acceptable. The min-scale option can be specified when creating applications in IBM Cloud Code Engine. The default value for this option is zero, which permits the number of pods to scale down to zero, thus enabling scale-to-zero.

Theoretically, if min-scale is set to 1, there will always be at least a single pod that can ideally promptly service requests even if there has been no activity for longer than 60 seconds. We verified this behavior by modifying the previous experiment to use --min-scale 1 when creating the serverless function application and then measured the response time after varying pause times, as before. We observed that regardless of pause time, the average response time was 0.22 seconds. Hence, setting --min-scale to at least 1 will significantly improve cold request performance.

Figure 1: Default vs. tuned average serverless function response time after varying periods of inactivity

Conclusion

This post has demonstrated how to use Knative Quarkus Bench to determine the potential performance differences between cold and warm requests to serverless functions. Furthermore, we demonstrated how to use the --min-scale option to avoid the potential performance impacts of scale-to-zero.

We encourage those currently running serverless functions on IBM Cloud Code Engine to consider if their workload could benefit from using the --min-scale option to improve cold-request performance. If you have not already tried out serverless function applications, check out the step-by-step instructions in our first blog post to deploy and access a serverless benchmark application.

Scott Trent

Research Staff Member

=======================

Page 1|Page 2|Page 3|Page 4