Service Projects and IBM Design Thinking

In the past four years, I have successfully delivered several large service projects using Agile and IBM Design Thinking methodologies. It is always surprising to hear the argument that Design Thinking is only for Software Development and has little applicability for service projects. 
Let me make the case that the opposite is true: Service Projects benefit even more from the core practices of IBM Design Thinking.

Hills
Service projects want to deliver business value to the user in a short time.

Credit IBM

Hills focus the architecture and creation of a service to what the user expected outcome is. A release allows no more than three major objective. This drives clear and containable scope, a great medicine against troubled projects. 
Three questions drive this focus:
Who is the User?
What is the Problem?
What is a sufficient Solution?


Look at this example from an actual project: "“Support recovery from a disaster with an RTO of less than 6 hours and near zero RPO”. Clearly, this will be very common hills for a service project.


Sponsor Users 

Credit IBM

Service projects on day one are exposed to the user. Sponsor Users help to identify the problems that a hill tries to solve. They validate the solution that is implemented in the service. That removes risk, as it pulls the feedback cycle to the left, before the service has been rolled out in production. The sponsor users can guide the envisioning during the design and implementation phase.



Playbacks
Service Projects need commitment, both from the client side, as well as from the service teams. 
IBM Design Thinking is a commitment to a new way of working, to be more adaptable. 

Playbacks puts client commitment center stages as it reduces the noise of nonspecific conversations, and improves the quality and consistency of feedback.

Credit IBM

For the team creating the service, Playbacks will check progress against the original goals, and thereby emphasize the commitment to the business and customer value defined in the Hills.

I would like to hear from you: have you used Design Thinking in Service Projects?

Have We Crossed The Chasm Yet?

Looking at the industry and Cloud, I often think about the book "The Innovator's Dilemma" by Clayton Christensen.

Innovative technology or solutions are usually treated by the industry with the progression of rejection, toleration, adoption, dependence.

Compare the time when the the 3.5" inch hard drive replaced the 5 1/4" inch hard drive. Initially they were rejected because no one knew what to use this smaller drive for. Their had less storage capacity and also cost more. 

Credit: IBM

Some server manufacturers started to put the smaller drive into their standard server chassis. This the phase of toleration. But since the chassis size did not change, the free space around the smaller drives create no value.

Then a new application appeared on the scene: computers that you could carry! There is a real benefit in using smaller sized hard disk for computers that need to have the size and weight to be accepted as carry-on accessories. 
This led to mass volume the adoption of the 3.5' inch form factor for drives. If you look into server and blade chassis today, you will see the also have changed over time as well and depend now on the smaller drives - since there is no space anymore for the 5 1/4' inch.

Where are we with Cloud? True, there are still the rejectors among the software vendors that make it hard for technical or non-technical reasons to run in a Cloud. But most applications these days tolerate to run on a Cloud.
More than that, 72% of developers report that cloud-based services or APIs are part of the applications they are designing. Example of these are the SoftLayer Cloud APIs and the BlueMix services. This is a big step toward dependence. An application that essentially relies on such services and APIs will run best and maybe exclusively on Cloud.

No question, Cloud is here to stay. But what do you think: will it completely replace dedicated systems? 

New in IBM Cloud Managed Services v1.4 - Virtual Machine Capture and Clone

IBM Cloud Managed Services is a fully managed, highly secure IaaS cloud optimized for critical enterprise workloads. IBM Cloud Managed Services offers unique instance-level VM uptime SLAs to 99.95% and many advantages of a private cloud—such as options for dedicated servers and storage—while providing flexible scaling and the benefits of cloud economics.

With IBM Cloud Managed Services v1.4, a new feature is introduced to capture and clone an unmanaged Virtual AIX Machine. In this article, we give an overview of the function and the individual steps.
Many thanks to Adrian Moti, Radu Adam, Mihai Andrei and Dan Serbanescu who contributed both the documentation and the implementation.

Overview
There are several practical use cases that benefit from the VM capture and clone function. 
For example, if a system has been configured as a basis for many other systems, this first system can be captured and then cloned to several other virtual machines. Or a system can be captured at various points in time and if the need arises, it can be reverted back to an earlier capture.

Before the capture and clone process can be started, a utility server is needed. With the help of that server, the next two steps are performed:

1. Capture a source system
2. Deploy the captured image to a target system

Step 0 - Creating a Capture & Clone Server
This utility server has to be set up for each data center that you want to use the capture and clone function. Even if you want to capture and clone multiple VMs in a data center, you only need this utility server once.

1. Log in to the Cloud Managed Services control User Interface
2. Provision a new Unmanaged AIX VM
3. Add a new disk to the provisioned
4. Perform required configuration steps, including the execution of the helper script makenimm
5. Write down the IP address of this server's en0 interface - you will need it later

