Four ways to get ready for Power Systems Virtual Servers in IBM Cloud

Are you investigating running your AIX or IBM i workloads in the cloud, but don’t know where to start? IBM Power Systems Virtual Servers in IBM Cloud provide significant value as an addition to your on-premises IBM Power Systems environment. Running AIX or IBM i workloads in the cloud makes it easy to use a pay-as-you-go model, handle seasonal bursts in computing demand without standing up hardware first, and transition from old hardware requiring expensive maintenance contracts.

If you’re intrigued by Power Systems Virtual Servers and wondering how to get ready for it, here are four tips for a smooth start with this new technology.

1. Know the solution

Some of the most common questions I get from clients are:

◉ How is IBM i or AIX running in the cloud?

◉ What does it look like?

◉ What is included, and what do I have access to?

◉ Where’s the documentation?

How is IBM i or AIX running in the cloud? AIX and IBM i workloads in Power Systems Virtual Servers are running in VMs (LPARs) on POWER9 processor-based hardware in IBM Cloud (existing POWER8 servers in some locations will be upgraded to POWER9). Those POWER9 servers are managed by the PowerVM hypervisor, virtualized with dual Virtual I/O Servers and NPIV-connected to Fibre Channel-attached storage. In other words, they’re using the same best practices as Power servers on-premises, but with the latest technologies (as of the time of this writing).

What does it look like? The best way to get an introduction is in this video. I recommend watching the whole recording, but the demo starts about 30 minutes in.

What’s included, and what do I have access to? Power Systems Virtual Servers are an infrastructure-as-a-service offering. What’s included is uptime of the underlying infrastructure and the operating system (IBM i or AIX) in each VM/LPAR with certain licensed program products. What you have access to is the IBM Cloud UI and APIs for managing the VMs and storage, as well as full access to the operating system within each VM. There’s no direct access to the Hardware Management Console (HMC), Virtual I/O Server or storage array.

Where’s the documentation? Start here and peruse all the topics in the “Learn” section on the left. Then proceed to the AIX- or IBM i-specific sections or the FAQ further down for specific answers.

2. Know your workloads

Consider the business criticality of your workloads, legal requirements and recovery point and time objectives (RPO and RTO). You want to start with applications that score lower in those categories. But let’s dig a little deeper. Power Systems Virtual Servers have minimum operating system (OS) levels for both IBM i and AIX (details here). You should create an inventory of likely migration candidates from a business standpoint and then compare them against the OS requirements. For those VMs/LPARs that don’t meet the requirements, it’s worth investigating the effect an OS upgrade would have on the applications running in those VMs. Last, consider the downtime available for each VM to migrate it, as some downtime will be required to save it on-premises, transfer it to and restore it in the cloud.

3. What about backups and HA/DR?

Appropriate backup and high availability/disaster recovery (HA/DR) options are must-haves for most AIX and IBM i workloads. Because backups are usually performed from within the OS, most of the options that exist on-premises are present in Power Systems Virtual Servers as well. However, the overall save and restore process has some differences and involves additional configuration and a bit of a learning curve. Keep in mind that physical tape drives or libraries are not available in the cloud. From an HA/DR standpoint, a key difference is that storage-based replication, which is the norm for many Power Systems clients, is not available with Power Systems Virtual Servers. HA/DR options for both IBM i and AIX involve logical or OS-based replication.

4. We have to talk about the network

How will these AIX or IBM i applications in the cloud be accessed? Do you need console-, interactive user- or application-level communication between your on-premises and Power Systems Virtual Server environments? Are you planning on using replication between your data center and the cloud for DR? These are all questions that will influence the network design and cost of your Power Systems Virtual Server solution. Multiple connectivity options exist. Finally, consider any non-Power Systems Virtual Server services or workloads you might want to use or have running in IBM Cloud. Having a complete multiplatform business solution in the cloud is one of the great benefits of Power Systems Virtual Servers, but it should also factor into your network planning.

Running IBM i and AIX in the IBM Cloud enables significant business opportunities for additional agility and growth. At the same time, it’s a new environment that carries a learning curve and requires thoughtful planning to use optimally.

Source: ibm.com

Continue reading

Engineering Ecosystems Architectures

Looking back, it’s possible to remember the rise in interest just before Objects and Object-Oriented Design were formalised. At the time many professionals were thinking along similar lines and one or two were applying their ideas under other names, but, in the final analysis, the breakthrough came down to a single act of clarity and courage, when the key concepts were summarised and labelled in an acceptable way. The same was true with Enterprise Architecture. By the time the discipline had its name, its core ideas were already in circulation, but practice was not truly established until the name was used in anger. So, in many ways, naming was the breakthrough and not any major change in ideas or substance.

