Monthly Archives: August 2020

Prepare for AIX Migration to the Cloud

AIX in the cloud is now a “thing”.

When moving your AIX workloads from on-prem to the cloud, there are two big-ticket items to initially consider for planning and execution:

Mapping Resources from on-prem to the cloud equivalent
Techniques for the actual movement of the images

Mapping Resources

First, get a list of all the LPARs that are candidates for migration and capture the essential attributes like CPU allocation, memory, storage , IOPS, and expected network bandwidth required for each server. If you attempt to do a straight “lift and shift,” you may or may not be able to do an exact mapping in a pure self-service model. Why? Because cloud vendors typically have “safety caps” on some resources that prevent an untrained cloud user, or a run-away automation script from doing unwanted actions.

Continue reading →

Quit hiding the cloud from your developers doing dev/test

If you say a person or organization “goes to great lengths” to achieve something, it means they try very hard and perhaps do extreme things to accomplish their goal.

One example of “going to great lengths” that I’ve seen with traditional companies is how they go to great lengths to “hide” the cloud from their pool of potential technical consumers doing work like development. Instead of saying, “here it is…” they block or restrict users from direct consumption. Developers don’t directly login to Azure, AWS, or Skytap, they go to the “internal corporate portal” and fill out a web form of what they want and submit it. Then someone will eventually process it and create what is needed.

Continue reading →

Chaos Engineering for Traditional Applications

Not all on-prem applications have a future in the cloud, but can those same on-prem applications leverage cloud-like capabilities to help make them more reliable?

In 2011 Netflix introduced the tool called Chaos Monkey to inject random failures into their cloud architecture as a strategy to identify design weaknesses. Fast forward to today, the concept of resiliency engineering has evolved, creating jobs called “Chaos Engineer.” Many companies like Twilio, Facebook, Google, Microsoft, Amazon, Netflix, and LinkedIn, use chaos as a way to understand their distributed systems and architectures.

But all of these companies are based on cloud-native architectures, and so the question is:

Can Chaos Engineering be applied to traditional applications that run in the data-center and will probably never be moved to the cloud?

Continue reading →