Go to search feature Go to content

Setting the Cloud transformation foundation

Illustration of cloud on a yellow background

At SEB, we started the Google Cloud journey with a Cloud Core Team of between five and ten people and now have more than 1,000 active users in our Google Cloud environment. In this article we will explain more about how we set the foundation for our cloud foundation.

McKinsey recently published an interesting article on the importance of building the right Cloud foundations at the outset, authored by Aaron Bawcom. If this is not done properly, long-term success and ROI are likely to just become pie in the sky.

Cloud foundations: Ten commandments for faster—and more profitable—cloud migrations

Reading the article, we were happy to see that we have gotten quite a few of McKinsey's recommendations right at SEB. For example, in the second of the 10 commandments that the article outlines for faster and more profitable cloud migrations, it states that one should:

Design the Cloud architecture so it can scale. If companies do it right, they can build a Cloud architecture based on five people that can scale up to support 500 or more without significant changes.

At SEB, we started the Google Cloud journey with a Cloud Core Team of between five and ten people and now have more than 1,000 active users in our Google Cloud environment, so that recommendation definitely holds true for us. Building on the article, we would say that there are three key factors that has made this journey possible for us at SEB:

  1. Using the Cloud that already exists.
  2. Working with Infrastructure as Code (IaC)
  3. Working with Security as Code (SaC)

Below we discuss these key factors in more detail.

Use the Cloud that already exists

The fourth commandment in the article explains:

Many companies operate in fear of being locked into a specific Cloud service provider (CSP), so they look for ways to mitigate that risk. A common pattern is an overreliance on containers, which can be expensive and time consuming and keep businesses from realising the genuine benefits available from CSPs.

In the SEB Cloud Core Team, we always search for a Cloud native solution whenever we're lacking a feature. It doesn't always necessarily correspond to a single CSP service or even multiple ones (sometimes we simply have to build it ourselves), but we always try to minimise the effort we need to put into a given feature, and rely heavily on the expertise of the major Cloud providers. Reinventing the wheel makes it a lot harder to make progress.

Work with Infrastructure as Code (IaC)

How many of your (Cloud) infrastructure deployments are four-eyes reviewed, tested and automatically deployed to their respective environments? Do you have an audit trail of your infrastructure changes, and how easily can you rollback in case of misconfiguration? While many companies go all in on various kinds of KPIs, metrics and OKRs, we haven't really seen enough companies put sufficient focus on having most of their infrastructure changes done via Infrastructure as Code (IaC).

William (one of the authors of this post) shares a personal reflection:

Back in 2018, I worked at another company on route to their Cloud transformation. I recall how new and even frightening IaC felt to many in the infrastructure engineering teams.

Gradually we moved the needle over and got a decent IaC coverage for our Cloud and on premise infrastructure, but it was far from given when we first started discussing it.

Coming to SEB, I was expecting a similar situation, but it turned out things were quite the opposite.

Nearly all of our acceptance and production infrastructure in Cloud is in version source control and highly automated, with all the benefits of that approach, such as visibility, repeatability, traceability, resilience, control and governance. By having IaC as a first-class citizen for all working in Cloud, and maintaining the discipline throughout, many other benefits realise themselves as well. These include decreased overall risk, stable and consistent environments for faster product and infrastructure iterations, easier cost optimisation, self documenting infrastructure, and simpler onboarding.

We know from experience that achieving a solid IaC practice is no small feat. It has its own learning curve and the steepness of the curve varies across different tools and of course the maturity of your developers. However, it's the only feasible solution if you're going for scale in public Cloud.

Not having IaC is not a problem if you are running a single web application on a compute instance behind a load balancer. But it's an entirely different matter when you are running a web application, a database, a Kubernetes cluster, and some serverless functions to support all the services of your application. That problem exacerbates when you need to run many environments (hundreds and thousands). Consider your development, acceptance, and production environments. You have to provision and maintain all that infrastructure. Doing that manually is a massive burden and time commitment (and of course highly prone to human error).

This investment into a more sound infrastructure process using IaC will pay dividends for the entire life of the product or company. Our colleague Tonni Hult recently published an article on this blog titled Do I have to use Terraform, where he discusses the benefits we've found in the Core Team working with IaC in more detail.

Do I have to use Terraform

Security as Code (SaC)

The McKinsey article again:

Security as code (SaC) has been the most effective approach to securing Cloud workloads with speed and agility. The SaC approach defines cybersecurity policies and standards programmatically so they can be referenced automatically in the configuration scripts used to provision Cloud systems. Systems running in the Cloud can be evaluated against security policies to prevent changes that move the system out of compliance.

The majority of the benefits with code configuration has already been discussed above. But it's worth mentioning security and compliance configurations in isolation because of the extended benefits they provide.

Having your Security configuration versioned, reviewed and traceable allows you to quickly scan the overall security posture of your Cloud configuration, as well as quickly find answers in relation to specific compliance requirements.

  • Are we making sure that no sensitive data is publicly exposed?
  • How fast can we propagate a new regulation requirement to our entire Cloud configuration?
  • Which, if any, of our environments across our entire organisation is exempt from our default security posture, and why?

As an example, the last question has a natural traceability through code commits and code reviews.

Since the banking industry is highly regulated, SaC is a given in our tech stack, and without it there is no way we could scale out our Cloud onboarding to thousands of users.

Product Owner for Public Cloud

Victor Bodell

Product Owner for Public Cloud

Victor Bodell


Chief Product Owner Cloud Core Platforms

William Milisic

Chief Product Owner Cloud Core Platforms

William Milisic


Do I have to use Terraform?

This is not a post on how to use Terraform or Infrastructure as Code, it is more of a summary on why we have found it to work well for us.

Illustration of Terraform concept

Building the Cloudification KPI Application – Part 1

SEB has chosen a Cloud First strategy based on the Google Cloud Platform. It is a pretty big change for a bank that has been self-sufficient in IT for around 50 years! But how do we track our transition to the Cloud? One way is to measure and work with KPIs or “Key Performance Indicators".

Illustration of documents in a cloud on blue background

Contact us

Do you have feedback or thoughts about future blog articles? Get in contact with us at the e-mail address below.