How we built a bespoke solution for PRISMA’S cloud migration

Our last blog post discussed the step-by-step approach taken by PRISMA as we faced the challenges of implementing a cloud migration. This time around, Dominik Kosieradzki, PRISMA’s Application Manager, leads us on a more granular exploration of the migration process, focussing on how we built a bespoke solution tailored to the specific needs of our company. 

As a small to medium-sized company, the need to optimise our flexibility, performance and growth played a key role in our decision to move PRISMA to a cloud based solution. And central to our vision has been the awareness of the crucial function we play in maintaining the  operational efficacy of the gas value chain in Europe.

This, as much as anything, is why undertaking a successful migration has been so important. And it is also at the heart of why it was necessary to create a bespoke solution based on the precise needs and complexities of our organisation and its role within the gas industry sector.

Laying the groundwork

When people think of cloud migration they tend to think of a technology shift – in other words, moving infrastructure into the cloud. But the reality is that cloud migration is an expansive process that not only affects system architecture from a development and operations perspective, but rather the company as a whole. As a result, input is required from all quarters: senior management, finance, accountings, product owners, customer support, customer success, and so on.

In the case of PRISMA, we were also aware of the requirement to involve a number of external service providers in the process, by working together on translating business requirements into actual solutions, as well as cross checking that we were following the best practices relating to security and compliance.

This is where my role came into play...

A key part of my remit was to act as a bridge between the business side and the IT side, translating the business needs into IT terms, ensuring a consensus on what to prioritise, and then delivering it as quickly as possible, without being diverted by lower priority issues.

To achieve this, it was essential that we had enough support from the top of the company and that – equally importantly – all of our colleagues were aware of how big the changes that were coming would be. I considered it extremely important to communicate up front that it wasn’t simply about re-starting the servers in a different data centre, but rather a major shift in many of our business processes.

A merging of knowledge & expertise

We quickly focussed on acquiring knowledge and capabilities that would allow us to deliver a solution and then operate it in co-ordination with our service providers. To achieve this, we set about bringing together people from inside the company with different skillsets: those with business knowledge, those with knowledge of the legacy systems we had in place, and those with deeper cloud expertise.

Among our most important decisions was to start building bridges between our development and operations teams with the eventual aim of merging them into one. By initiating this process for our cloud migration, we were better able understand the varying perspectives involved and apply them in a collaborative fashion.. For example, it allowed people with greater legacy development knowledge and those with a better understanding of the cloud-native architecture to discuss things more quickly and efficiently than when they were self-contained teams.

In turn, this not only benefited the quality of our cloud migration solution, but the company culture as a whole.

The lift & shift approach

When it comes to cloud migration strategy, there are essentially six different paths you can take.  Our decision to adopt a ‘lift & shift’ approach  – whereby we re-produced our current applications in the cloud on AWS for most components of our solution and improve iteratively from there– was driven by the fact that we had defined upfront what our goals and expectations were and which of them we wanted to achieve quickly and which should be tackled with new insights once the system was already up and running in the new setting. Namely, the top priorities were - more flexibility in terms of the capacity for running our applications, and a greater sense of empowerment for our people at PRISMA to experiment.

We began with an iterative approach, making small changes at first, learning from them and then improving on them. We outsourced the basic administration of some of the components of our solution to Amazon Web Services [AWS], which allowed us to focus on the core of our work – delivering the new functionalities and making other improvements to our infrastructure and architecture.

Choosing a one-cloud set-up

One of the most important decisions a company must make when it comes to cloud migration is moving to a single or multi-cloud set-up. This is because different cloud service providers offer different benefits. For example, one provider may excel in machine learning and artificial intelligence, while another may offer excellent storage. 

Some organisations prefer to have more than one cloud service provider in order to distribute the risk between them. However, as a company already working with several external service providers, we decided it was important for us to minimise the complexity and maximize our internal expertise by opting for a one-cloud solution.

Our only proviso was that it would be essential for us to retain flexibility in situations where we needed to restore our application in a different region. For example, if something were to happen to our data centre in Frankfurt, we needed to be able to activate our solution in Ireland.

For this reason, we opted for a large, well-established cloud service provider (AWS) who are able to offer several data centres in different parts of the world, therefore ensuring that our disaster recovery process was rigorous and reliable. 

Operational challenges

Even if you’re only implementing small changes to your application - as is the case with lift & shift - preparing for a cloud migration requires substantial groundwork. Among the decisions we faced were how we’d monitor the solution once it was up and running, how we’d maintain data security, and how we’d structure our team to respond to incidents.

We also anticipated that our architecture would grow in size and complexity over time. For this reason, we decided to invest up front in technical baselines that would help us set up new accounts or new server instances later, and keep all new resources in line with your security and compliance requirements. 

When it came to how we’d actually run the solution once we were in the cloud, we had quite a complex model due to the number of vendors and service providers involved. To deal with this, we had to make strategic decisions regarding areas that we both wanted to keep under our control and share responsibility for. Depending on factors such as how critical the component is, how scarce the knowledge about a specific technology is, and how much we expected that technology will be worked with daily, we tried to balance the split of work and responsibilities between external service providers and our own team.

Another effect of working with different service providers was that it invited a greater diversity of perspectives, experiences and specialised expertise in managing individual components of our solution, which also has broader benefits for our team such as opportunities for knowledge sharing and collaboration.

Preparing for the switch

The lead up to migration night required significant planning. We even created a so-called ‘war room’ for us to rehearse alongside colleagues and service providers the various scenarios and difficulties that could play out as we made the switch.

What’s more, due to the structure and governance of our company, a huge amount of communication was also required with our users and other external stakeholders who rely on the platform on a regular basis, so that there would be no surprises once the switch took place.

One of our most useful resources in this regard was ‘dry run’ migrations. These were essentially mock migration nights in which we would replicate the entire process, step by step, helping ensure that when it came to the big event, everyone involved knew what they had to do, and when.

Another key challenge was keeping platform downtime to a minimum and executing our cloud migration in a way that was as seamless as possible for all external parties – a target that I’m glad to say we met.

Monitoring post-migration

Once the migration itself had been completed, there was an ongoing need to keep monitoring the application. To help with this we prepared dashboards which allowed us to track the key metrics and processes on the platform. We gave responsibility to people from across the company – in infrastructure, development, customer support, success and so on – who worked in shifts on their specialist areas, monitoring the application and responding in the event of an incident by communicating the issue to customers or relevant stakeholders.

This ‘hypercare’ approach – whereby a project team provides enhanced support after a new system has gone live – was a vital tool in ensuring a smooth post-migration transition

Just the beginning…

Of course, we know that in many ways our cloud migration is just the start. Moving to the cloud opens so many possibilities around improving the resilience of our infrastructure and our systems during down times, our ability to respond to increased demand from the market, and to evolve and adapt our solution while in full flow. But my overriding feeling at this juncture is that we’re well on our way to achieving the ambitions we set out at the start – and that is a source of great satisfaction.

In Part 3 of this series to be published next month, we’ll speak to Tobias about the lessons learned one year after PRISMA’s cloud migration.