Cloudy with a chance of apps

There are many reasons for looking towards the cloud. For example, many customers want to migrate old applications to the cloud because their on-premises hardware is outdated. Other customers want to start new projects directly in the cloud to benefit from the modern technologies and the many advantages. Often, outdated applications also need to be modernised, and these should then also be able to exploit as much cloud potential as possible with as little adaptation effort as possible.

Since the reasons are so diverse and the paths so numerous, a well-thought-out and holistic approach is required. Only when it is clear to everyone involved why the path to the cloud should be taken can it be taken and success measured. Only when the necessary steps are known can it be decided who can provide what through their own efforts and training needs or through external services. Long-term success can only be achieved if an agile roadmap with foresight and reasonable budget planning is created.

To cover all these aspects, adesso has developed an agnostic process model. On the one hand, it is based on our many years of experience with our customers. These customers were always at different points on their individual journey, were represented in all sizes and came from all the industries we serve. Regulatory environments and planned certifications had just as much of an influence as the respective corporate culture. On the other hand, the process model takes into account the adoption frameworks of the three major hyperscalers (Azure, AWS, GCP) and their best practices. The model is regularly compared with the recommendations of the hyperscalers and maintained and expanded by the numerous adesso employees.

The following graphic shows the adesso process model for cloud adoption:

The process model is divided into three workstreams: Strategy, Environment and Workloads. Each workstream consists of a series of interrelated steps that fulfil a sub-goal of the adaptation. Depending on the customer's target picture, position in the cloud journey and technical conditions, we recommend that you go through all, some or only parts of the steps in the process model. The workstreams influence each other, so you should start with the Strategy workstream first. The other two workstreams start slightly later and then run in parallel.

Strategy workstream

The strategy workstream develops the objective, defines the framework conditions and makes all relevant decisions. Many of these topics can be addressed in the course of cloud adoption to enable an agile approach.

The first step is to develop a vision. This must be defined at the beginning because it influences all further steps. Once the goal is known, the following steps can be aligned with it and success can be measured against it. For example, if customers want to move to the cloud to relieve the burden on operations, attention is paid to the use of higher-value services and automation during migration and modernisation. If a system does not support these goals, it must be replaced and should not be moved to the cloud.

The second step is to define the operating model, which involves more than just deciding on the actual operation. It also includes questions such as when which clouds will be connected and what holistic security looks like. Often, certain cloud services are excluded or given preference at the beginning because experience is still lacking. This information then influences the migration strategy again, since not all services can be used, even though they may be the best fit.

After defining the operating objective, cloud enabling ensures delivery capability. It is checked what the customer wants to and can do themselves and where training is needed. For some tasks, it may make sense to buy in support from service providers, whereby the services can then also be gradually taken over by the customer themselves. It is often necessary to modernise or replace an existing toolset, for example to integrate metrics from the cloud.

Once operations are running smoothly, steps towards operational excellence should follow. This may involve taking on further tasks or onboarding additional services. The experience gained can now also be used to further refine the strategy and incorporate topics such as FinOps.

Workstream Environment

The Environment workstream deals with both the customer's existing legacy environment and the future cloud environment. It has a technical focus and benefits greatly from tools and scripts.

Discovery is the first step in this workstream. This is where the existing landscape is measured and examined for its technical cloud capability. The strategy should already have determined whether all applications are in focus or only individual areas or technical clusters. In this step, the tools of the respective hyperscalers are used, along with additional tools from other providers, to complete the picture. The result is a record of the landscape with a technical assessment of the cloud readiness of the applications found.

To avoid moving applications to the cloud in an unstructured and uncontrolled way, a framework must be created in which the applications are embedded. These are the cloud foundation and the landing zones. Both are designed in the foundation and landing zone design step. A cloud foundation contains structures that are relevant for all applications, for example connectivity, policy, monitoring, etc. The landing zones later contain the specific workloads. They can be specific, so a landing zone for SAP is different from landing zones for containers. The first landing zones are designed depending on the applications found or defined by the strategy.

During the foundation and landing zone setup, both are implemented accordingly. This is usually done through Infrastructure-as-Code, using building blocks from the hyperscaler and from the company itself. Some customers have already built up corresponding structures, in which case it is necessary to compare these with the design and start any migration projects that may be needed to bring the structures into a compliant state.

Finally, processes and responsibilities should be created that enable a sustainable improvement in cloud management. These include, for example, the aforementioned cost management, but also the evaluation of security findings and tool analyses. These results must regularly lead to activities that, step by step, also through automation, lead to an ever-improving cloud environment.

Workstream Workload

The Workload workstream focuses on applications and their future direction. It looks at both each individual application and a roadmap with several applications, transforming them according to their future purpose.

The technical data from the Discovery step is now supplemented by technical assessments in the Assessment. Technical data does not contain any information about an application's potential and does not identify any pain points. Furthermore, it cannot take into account any strategy or operational restrictions. Therefore, the assessment phase collects information that provides a complete picture of the application.

If the assessment has revealed a high potential for an application, a modernisation concept should be created in the conception and roadmap step. This contains the steps for redesigning the software to eliminate the pain points and exploit the advantages of the cloud. If such modernisations are not necessary or possible, migration concepts should be created. These range from simple lift-and-shift migrations to the use of higher-value services. If the landscape is homogeneous, a general migration concept can be created that is valid for all applications.

The individual migrations, concepts or transformation projects must be put into an implementation sequence – the roadmap – according to resources and strategy. This can extend over several years, divided into waves of tasks, with a certain degree of fuzziness in the more distant future. It forms the basis for long-term planning.

This roadmap is worked through in the migration and modernisation step. The work is carried out in defined waves. Depending on the resources and requirements, the waves can be carried out in parallel or in sequence. Often, customers expect a great deal of support in the first few waves in order to gain experience and then want to implement the later waves on their own. Depending on the company structure, several teams may be involved in the migrations, for example application management, IT operations, security, business users, etc. Careful coordination of the parties involved is just as important as suitable test cases and a hypercare phase.

Since applications are often migrated to the cloud via Lift&Shift or fewer metrics were known in the on-premises environment, there is still a lot of potential to exploit the advantages of the cloud even after the migration. This improvement is implemented in the App Optimisation step. After the migration, the correct sizing can be better determined or even an automatic scaling configured. Backup, patching and cost control are also often modernised after the migration to simplify operations. For some applications, a software optimisation can also be useful, for example by breaking down the application step by step into microservices. The optimisation steps should always contribute to the strategy, not be an end in themselves and, above all, not be forgotten.

Conclusion

The process model helps to identify known and unknown stumbling blocks and contains best practices for rapid and sustainable success. It is important not only to address the technical aspects, but also to consider the customer's journey and strategy. Only a customised roadmap that provides guidelines for the individual steps will lead to the desired success.

Would you like to learn more about exciting topics from the world of adesso? Then take a look at previously published blog posts.