The server that was created will act as a utility system for the next steps. Now you are ready to use the capture and Clone capability.

Step 1 - Capturing an unmanaged AIX machine
Capturing a source VM is aided by a script based automation.

1. Find the Capture & Clone server en0 IP address (see above) 
2. Login to the unmanaged AIX LPAR machine (called source LPAR) you want to capture with an administrative user (root).
3. Execute the vmcapture script, specifying the en0 IP address of the Capture and Clone Server.
4. Optionally, you can specify an mksysb image name. 
5. After the capture is completed successfully, a message is displayed with the image name to be used during deployment.

You are now ready to deploy the image you have captured from this source system   

Step 2 - Deploying an unmanaged AIX image
There is an automated script available to perform the deployment into the target system.

1. Using the Cloud Manages Services UI, Create a new unmanaged AIX VM. This is the target system to deploy the previously captured image.
2. Log on to the Capture & Clone Server 
3. Identify the mksysb image to be deployed on the target VM
4. Execute the vmdeploy command which automatically restores a captured mksysb image.

You will be able to remotely access the cloned LPAR via SSH using the credentials od the captured mksysb.

Migrating systems to IBM SoftLayer - Overview

This is a first in a series of articles that discusses how to migrate workload to SoftLayer.
Special thanks for the content of this article goes to Matei Puiu, Gabriel Teodorescu, Mihai Garbia and Adrian Moti.

Overview of the Racemi tool for migration
With Racemi Cloud Path for IBM, you can now automatically move your existing servers to the SoftLayer platform and benefit on minimal downtime of your existing workload. Cloud Path for IBM provides an automated cloud instances migration process that moves the entire server stack to the new Softlayer environment in a few easy to follow steps.

Description of a sample configuration for migration and CloudPath for IBM setup
We will go through the process of migrating one active server to SoftLayer by using the Racemi CloudPath for IBM Migration method. After the migration we will expect the same type of instance with the same configuration to be running on the SoftLayer platform.

The prerequisites for this guide are access to the active source server and proper SoftLayer accounts The process starts by describing the creation of the Racemi account.

Creating the Racemi CloudPath for IBM account:

1. Access the link 
2. Click 'sign up' button from the Registration and Login box.
3. Complete the user, password and other informations in the registration form. 
4. Check your email and click on the link to complete the registration process.

For more information, you can also check the Racemi provided tutorial. 

Getting started with CloudPath for IBM
When you first log into CloudPath4ibm, you will be presented with options to register your cloud credentials and download your migration agent.

Prepare and clean up the instances prior to migration
Please take into account a certain downtime of your servers during migration. The downtime depends on the quantity of data as well as the transfer speed which is directly impacted by the geographical location of the source server and the target SoftLayer datacenter. 

Checklist prior to migration:

• make sure the instance is running at the time of migration
• verify access to your instance – Linux instances need to be accessible via SSH key, and Windows instances via RDP
• since the post migration logging in, is done using the same credentials as for the source system, make sure you save the SSH key or account credentials for Windows backed up
• make sure the Racemi migration agent is installed 

Post migration configuration and validation, update procedures
After the migration process is completed, your old server will also be available on SCE. Most likely, clients will still connect to this server. Client migration procedures are necessary in order to re-direct the traffic to the newly created server. Please keep in mind that the new server will have different IP settings.

Below you can see an example of this change:

Original instance:
[idcuser@vhost5112 ~]$ cat /etc/resolv.conf
domain site2.compute.com
nameserver 129.35.212.106
nameserver 129.35.212.107
[idcuser@vhost5112 ~]$ hostname --long
vhost5112.site2.compute.com

SoftLayer migrated instance:
[idcuser@mgrh64enh ~]$ hostname --long
mgrh64enh.racemi.com
[idcuser@mgrh64enh ~]$ cat /etc/resolv.conf
nameserver 10.0.80.11
nameserver 10.0.80.12

Known issues and limitations

• Logging in to the CCI instances will be done with the original server authentication method and credentials
• To use the full 100GB disk space that SoftLayer provides, you might need to modify the partition layout.
• Note that SoftLayer cannot create partitions larger than 300GB on local storage.
  If you plan to migrate partitions larger than 300GB, use SAN storage as server configuration in Racemi's Cloudpath migration tool, which supports up to approximately 2TB partitions.
• When you plan to migrate, take into account that, when Windows creates a partition, it allocates a small amount of partition space to the NTFS file system table. This space varies depending on the partition size, so the actual available space on the partition will be less than the partition size.
  For example a SoftLatyer 2TB partition has 1999,85GB free space. If your SCE partition size is more than this size, then the migration will fail.
  To overcome this issue, either split your partitions into multiple smaller partitions, or if you have enough free space shrink the partition to a size smaller than 1999,85GB
