This article is going to show what are common approaches to move from a classic ICT infrastructure to a newer technology (like containers or cloud) for enterprises. In our posts we have already tested simple docker installations in small hardware (for example here) as simple projects examples (for example here). Now I’m going to list some of best pr
Switching to a new technology: why and when
Industries have been placed for years on infrastructures based on Virtual Machines (VMs). Over the years, this approach solved needs to allocate datacenter computing/storage power to these servers (and applications) who needed. Another problem solved by virtualization was to simplify servers backup and restore operations, including disaster recovery processes.
In the last years technology saw the rising of a new concept of thinking application management: the introduction of containers have meet developers needs to speed up deploy process and simplify application testing. On the other side, not all enterprises were ready to adopt containers. This could require a deep revolution both to development approach and application management which requires effort.
However, containers are going to fit better some ICT needs and answer to more pressing requirements in terms of:
- Better resources usage
- Improve time to market
- Improve security
- Simplify scalability
That said, many companies are watching containers step as a must for their future infrastructures, but they are also asking how to approach this great change.
Preparing the change: assess needs before technical solution
Before starting the change process, some considerations are needed. A typical error is thinking a change only as a process to reach a specific technical solution. This is, IMHO, the biggest (and most common) mistake. Every change should start from focusing the needs that drive the change itself. Questions should be like:
- What changed in my market/business? What are new needs?
- What are the key stakeholders? (both internal and external)
- What are possible solutions?
- What are pros and cons for each solution? (both economical and organizational)
- What could be possible collateral benefits
The best way to share these analysis could be issuing a Business Plan which deepens topics related to these questions.
Involve from very first steps all key stakeholders, which should be at least:
- Business Sponsors
- Technical support (for example engineers from your network, server, storage, security, etc)
- Developer groups
- External suppliers
Identify from beginning the Project / Program Manager. It is important that people know who to refer and ask questions or doubts. Another very important think is Management commitment. People give importance to a project if Management commit this importance.
Be focused to approach this project using all best practices used in Project Management literature. Many guide lines can be acquired from a Prince2® and/or PMI® approach. Remember that the product of this project is technology migration and not the technical solution.
Initializing the change: evaluate the steps, identify actors, plan the move
The most common way to conceptually organize the macro tasks is using the so called PDCA (or Deming Cycle) approach. As defined in Wikipedia (ref. https://en.wikipedia.org/wiki/PDCA) “PDCA (plan–do–check–act or plan–do–check–adjust) is an iterative four-step management method used in business for the control and continuous improvement of processes and products”:
Here below a short description for main steps:
- Plan: fix objectives and processes required to deliver the desired results.
- Do: execute the planning coming from previous step.
- Check: data and results gathered from the do phase are compared with expected results.
- Act: (Also called “Adjust”) improve processes realized in the previous steps. This phase also gives the records to mind for starting the next recursive Plan step with a better base-line.
You can use this cycle both for whole project as for smaller work packages.
From tehnical side, there are many migration strategies available to face an ICT migration. Personally, I found strongly applicable in our context those one commonly used in migrating to cloud solution. My suggestion, before starting each approach evaluation, is starting with applications split: to simplify actions, divide each application in smaller frameworks (each one with a defined set of inputs and outputs) that you can manage easier. This way can be also useful if you are trying to standardize some functionalities or some features to compose a base common framework. Following the good schema provided from Netapp (Ref. https://www.netapp.com/us/info/what-is-lift-and-shift.aspx), migration strategies can be then summarized as following:
- Rehost or “lift and shift”. You rehost your application in destination environment without changing the app’s architecture. Migration is fast and relatively inexpensive, but ongoing operation can be costly because you’re not leveraging cloud efficiencies.
- Refactor or “Lift, Shift, and Optimize”. You run your apps on a cloud provider’s infrastructure. Developers can reuse languages, frameworks, and containers leveraging code that’s strategic to the company. The downside is missing capabilities, transitive risk, and framework lock-in.
- Revise. First, you support legacy-modernization requirements by modifying or extending the existing code; then take the rehost or refactor route to the cloud. This means you can leverage new technology advantages, but not without some upfront development expense.
- Rebuild. You throw out the code for an existing app and rearchitect it. The advantage is access to innovative features that improve developer productivity. The price you pay is either lock-in or abandoning your application assets if the situation becomes unacceptable.
- Replace. Discard your existing application set and start a new development project for those features. When requirements for a business function change quickly, this approach avoids the time and investment of mobilizing a development team. But you may face issues like inconsistent data semantics, difficult data-access, and vendor lock-in.
Plan the move
Collect stakeholders needs and start identifying tasks and an overall plan. Prepare a RACI matrix: people need to know what/when to do and what they can expect from others. A good plan should trace, beside tasks duration and effort:
- Tasks responsibles
- Critical path (and what tasks can affect project duration)
- Max task flexibility
- Milestones regarding point of controls and periodic meetings
Avoid big tasks, they only make you lose control of how thinks are going. A good plan should foresee at least 1 Management work progress meeting and at least 2 technical work progress meeting. These meetings should include only really involved people and eache meeting must finish with a meeting note sent to all other people. I’ve seen tons of meetings with 40-50 people which have derived to off-topics. All off-topics are waste of time. Meeting note must trace what done, all critical facts happened, issues still open, issues closed and solutions adopted, next tasks from plan with owners. People must also have clear that issues must be showed in these meetings already with options including Pros and Cons for each option.
Identify Key Performance Indicators (KPIs) that can easily summarize project progress. They should be easy to calculate and expressive. Think also KPI management itself as a project: costantly check that they are correctly expressing work progress and edit them.
Control the change: monitor, tune, restart
Stay tuned on your project progress. Check frequently tasks owners before the task finish.
Don’t be spammy. Remember people the basic of how they should use e-mails. The most important rule, even if often not clear, is tho use correctly “to” and “cc” fields. “To” field must include only one or very few people: my old boss once teached me “if you don’t want answer, you must write to all people”. Also “cc” field should be used in the right way. CC should include people that could act if something is going to be wrong and not to inform others that responsibilities must go to someone different from mail sender.