Moving your data and workloads to the Cloud? Read our top ten frequently asked questions
Here, Peter Wilson, our Head of Technology Consulting Services and cloud veteran, answers the common questions around migrating to the cloud. When we talk about the cloud at Advania headquarters, what do we mean? Just this:
‘An environment away from your business location that is fully or partially managed by another party’.
As we specialise in Microsoft hosted systems, Pete references them this blog. This isn’t to say other public or private clouds aren’t right for your organisation. But we feel Microsoft technologies can address pretty much any requirement. Over to you, Pete!
Will our data be secure in the cloud?
A cloud service gives you more complete security options than an on-premise system could with the same budget. There are layers to cybersecurity and copious tools to achieve it. These tools could be around:
- Stopping external and internal attacks
- Governance around the data and compute concerning disaster recovery and versioning
- Continual monitoring, so that your systems are protected, and no issues are flying under your radar.
All are equally important, which is where the benefits of a large, multifaceted public cloud vendor come into their own. The tools in Microsoft’s Azure stack address these needs, and if you’re an SMB business, they’re in reach financially.
A single vendor’s security ecosystem has integrations that simply work, applying intelligence across the different elements of the Microsoft estate to highlight attacks before you are compromised.
What if you have specific requirements around external firewalls and need a common platform across your non-public cloud environments? The more traditional firewall vendors – Cisco, Fortinet, Palo Alto, etc., all have virtual appliances that fit into the Azure estate.
And unlike a traditional datacentre environment where responsibility for the security of the platform is yours, Microsoft lifts this burden from you. But be aware that the protection of your data remains your responsibility and you might require additional tools.
We know that trying to manage these requirements can be complicated. At Advania, our Velocity Landing Zone (VLZ) brings everything together in a standard, code-based solution for secure, faster cloud migrations.
Most of our people are working remotely now. Would migrating to the cloud improve our end-user device management?
Yes, is the simple answer to this question, but it’s not a case of moving your traditional device management products into Azure.
When performing Azure assessments, we often come across many management servers – like laptop backup or image management servers, anti-virus or encryption management, vulnerability scanners and SIEM (Security Incident and Event Management) collectors.
Commonly, the tools for managing and securing your end-user devices are replaced using the broader Microsoft ecosystem. We’ll use tools from the Microsoft Endpoint Management suite, the Microsoft Defender suite or Azure Sentinel, which is a cloud-native security information and event manager (SIEM) tool.
To allow for central management via Active Directory (AD) when users work remotely, there is a need for a VPN (Virtual Private Network). The VPN allows for synchronisation between the devices and AD environment when passwords expire and policies in AD change.
If your users’ machines are directly connected to Azure AD and configured to use the Microsoft Endpoint Manager tools, a VPN is no longer an issue for management anyway. Configuration and management of the devices are direct from Azure, removing the need for a VPN and simplifying your device management.
If you’d like more advice on this topic, you’re welcome to contact us.
Will our systems perform as well in the cloud?
The ‘lift and shift’ approach is one we often see our clients consider, and the answer is ‘possibly’. But a better question is why you would move specific workloads, say email, onto a server in Azure?
It’s usually much better to move into a dedicated service. Taking email as an easy example, this would be Exchange Online. But the same applies to many workloads in your existing environment.
Our approach is to look at your different workloads and identify what is ripe for transformation before migrating your systems.
We’ll also want to understand your motivations for the move. If you have pressing reasons to migrate to the cloud, then we may well propose a lift and shift approach, with transformation once you’re in Azure. I can’t recall any moves to Azure where our clients’ systems have stayed as they were.
Can we save money by moving to the cloud?
The answer to this is ‘it depends’. There are many factors we’d look at for you.
By using the Microsoft SaaS services (software-as-service) that come with the M365 subscription, some of your requirements in Azure could reduce. In this scenario, you’d undoubtedly save money.
Or you might want to take advantage of other Azure services, like better DR (disaster recovery) auto-scaling services for improving performance, or extra security layers to help with compliance. But here, you’re not comparing apples with apples, so see the question of ‘will you or won’t you’ save money in a broader context.
The key is to play forward your requirements and create a compelling business case for your proposed system design. Don’t move for cost reasons alone.
Do Azure Reserved Instances (RIs) save money? Should we implement them as soon as we’re in the cloud?
So, we’ve moved your applications into Azure – should you go for RI compute immediately? In my view, no.
Reserved Instances can provide significant savings for workloads that will remain in Azure. You can purchase a one-year or three-year term and pay monthly.
But before you consider Azure Reserved Instances, perform an optimisation exercise. The exercise will check if your services are using the best compute instance. You can save much more by right-sizing and then adding RI.
As an additional cost-saving measure and for suitable workloads – like UAT (user acceptance testing) or those used sporadically – you can use automation to power down the workloads, which sometimes offers more cost savings than Reserved Instances.
Cloud optimisation is a critical element of moving to a cloud service. And not only from a cost perspective; the technology and capabilities of the platforms change regularly. So, don’t view cloud optimisation as a one-off exercise.
I suggest reviewing your estate quarterly. Reviews will ensure you’re making the best use of your cloud platform and keeping costs at a reasonable level.
Will our applications be suitable for the cloud? And what about app performance in the cloud?
If you correctly consider the design of your application, the answer to this question is yes. But there are many elements to app performance in the cloud. They range from ensuring your environment is scaled correctly (in terms of compute instance and disk capability), to how your users interact with the applications.
The cloud isn’t a magical computing environment where things always work (sadly!) Different workloads need to be monitored and designed to use cloud resources in the best way. On this basis, they will perform well.
But there’s another area to consider, which is your network. Specifically, how your users will access your applications once they’re in the cloud, say Azure. If their local area network, wide area network or home connection is poor, your users’ experience of the applications will be equally poor.
So, it’s essential to consider connectivity too. There are many compute options (Ultra Disk, GPU enabled machines, etc.) and enhanced networking tools (like acceleration) that will improve your application’s performance. But in the end, if it’s badly coded, you may struggle, even with the mighty resources of the public cloud.
I have an app I’d prefer to keep on-premise; I don’t want to move it to the cloud. Is this okay?
If you have the option to move the workload into Azure, I say you should look at it. But it depends on how historic your system is, e.g. if the operating system or application is supported. For this FAQ, let’s say the app is supported in Azure.
If so, why would you want to maintain a workload on-premise when you can move it into an Azure platform? There, keeping the lights on is managed for you. Also, if it’s old and historical and used sporadically, we can migrate it and power the compute only when the app is needed.
Versus running the service full-time, you’ll enjoy significant savings and get a full set of governance and security around the application, instead of having to maintain it yourself.
It’s likely that your use of the application will also reduce over time. As such, your costs reduce commensurately with the required computing time. The cloud is a great way to give your IT team time back. They’ll no longer have to keep the lights on for an ageing, and most likely rarely used, application.
Do I need backup and disaster recovery in the cloud? I believe that cloud computing is ultra-reliable.
I say yes, you do need these services. But their scale may depend on the SLAs your cloud environment provides. While the base platforms in Azure are very reliable, they do sometimes have faults and outages.
And it’s not just the reliability of the platform we need to protect against. Your data is a critical element; your users could still accidentally delete or enter incorrect data.
The first stage is to look at each workload and its data to work out its importance and the service level agreement to your business. From here, we can design an architecture per workload. In the past, we often put a single SLA around large parts of the system, but with cloud services, it’s possible to provide different SLAs to each workload.
Options we consider range from full live – live workload builds between regions, down to a simple backup, that’s either locally or geo-replicated. As a minimum, we’d also look to back up your data from its home region (noting compliance requirements).
And as always, we need to treat backups and DR with considerable care. By regularly testing scenarios, you can operate as you would expect in the event of a problem.
I hear one benefit of cloud services is the ability to scale compute storage up and down. Is this true across all service types?
Unfortunately, no, not across all environment types. However, if there’s a need to design a service where this is a requirement, then yes, it’s achievable.
But what do we mean by scale up? In Azure, it’s possible to build horizontal scale sets, for web resources, for example. Automation based on load can increase (“out”) or decrease (“in”) in the number of VM (virtual machine) instances running your web application.
If we look at vertical scaling – where we add more resources to a VM – it’s also possible to add more (“up”) or less (“down”) resources to the VM. But there are limits to the scale, both up and down. These concern the machine types used in the initial build.
There are also machine types in Azure that allow you to burst the CPU usage without scaling up or out. When a B-series VM accumulates credit (for using less performance than its baseline), it can burst above the baseline using up to 100% of the CPU when your app demands higher CPU performance.
These servers aren’t designed for all workloads though, so care is needed when using them. Storage-wise, this becomes much more difficult. While it’s possible to auto scale some databases, scaling back storage is not possible.
In all types of environments, the design needs careful consideration so that the intended performance improvements meet the correct cost levels.
Do I still need Active Directory (AD) if I move my workloads to Azure? I hear it already has Azure AD
You likely will, and here’s why. Over the years, you’ll have had at least one AD server in your environment. And I see many cases with significantly more.
Active Directory has been around since Windows 2000 and is on all Windows platforms since then. AD provides, in simple terms, an identity platform for your users and machines.
However, Azure AD is now also available as an identity-as-a-service solution (IDaaS). So, can you use AD for all your identity requirements? Let’s look at the most common use cases. In a modern workplace environment, your users’ devices join Azure AD directly and use Microsoft Endpoint Manager (Intune, etc.) for management. Microsoft Endpoint Manager replaces the older system centre configuration manager or group policy objects for configuration.
It’s also possible to use Azure AD as the master user database for your system. It has greater functionality than the more traditional AD and provides features including simple multifactor authentication, and self-service password resets. So again, traditional AD isn’t a requirement here.
Where many organisations retain AD is where they have several historic IaaS workloads that are likely to exist for some time. While Microsoft has created Azure Active Directory Services (Azure ADDS) – which is a PaaS domain service – lots of our clients are keeping AD for the time being in Azure.
Even though the reliance and number of AD servers significantly reduce, migrating the existing AD can provide more a straightforward way to migrate workloads.
Trying to pick my top 10 was a difficult choice, but I hope I’ve addressed some of your questions. I tried to avoid using the dreaded ‘it depends’ answer, but in all scenarios, there are variables, as each organisation’s needs differ.
Whatever your challenges are, we can help. Advania is the partner that can make it happen. Talk to us today.
