Throughout the COVID-19 lockdown, it has become apparent that the way we use many of our in-country cloud deployments are still fairly “mantronic”. Service activities slowed as platforms were placed into brown-out or black-out change windows and service prioritisation limited to those few “Essential Services” organisations. Here are some reflections on recent developments that may be useful for your organisation.
Start preparing your environment to allow for automation
I don’t doubt that there were many heroic efforts to spin up environments urgently to meet the emergency needs, but surely if the toolsets used to deploy and manage infrastructure components, and also the overarching principles of automation are not appropriate, well established and well understood within our organisations the dependency on third parties will remain. Our heroes should be those preparing the environment now for automating scalable, on demand infrastructure and networking.
Now add Microsoft into the equation
Furthermore, with the recent announcement that Microsoft is planning on establishing an Azure Datacentre in New Zealand, the two significant constraints for adopting cloud services from the multinational cloud Hyperscalers have been removed. The age old question on data sovereignty and security classified data with regards to the Hyperscaler providers can hopefully be put to rest with the introduction of in-country storage… and the even older question on the limitations of the speed of light has also been partially addressed with latency decreasing and improving the closer you are to the proposed Azure site.
The benefits of adopting cloud continue to be compelling and irrespective of which model you choose to pursue, whether pure cloud in a Hyperscaler like Microsoft Azure or hybrid cloud with workloads operating on premise and / or in an established IaaS provider with legs into Hyperscaler services, there are a few considerations that if taken into account will make the step to cloud easier.
“Automation, scalability and availability are typically the advantages straight out of the box. However, don’t forget to ensure your sponsors are aware of the significant operational and cost benefits that must be factored into any Cloud business case. These benefits include platform and environment redundancy, datacentre security, cooling and clean power, hardware resiliency, as well as operational activities that no longer need to be funded out of your wages budget
The Cloud Business Case Conundrum
The business case for cloud has always been difficult to justify. Purchasing hardware is cheaper, but ensure you are in a position to justify and articulate well (and regularly) the massive operational benefits provider by IaaS and Cloud providers. Automation, scalability and availability are typically the advantages straight out of the box. However, don’t forget to ensure your sponsors are aware of the significant operational and cost benefits that must be factored into any Cloud business case. These benefits include platform and environment redundancy, datacentre security, cooling and clean power, hardware resiliency, as well as operational activities that no longer need to be funded out of your wages budget and the list goes on…
An opportunity to grow your team’s skills
Throughout any cloud transformation project, your engineering teams move from being hardware specialists, to business specialists. Their roles need to adapt and operate “further up the stack”, looking at how the business needs can be meet by the possible solutions available from Cloud providers. Furthermore, the Service Delivery Management role becomes increasingly important ensuring that SLA’s are met, and performance is as contracted. Preparing the team with training and a determined focus on your business solutions and how technology can support it is important and it is too late to begin when you are already in the middle of a cloud migration.
Your Service Catalogue will ensure service delivery accountability
But if there is one thing that helps with preparing for a cloud migration more than anything else, it is identifying infrastructure components as they relate to Business Services. Identifying your business services in a formal business service catalogue brings the structure and clarity necessary for cloud migrations and assists in identifying the areas that can benefit from re-architecture.
A service catalogue will allow you to better define your recovery and availability requirements per business service allowing you to have confidence in any backup or resiliency design being defined. Assigning business owners, technology owners and potentially data owners to each service enables accountability and agreement to be established within both the business and the technical teams. Finally, identifying infrastructure and application components that relate to each business service begins to build the picture of what services and components are related and how these need to be managed for future changes or any cloud migration activity.
Choose your migration strategy carefully – costs can escalate quickly
Finally, when planning your cloud adoption, one key decision that needs to be considered early on is whether you plan on undertaking a “lift and shift” or a “re-architecture onto” migration. A lift and shift has all your current infrastructure components simply moved to a cloud provider. You see immediate operational benefits with this strategy and likely a reduced migration timeframe. The intention of the “re-architect onto” strategy looks at provisioning new services in the cloud and then migrating the services not the servers. It is more of a cloud purist model as it adopts the latest cloud services but runs the risk of stalling as complexity is introduced. The worst outcome is to have started incurring costs for cloud services without decommissioning your legacy infrastructure essentially increasing cost but not yet releasing you from the legacy burden.
– Jason Fazackerley