With hindsight it’s now clear that such naming events have little to do with changes in approaches to problem solving, but lots to do with the increasing scale and complexity of the challenges that drive them. Both are side effects of general technical progress. As we become more proficient with a tool or technology, we generally learn how to build bigger and better things with it. Be they bridges, skyscrapers or IT solutions, the outcomes are largely accepted as business as usual. What really matters is that the tools and techniques used for problem solving evolve in kind as demand moves onward and upward. For that reason, when a step change in demand comes along it is normally accompanied by an equivalent advance in practice, followed by some name change in recognition. For instance, IT Architects talk of “components”, whereas Enterprise Architects talk of “systems”. Both are comparable in terms of architectural practice but differ in terms of the scale and abstraction levels they address. In this way, IT Architecture focuses on solutioning at the systems level, whereas Enterprise Architecture is all about systems of systems.

Interestingly, the increases in scale and complexity responsible for Enterprise Architecture were themselves a consequence of advances in network technology, as platforms like the Internet and World Wide Web catalysed progress. This trend has continued with movements like social media having a profound impact on business. So much so that today conventional definitions of “the enterprise” are being challenged, as businesses enhance their capabilities with resources from outside their organisation. This is driving a need for solutions that reach beyond traditional enterprise networks and out into the broader digital ether. We are therefore seeing the next step change to face IT Architecture and again the profession is awash with emergent practice. We even have a name for it already. When networks spread beyond the influence of any single entity or system we generally call them an “ecosystem”. All that remains is for the realisation to dawn: the era of Ecosystems Architecture is upon us.

Enterprise Architects have been familiar with the idea of ecosystems for some time and the pressing need to describe networks of systems working towards shared goals. This is no longer a matter of debate. What is still up for discussion though is how we establish credibility in this new era? Past lessons point to some likely answers, and common sense reminds that tried and tested approaches tend to hold value when modified to embrace change. Nevertheless, this time around the change involved brings with it at least one significant difference. Whereas previously, building things bigger and better typically involved more cost, time and effort, advances in information technology have produced the opposite effect. Today, users expect their IT to be delivered ever quicker and at lower cost, and in response professional practice has evolved to become ever more agile and cost efficient. So, given that previous generations of problem-solving techniques have relied less on being reactive to changing demand, perhaps the jump to ecosystems architecture presents more of a challenge than at first sight?

It is therefore considered that a lightweight framework of pragmatic architectural best practices will be fit for purpose. At its core it provides a surprisingly elegant set of tenets that allow multiple delivery styles to mix and match without conflict:

1. Coverage: Ensure that the portfolio of connected parts is sufficiently covered and understood across all design and delivery activities. Depth is not as critical as breadth, but all parts (networks, systems, components, etc) must be identified and adequately positioned within any broader architecture.

2. Skills & Leadership: Ensure that adequate skill levels are available to address all identified needs. This applies across all known contexts and abstraction levels, and should safeguard technical direction across the entire systems lifecycle. Coverage should be at the significant part level (every justifiable part deserves a capable technical owner across its life).

3. Semantics: Create a scheme for naming parts at different abstraction levels and stick to it. Established convention, such as “network:arbitraryName”, “system: arbitraryName”, “component: arbitraryName”, etc, is perfectly acceptable.

4. Architectural Decisions: Ensure that an accurate record of technical choices is maintained and accessible. This is to ensure the viability of future decisions and help build a body of knowledge in support of future practice.

5. Operation: Ensure that justifiable method(s) and tooling is applied. This should provide guidance when needed and support essential feedback loops, such as decision making and knowledge harvesting.

6. Building Codes & Regulations: Ensure that architectural decision makers follow relevant guidelines, rules, and standards. These must comply with all applicable constraints, like external legislation, ethical consideration, security pressures and so on.

To understand the value these tenets might offer going forward, it’s perhaps worthwhile finally pausing to consider what IT architectures at the ecosystems level actually look like. The following list came out of some recent work at IBM and is not intended to be exhaustive. Nevertheless, it hopefully provides a taster of what lies ahead:

1. Functionality: Participating parts must be able to do something that contributes to all, or part, of the ecosystem

2. Communication: Participating parts must be able to communicate and co-ordinate resources with other parts, either within their immediate context (ecosystem, sub-network, system, etc) or outside of it (system, wider-network, complete-ecosystem, environment, etc). Parts must possess amplification and attenuation capabilities to suit

3. Controls: It must be possible to control the ways in which participating parts group (structure), communicate and consume resources in a common or mutually agreed manner

4. Awareness: An ecosystem must support instrumentation and observation at both participating part and higher-group levels. This includes implicit awareness of its environment, given that this can be considered as both a unit and group participant in the ecosystem itself

5. Regulation: An ecosystem must support constraints at the group level, that guide it to set policy and direction

6. Adaptability: Participating parts and higher-level groups must be able adapt to variance within the ecosystem and its environment

7. Support and Influence: Participating elements must be able to use resources supplied from other participating elements, groups and/or the environment itself

8. Self-Organisation: Structures must allow self-similarity (recursion/fractal) at all scales and abstractions

Source: ibm.com

Continue reading