The users are happy in the cloud user land. The SaaS application is always available.
Then one day the application is replaced with a new version. It's not working as it should. As you would expect:
- SaaS users howl that they can't make timely business decisions.
- Developers groan that their frantic solution fails.
- Technical maintainer moans that network latency (explained later) is very high.
Howling SaaS users are directed to the wrong URL location when they click on a link in the new SaaS application. The users are impatient with slow response from the application.
Groaning developers discover too late an SaaS application version of all or some components of the legacy systems consumes all the resources in the cloud. The number of components that duplicate same functions is excessive, wasting much of the resources.
- Tightly coupled couldn't be converted into loosely coupled components.
- Component dependencies in the legacy system are very complex or outdated.
- Source code for the legacy system has been patched and re-patched excessively, making decomposition difficult.
- Service components have been restructured for the wrong target operating system.
Developers couldn't find the documentation on how service components are related to one another; it's missing or very outdated. They aren't familiar with legacy application development technology.
Developers forget to:
- Change the URL locations when they restructure the components.
- Factor in new user and business requirements.
- Not mix code written for 32-bit service components from the legacy system with the code written for 64-bit service components.
- Avoid multithreading restrictions of language interfaces (for example, COBOL interfacing with Fortran and C/C++ subroutines).
Moaning technical maintainer discovers:
- Resources assigned to developers are fully consumed.
- High network latency is contributing to the SaaS application's slow response to the users; the round-trip time of sending a packet that's returned to the sender is high.
- The SaaS application doesn't have multithreading features that would have lower network latency.
The technical maintainer finds three contributors to high network latency:
- Large packet: Takes longer to receive than a shorter packet.
- Medium type: Optical fiber, wireless or some other medium introduces some delay.
- Router delays: Each gateway node takes time to examine and change the header in a packet (changing the hop count in the time-to-live field).
To make matters worse, the maintainer doesn't have in place:
- The threshold policies on data requests, users and resources (explained later).
- Documentation on troubleshooting.
- A cloud failover policy (see Resources).
Go proactive with PaaS
As part of the recovery process, the developers go proactive. They first meet together virtually to plan a life cycle of four stages.
- Life cycle stage 1: Discover benefits of decomposing a tightly-coupled legacy system into loosely-coupled service components on the PaaS to make SaaS applications.
- Life cycle stage 2: Build an SaaS application using service components decomposed from the legacy system while sharing technical skills virtually.
- Life cycle stage 3: Test the SaaS application with SaaS users who are co-residents on the PaaS to determine if it meets the users' (as well as developers') expectations, including fast response (low network latency).
- Life cycle stage 4: Migrate the SaaS application to the production environment and ensure the network latency remains low.
Stage 1: Benefits of decomposing a legacy system on PaaS
The benefits of decomposing a legacy system into service components — procedural, functional and data — on the PaaS is that at a minimum, developers can:
- Work as a virtual team.
- Share skills virtually.
- Test SaaS applications virtually.
Benefit #1. Virtual teamwork
PaaS developers can get together as a virtual team from different locations. They aren't restricted to be physically present at a data center to decompose a legacy system on a mainframe.
As a minimum, the virtual team can determine which parts of the tightly coupled legacy system can be:
- Extracted as components based on their functionalities.
- Discarded as components with unaccepted dependencies.
- Reused as service components with accepted dependencies.
- Combined as a single service component with one service functionality.
- Reconstructed as loosely coupled service components.
- Organized as a hierarchy of service components.
Developers' choice is based primarily on:
- User requirements.
- Characteristics of the target operating system environment.
- Skills in untangling component dependencies.
- Availability of documentation.
Benefit #2. Virtual sharing of skills
PaaS developers can share their technical skills virtually. Not all developers have all the skills they need to decompose legacy systems.
For example, few developers in the team are familiar with:
- Legacy application development technology.
- Language interface issues (for example, multithreading and program restrictions).
- Conversion to 64-bit service components from a 32-bit legacy system.
Benefit #3. Virtual application testing
PaaS developers with varying skills can virtually develop and test the SaaS application on the PaaS with SaaS users as co-residents. The developers can use feedback from SaaS users to determine if the test results are what the SaaS users expect.
Once the developers successfully complete the test, they can:
- Certify the service components in the SaaS application have been restructured with accepted dependencies.
- Migrate the SaaS application to the production environment.
- Negotiate with the technical maintainer on the terms and conditions in the Service Level Agreement for this application.
Stage 2: Make SaaS applications from decomposed legacy system
At a minimum, there are four things to consider on building SaaS applications from decomposed legacy system on the PaaS:
- Expectations from users, developers and technical maintainers.
- Cloud service types: private, public and hybrid.
- Extracting service components from a legacy system.
- Threshold levels.
- Orchestrating service components.
First, consider the expectations from end users, developers and technical maintainers. Then choose whether the SaaS should run from a private, public or hybrid cloud.
Next, extract service components from a legacy systems on the PaaS, and combine them into fewer single service functionalities with accepted component dependencies as part of the application.
When building the application, develop threshold levels at the resource, data request, and user request levels. Once these levels are known, reconstruct service components to reduce further dependencies. All redundant service components are combined into fewer single service functionalities.
Then orchestrate service components in an SaaS application to make sure they work as intended. The orchestration should show the open API included in the application has been successfully integrated with third party legacy web services or open source web services.
Let's suppose some service components were extracted from a legacy system and restructured as loosely coupled service components with accepted dependencies and fewer functionalities in a SaaS application. You should determine if these functionalities are what the user expects.
Let's look underneath the user interface to discover what developers and technical maintainers are doing to make those user expectations occur.
All users are happy with the application. Everything is running smoothly. The application is always available. The user can scale up and down the application without issues. He always gets information very quickly to make important business decisions or continue business operations. He assumes the service components from a legacy system were easily and smoothly extracted into a SaaS application. He rates the provider as having a good business reputation — reliable, fast, secured, and efficient.
To make user expectations happen, a virtual team of developers can expect the ease of developing an SaaS application from service components in a legacy system. The application in the cloud is stateful from one service component to another, has been properly fixed with a new version, and will run on a different target operating system (Windows to Linux). It is fast and responds quickly to users' requests and scale up and down smoothly and without issues.
Technical maintainer expectations
Another party to make user expectations happen is the technical maintainers. They are usually the providers or third parties for the providers. They ensure that technologies are properly used to migrate to the production environment the SaaS application that was successfully tested on the PaaS. Ensuring good performance is important in maintaining the provider's good business reputation as reliable, fast, secured and efficient. Poor performance can result in unexpected service outages that leave:
- Users stranded without the information they need to make important business decisions.
- Developers stranded in the middle of application development, further complicating efforts to resolve component dependencies.
Private, public or hybrid cloud?
The criteria to determine whether an SaaS application should be developed on a private PaaS includes:
- Data can't go outside the public PaaS provider (data sovereignty issues).
- Security requirements (highly sensitive information) can't be met by the public PaaS provider.
- Network latency requirements (particularly for large files) can't be met by the public PaaS provider.
- Application architecture doesn't meet requirements of public PaaS providers.
Another criterion is that the companies and government agencies might want tight integration with sensitive back-end systems (legacy systems not being decomposed). They might find that:
- Tight integration is technically impossible with a remote system.
- IT department is uncomfortable about creating holes in the firewall that would permit an outside server to initiate actions on internal systems.
All SaaS applications should be developed on the private PaaS. When the SaaS application testing is successfully completed, the developers can migrate the SaaS application to the private, public, or hybrid cloud's production environment.
Extract components from a legacy system
The ease of extracting service components in a legacy system depends on how the source code was written and how it was patched and re-patched to fix bugs and logic.
Untangling the component dependencies while avoiding excessive fragmentation of the legacy system might be a daunting task. The complexity of this task depends on the skill levels of the developers. Once the dependencies are found, the developer can opt to accept, reject, or combine them.
Accepting dependencies doesn't always result in accepting a service component as is. This component may need to be restructured with accepted dependencies. Combining dependencies might result in fewer service components.
Then organize the service components in a loosely-coupled manner in a hierarchy. The relationships of one component to another depend on the functionalities of each component.
Set threshold levels
When building the application on the PaaS, develop threshold levels at the resource, data request, and user request levels.
What are these thresholds anyway?
- User threshold level sets the maximum number of users concurrently accessing the application that consists of accepted or restructured service components decomposed from a legacy system.
- Data requests threshold level sets the maximum number of data requests that users can concurrently sent to the SaaS application.
- Resources threshold level sets the maximum amount of resources (for example, CPU, storage devices, disk space) that can be allocated to each SaaS user, PaaS developer, and IaaS network specialist.
Who sets threshold levels?
Setting the threshold levels depends on the control variables assigned to the SaaS, PaaS and IaaS users and providers.
- SaaS user
- The end user doesn't set any threshold levels. The only control the user has is to access the application from either the provider or the PaaS developer from a desktop, laptop, or mobile.
- SaaS provider
- The provider sets the user threshold level. At a minimum, the provider controls operating systems, hardware, network infrastructure, SaaS application upgrades, and patches.
- PaaS application developer
- The developer can set the data request threshold at the SaaS user level for SaaS users who are co-residents on the PaaS. The developer controls the development of all SaaS applications of loosely coupled service components with accepted dependencies in a full business life cycle, and runs them on the PaaS. The developer manages, upgrades, and patches to all functionalities of this application. As part of the business life cycle, the developer uses spreadsheets, backups, and billing.
- PaaS provider
- The provider sets the data request and resource thresholds at the developer level. At a minimum, the provider controls operating systems, hardware, network infrastructure, and resource management.
- IaaS infrastructure and network specialist
- If the specialist hosts the PaaS, he may set the user and data requests for the PaaS developers. The specialist controls the operating systems, network equipment and deployed applications at the virtual machine level.
- IaaS provider
- The provider sets user, data requests, and resource threshold levels. At a minimum, the provider controls the infrastructure of traditional computing resources in the cloud environment.
Stage 3: Test the application
As part of application testing, orchestrate these components in a SaaS application to make sure they work as intended. If application testing fails, the developer needs to resolve:
- Orchestration issues.
- User, data request and resource threshold issues.
- Component dependency issues.
The developer can also:
- Resolve load balancing issues.
- Change target operating system or make any operating system neutral.
- Update documentation.
If these components need to be connected with other SaaS applications that are available remotely, make sure network latency is low to speed up application response to users' data requests. To help keep network latency low, consider:
- Prefetching (anticipating the need for data input requests).
- Multithreading (using parallelism across multiple execution threads).
If open APIs are included in the SaaS application, the orchestration should show the open APIs have been successfully integrated with third party legacy web services or open source web services.
At a minimum, there are three reasons for including APIs:
- Data export capabilities to take the data out.
- Social media integration (Facebook, Twitter, and Google Maps, for example) to help retain existing and get new SaaS users.
- Integration with a legacy system with remaining components that have not been extracted.
Stage 4: Migrate the SaaS application to the production environment
After you migrate the SaaS application to the production environment, you need to make one more test. Make sure the application that worked well on the PaaS behaves well in the production environment; network latency remains low with little or no load balancing issues.
Then you can use IBM WebSphere Cast Iron Cloud Integration to connect the application to the hybrid world of public clouds, private clouds, and on-premise applications. It frees up scarce resources and can assemble and publish API web services, and allows the providers to update their APIs.
Extracting components from a legacy system, building the SaaS application from these components, and testing the application for component dependencies and network latency issues on the PaaS require collaborative efforts from a team of developers, users, business analysts, and technical maintainers. It requires planning ahead to migrate the SaaS application and handle the issues of component dependencies, load balancing, and network latency, without resulting in system overloads. Orchestrating the service components (accepted or restructured) that are organized in a hierarchy is a more flexible way of:
- Analyzing issues with service components and their dependencies.
- Combining redundant services, if any, into single service functionalities.
- Resolving issues with threshold levels and network latency.
You will find that resolving the issues makes your job of decomposing a legacy system on the PaaS to build a SaaS application much easier.
- Find out more about network latency in the report Spec Open Systems Group: Cloud Computing Working Group.
- Read Judith Myerson's article Build proactive threshold policies on the cloud to discover the impact of purpose, scope, background, consumer control, actions, and constraints of threshold levels.
- Take a look at Judith Myerson's article on creating a failover policy with cloud specific-riders. The article details components and tasks.
- Get more information about IBM WebSphere Cast Iron Cloud Integration.
- Learn more about cloud computing technologies at cloud at developerWorks.
- Follow developerWorks on Twitter.
- Watch developerWorks demos ranging from product installation and setup demos for beginners, to advanced functionality for experienced developers.
Get products and technologies
- Access IBM SmartCloud Enterprise.
- Evaluate IBM products in the way that suits you best: Download a product trial, try a product online, use a product in a cloud environment, or spend a few hours in the SOA Sandbox learning how to implement Service Oriented Architecture efficiently.
- Get involved in the developerWorks community. Connect with other developerWorks users while exploring the developer-driven blogs, forums, groups, and wikis.