• All the migrated CCIs will have a NIC with a public IP and a secondary NIC with a private IP, regardless of the number of interfaces the source system had. If a user requires more IP addresses, he can request additional IPs by logging to the old portal (https://manage.softlayer.com) and clicking on 'Add IP Addresses' in the 'Sales' menu. He can then add the IP addresses to one of the instance NIC by following this Knowledge Layer guide:
• Windows
• Red Hat
• If you make any major file system structure changes on the source instance, such as resizing a partition or attaching/detaching a storage, a reboot of the instance or a restart of the dynacenter service Are required, in order for the Racemi agent to be able to update the settings before the migration process begins

Check back here on this blog for more articles on migration to SoftLayer.

Migrating Workload to Cloud - How to avoid the pitfalls

After analyzing Cloud migration projects over the last few years, I noticed some patterns. Here are the Best Practices of successful migrations. This covers both SoftLayer as well as the IBM Cloud Managed Services.

Successful Migrations:

• Use documentation and training material before starting the project
  Good resources are the ThoughsOnCloud blog. Or find out that there is a great offer from Racemi and IBM to accelerate Cloud adoption.
• Understand the target Cloud system capabilities and standards in detail
  For example, get to know what Operating System and what versions and fixpacks are supported on the target Cloud. Do they match with the systems currently running the workload? Is there an additional release upgrade step required?
• Analyze the source workload and match it for fit on the target Cloud
  The Migration feature for IBM Cloud Managed Service includes a tool based method that can be run on the source system or a offline copy and includes over 450 checks to determine which adjustment would need to be performed for a migration.
• Plan a Proof Of Concept of initial "Wave 0
  During the actual migration window when productive workload is to be cut over, time is of the essence. To have a more relaxed opportunity to rehearse and validate, successful teams plan an initial migration of less critical workload and include a buffer.
• Document Roles and Responsibilities
  Migration project often employ specialised transition and transformation personnel. Also the target Cloud environment might be new and therefore not well known. To avoid misunderstanding, hand-over gaps and loss of time for problem solving it is important to understand R&R. This helps each performer to know where to reach out to if questions or issues arise.   
• Train migration engineers before the migration window.
  Or better yet, work with a team that has done it before. IBM Cloud Managed Services offers a standardized, partially automated processes in a globally delivered factory model to help complete workload migration and deployment.

Have you done successful migrations to Cloud? Tell us about it. What where your lessons learned?

The overlooked dynamics in Enterprise workload

For new developed web applications, most of the time, it is a no-brainer to decide to host the production system on a shared Cloud. The highly dynamic number of request, the peaks within a day and over a week are often quoted as good fit for a shared infrastructure. The scale out model of the application makes it easy for servers to come and go. The benefit of paying for the resources that are needed is easily seen.

For applications that were born on the Enterprise, this daily or weekly dynamic often does not exists. Or the argument is that the maximum capacity has to be available all the time to meet the expected SLA. The conclusion is that a shared Cloud has no benefit over dedicated resources for such workload. But that overlooks several important points, two of which are shown in this diagram.

The blue line shows the cost for a dedicated infrastructure over 4 years, imagine for a double digit number of servers, with the capacity fixed for the time period. The green line represents the resources provided in a shared Cloud, with per-device pay-as-you-go pricing.

Consider two dynamics
For a contract period of 4 years, the initial setup of a dedicated infrastructure usually takes 6 to 9 months, for the ordering of the hardware, setup, configuration and creation of the workflows and runbooks to manage the systems. This yellow area represents about 6% to 10% of the total cost of the infrastructure for the 4 year period! In a the IBM shared Cloud the onboarding and setup takes on average less than 3 weeks because the Cloud is already set up an operational.

During the 4 years inevitably there is some fluctuation of capacity actually required. For example, during some version or release upgrade, additional systems are needed for several weeks or months. Or due to consolidation, a number of systems are no longer needed. A dedicated infrastructure will need a capacity management process and additional investment before more resources can be added. And unused resources incur cost for the provider; by definition, dedicated resources cannot be shared with other customers. Very different in a shared Cloud, where the provider can quickly reassign resources from one client to another. IBM Cloud Managed Services reduces the provisioning times for new systems from months to days.

For more information, check out

• Choosing a partner for enterprise cloud production workloads
• Thoughts On Cloud Blog

SCRUM in 6 minutes

Check out this 6 minute overview of what SCRUM is. It shows the value of adhering to the method. And it does away with the myth that Agile is all about chaos and disorder.

(yes, there is a little advertising for a book in the video, but it is still worth the time)

Link to the video