As we saw in Part I of this blog, Unifonic’s objective was to build cloud-agnostic microservices architecture. You might be asking yourself why this would be a priority. The answer is that Unifonic had previously been using Cloud providers to host their applications. This was a perfect solution at the time but business client requirements have necessitated a change in direction. 

In-Country Deployment

Whatever system one is building these days, it is important that it is deployed ready to work with different cloud providers like Oracle, AWS and Azure.

Dealing with such providers requires paying careful attention to every component used, and this brings with it a huge and complicated list of challenges to deal with.

User Federation

In whatever territory a deployment takes place, there will be different regulations about storing and moving data. For example, in Saudi Arabia, all client data need to be stored locally within the country.

In-Country challenge

Cloud service providers have specific services and data centres in different countries and as mentioned above, this may violate laws and regulations about keeping client data in the country. When the decision was taken to change the system architecture and infrastructure to support in-country deployments, it introduced a technical challenge around how to use cloud services on different platforms. For example, having two different deployments on Oracle and AWS.

From Cloud-Specifics to Cloud Agnostic

Unfonic subsequently decided to shut down all cloud specifics services and replaced them with standalone components. For example, replacing Object storage with MinIO, and replacing Event Hub with Kafka. This enabled the company to move and deploy the systems more easily on different platforms.

Is it all about System Components?

Being cloud agnostic isn’t only about deciding on the system components and services you will use. There is also a big element about communications and a complete understanding of what is being used by engineering teams; that way, teams can safely choose the component they will use and the code compatibility they will develop.

For example, notice the impact of small changes in the following java code:

public class SystemRepository {

// Define database connection regardless of what is the current cloud provider?

private final JdbcTemplate jdbcTemplate;

  public String getCurrentDate() {

    String result = jdbcTemplate.queryForObject(

      "SELECT CURRENT_DATE FROM DUAL", new RowMapper<String>(){

       //// some business logic

    });

    return result;

  }

}

At first glance, all looks good. But what if the developer had already introduced the following in the code?

public class ApplicationConfiguration {

  // AWS RDS SDK artifact

  @Bean

  public RdsInstanceConfigurer instanceConfigurer() {

    return ()-> {

        TomcatJdbcDataSourceFactory dataSourceFactory = new TomcatJdbcDataSourceFactory();

        dataSourceFactory.setInitialSize(10);

        dataSourceFactory.setValidationQuery("SELECT 1 FROM DUAL");

        return dataSourceFactory;

    };

  }

}

The code is no longer compatible with different cloud providers, and will not work on any platform but AWS. So, It was really important for the engineering team to pay close attention to each process, review the systems from different angles, and adapt the code where required.

What was the Plan?

The plan to migrate from cloud providers was straightforward and went forward without a hitch. The advantage was in having all systems over containerization (docker), the IT infrastructure team got the required list of components from each team and started to migrate them as is, with a small amount of fine-tuning where required according to engineering team guidelines.

 At the same time, the engineering team and DevOps engineers were preparing the required configuration scripts to automate the process and to develop tools to be used in the future.

Following up with One Diagram

The diagram was revisited at every stage of the migration process, meeting with architects and stakeholders regularly to get feedback from all areas of the business. These meetings were helpful all around as there are always points of confirmation and collaboration to be discussed and understood to avoid problems. 

This has been an important journey for Unifonic and one that raised a lot of challenges and questions. We are proud of the outcome and look forward to many more such journeys as we continue to provide our customers with the best possible products.