Make your team fit for developing an Azure solution.
The customer commissions you to provide supporting architecture and development services for applications based on client/server and legacy/mainframe technologies that are to be migrated to a cloud-based service infrastructure as part of a migration project.
These applications have been developed in different programming languages. Due to the business logics/system architectures, they need to exchange large volumes of application data with one another.
Many different interfaces to, in part proprietary, peripheral systems, as well as to database, web and application servers, exist for this purpose. To facilitate communication and the exchange of data, the applications are interlinked over a bus system. Under these conditions, it cannot be assumed that a full migration will be achievable.
There is a strong probability that a hybrid (i.e. a partially cloud-based) solution will have to be implemented.
Even if there is a chance that a 100% migration can be realized, it is necessary to assess whether an iterative integration over several hybrid intermediate stages would not be more advantageous.
Assumptions about the security needs in the context of the solution have to be made, which among other things will decide whether the databases are to be moved to the cloud as well.
We begin by pinpointing the key factors for a successful migration, as these will determine the Trivadis procedural model that is outlined in the second part.
Special characteristics and cloud-specific challenges:
- BUSINESS CRITICALITY
Today's trends and pressure from providers are pushing companies to "finally move into the cloud". If, however, a technically extremely complex legacy application meets the prevailing business and user requirements, migrating to the cloud just for the sake of it will not make any sense.
The advantages of a migration must be worked out from a business perspective in the first step of the evaluation, because although it may be technically feasible to migrate an application, the associated costs, time, and risks may mean that it would be better to redevelop the application instead.
- NOT EVERY LEGACY APPLICATION IS TECHNICALLY “FIT” FOR THE CLOUD.
The benefits of a successful migration speak for themselves: greater agility, scalability, accessibility, cost effectiveness, etc. However, while it has never been so easy to create new solutions in the cloud, enterprises are faced with the problem that legacy applications which have been developed in-house can complicate a migration:
- The main reason for this is that many legacy applications have been developed for a local network with a high bandwidth and low latency times.
- Not only that, but these applications are even today still not web-based, and
- they build on a multi-tier architecture, which makes a migration much more complicated.
And even if a technical migration is actually possible, migrating to the cloud may be disadvantageous without a prior understanding of the cost situation and the impacts on security and performance. This requires an evaluation step which may result in an application not being migrated.
- NOT EVERY CLOUD IS SUITABLE FOR THE APPLICATION OR BUSINESS DOMAIN (AND VICE VERSA)
To find the suitable cloud, some questions have to be answered, such as:
- Is the application suitable for a specific cloud?
Feature-wise, cloud solutions can diverge to a huge extent. Example: Does the application really need to provide the service for thousands of VMs in the shortest time possible? Is it really necessary to pay for the mandatory managed service package?
- What capacities and scaling attributes are expected?
- How do the present operating costs compare to those for the cloud?
- Does the cloud perhaps not offer all the required features? Are there any workarounds? When are these gaps closed?
- Are the current (development) tools compatible? Which ones can continue to be used? What about the training requirements?
- INFLUENCES OF THE ARCHITECTURE AND DESIGN
Many legacy applications date back to a time when the internet, services, or even the cloud, did not play a role. This regularly leads to dependencies that make a simple migration impossible.
Examples of this:
- The need for local authentication
- Strong dependency on local databases
- Mainframe applications
Furthermore, many of these applications are linear, single-threaded transaction systems, which scarcely benefit from the advantages of the cloud (in particular dynamic scaling), and the usual performance boost fails to materialize.
- PERFORMANCE EXPECTATIONS, SLAs
Commonly encountered legacy client-server protocols are yet another factor. These protocols are not designed for the web or cloud, and are based on a fast and, so to speak, instantaneous local network. All the performance-related impacts of a migration have to be taken into consideration in advance to at least maintain the performance, to ensure satisfied users, and to safeguard the ROI.
- SECURITY AND COMPLIANCE
The risk associated with data loss or even data theft has long been an obstacle to using cloud technologies. A migration to the cloud must attain the security level of the old application, or ideally exceed it. Potential access by government organizations in particular must be considered here, which may result in a redesign of the topology for the data providers and data flows.
The procedural model at Trivadis.
Our approach is derived from the aforementioned aspects. The illustration below shows all the relevant theme areas that come to bear in the scenario.
A comprehensive migration project extends over five levels. The procedure is horizontally oriented, i.e. we follow the steps in the following sequence: Analysis & Review → Design & Architecture → Plan & Manage → Deliver & Assure.
Trivadis supports you at every stage and in all the theme areas in this matrix. We assume that the commercial aspects of the migration, including the definition of the business case, lie with the customer, and not in the task area. The horizontal track "Commercial" will therefore not have a direct focus.
All the other horizontal tracks, on the other hand, contain more technical aspects of the scenario. A particularly significant factor with the solution architecture is how the integration between cloud-based and non-migrated components is implemented.
Here, the bus topology is usually modified. In the simplest case, it can likewise be moved to the cloud. In more complex scenarios, the non-migrated components stay on the old bus, while the migrated components are adapted and then communicate with the old bus. Today, this is done predominantly using standardized tools and products from the cloud provider. Whenever possible, we try to pave the way for a transition to micro-services and API apps, i.e. during the migration we examine how the data flow can be switched from XML to JSON,
which SOAP APIs will need to be converted to ReST APIs, and whether a switch to iPaaS can be conducted during the project.
The need for support at the organizational level is not quite evident. Alongside those issues that are directly relevant to the implementation, Trivadis can also assist in preparing your employees for the introduction of cloud technologies. Trivadis also offers cloud boot camps for this purpose, for example for Google and Oracle cloud-based Azure and cloud projects in Java environments.