Market research specialists Forrester recently predicted that the public cloud market will grow to $132.8 billion in 2020. More and more businesses may be moving to the cloud, but cloud migrations are not always plain sailing!
The background
At Uniper, we started our cloud journey back in 2016, and over the years we’ve experienced the ups and downs of cloud migration first-hand. In this article, I’ll be sharing some things we learned along the way - the good, the bad and the ugly! By learning from our maturity, you can avoid the major pitfalls and ensure that your own cloud migration goes as smoothly as possible.
Uniper splits from E.ON
In 2016, E.ON decided to separate its conventional power generation and energy trading operations into a standalone company. At the time, E.ON were operating primarily on-premise infrastructure, but as a newly-founded company, that was completely separate from E.ON, Uniper needed a new IT service that was efficient, reliable, secure, and could scale on-demand. There was only one solution that ticked all those boxes: the cloud.
The bad: Cloud is complicated
When businesses migrate from on-premise infrastructure, most of the time they already have an Exchange server in place - and Uniper was no exception. With a pre-existing Exchange server at our disposal, we had two architectural options: we could migrate to a 100% cloud deployment, or Uniper could go hybrid.
When we initially deployed Office 365, we opted for a hybrid approach. In hindsight, this was more complicated than we thought. Since we had to manage two completely different infrastructures, our hybrid environment had far more requirements than an on-premise or cloud solution. This list of requirements made our hybrid deployment complex and expensive - there were even areas where hybrid essentially doubled our workload and greatly increased the total cost of ownership!
To deliver our new hybrid environment, we connected Uniper’s on-premise Exchange server to the cloud-based Office 365 Exchange Online service. This configuration allowed us to route mail between cloud and on-prem, so we had the flexibility to host mailboxes locally or in the cloud.
However different parts of our workforce had access to different functionality, depending on whether their mailboxes were hosted locally or in the cloud. This inconsistency made it difficult to collaborate and made it impossible to implement consistent company policies regarding collaboration services.
To make matters worse, we hadn’t updated our contract responsibilities to reflect the cloud aspects of our hybrid mail service, which led to further inconsistencies and confusion.
Our hybrid configuration also made automation much more difficult, as we needed to manage our on-premise and cloud infrastructures separately. When you migrate to the cloud, you should aim to automate everything, but we were able to automate very little.
The solution: Remove the hybrid
Faced with these challenges, we decided to remove the on-premise element and migrate everything to the cloud.
This failed.
For many organisations (Uniper included!) removing the hybrid means untangling huge amounts of complex on-premises services. If you’re migrating from on-prem to a pure cloud environment, then Microsoft has a very clear migration strategy. However, since every organisation’s hybrid deployment is unique, Microsoft doesn’t provide a migration strategy for moving from hybrid to the cloud. If you do opt for hybrid, then even your cloud provider may be unable to help if you ever decide to migrate to the cloud.
The ugly: Your apps probably aren’t suitable for the cloud
The cloud is far less forgiving than on-prem. With on-premise, you can often disguise poor application design with a high-speed network, particularly when local apps and their end-users are in close proximity.
When we first started migrating our application estate to the cloud, we encountered problems such as multiple login popups, latency issues and overall poor performance.
This was due to an ad-hoc approach to selecting applications for migration. We really needed to find a way to quickly classify our application estate and work out what was suitable for migration, and what had to be decommissioned. Classifying apps based on some mandatory capabilities such as federated identity support and the use of web technologies was essential.
In the end, if an app didn’t meet this criteria, then we either moved it to an alternate, non-cloud platform, or created a roadmap to decommission it.
Ultimately, we decided that a large portion of our application estate was unsuitable for direct cloud migration.
When planning your own cloud migration, you should expect that around 75-80% of your applications will be unsuitable for cloud deployment. Just because you can host it in the cloud, doesn’t mean you should.
The good: Why you should migrate to the cloud
For Uniper, one of the biggest benefits of migrating to the cloud, was the creation of our own cloud-based IIoT (Industrial Internet of Things) platform.
Uniper’s Enerlytics platform was built with cloud technologies firmly in mind. Enerlytics uses powerful cloud processing to help our customers detect potential issues and predict power plant failures before emergencies arise. Since Enerlytics is a cloud-based platform, users can access all of its functionality from anywhere in the world, without experiencing any loss of performance.
We created the Enerlytics prototype on IaaS (infrastructure as a service), since we were already familiar with the tech. We had experience running Docker swarms and knew that these swarms could be replicated to our work stations, so by using this particular tech stack we were able to progress to the development stages as efficiently as possible.
However, as Enerlytics grew we encountered a problem with our initial IaaS setup: the virtual servers supporting Docker needed to be created manually. If we didn’t monitor the platform and scale our servers up and down as required, then we could end up with unused servers, which would be a huge waste of Uniper’s resources.
We needed to migrate Enerlytics to a new platform as quickly as possible. Traditionally this would have been a huge undertaking, but since Enerlytics was designed to fully embrace the cloud technology stack, we could migrate it between different cloud providers and services extremely quickly.
Ultimately, we decided to move our Docker orchestration to Azure Kubernetes Service (AKS). AKS scales up and down automatically, so we no longer had to manage the underlying servers manually. This significantly reduced the workload required to run Enerlytics, without us having to make any significant changes to the Enerlytics platform. By opting for Docker and microservices, we’ve achieved a highly portable design. In the future we could migrate Enerlytics between different cloud providers, such as Amazon Web Services (AWS) or Google Cloud Platform, or even move back on-prem, in a very short amount of time.
If you want to migrate to the cloud while avoiding vendor lock-in, then it’s essential that you embrace modern cloud design patterns. Docker and containerisation are your friends!
What we learned from our cloud migration
So, what’s my key advice, for any businesses looking to migrate to the cloud?
Firstly, avoid hybrid wherever possible. Hybrid may seem like a low-risk option, but that’s because it’s not really cloud. At Uniper, we found hybrid to be complex, costly and difficult to escape - the exact opposite of a successful cloud migration!
Secondly, before migrating any application, you need to evaluate whether it’s even suitable for the cloud. If you try to force outdated apps to adapt to a cloud environment, then your application estate is going to end up holding you back and may even sabotage your entire cloud migration.
If an application is unsuitable for the cloud, then you should keep it in your traditional hosting environment - or even better, decommission and replace it with a modern application that was designed with the cloud in mind.
