Many remember well the buzzing Stockholm meetup scene before the pandemic. Each week there were inspiring great new talks, followed by deep and insightful discussions on all kinds of tech and non-tech topics. Having not been at real-life meetups for more than two years, of course we directly jumped on the opportunity to present at one of SEB's first meetups after the pandemic.
Setting the scene
We decided to talk about how we, SEB’s Cloud Core Platforms unit, are supporting SEB's Cloud journey. Initially we provided some context and retrospective on SEB's 167-year old tradition of supporting people and companies, constantly seeking out innovations and creative solutions to both new and old challenges
Over the decades and in many new – and at the time transformative areas and industry sectors – SEB has been a catalyst for change by providing responsible capital and advice.
Over the 167 years passed, we have transformed a great number of times, sometimes faster and sometimes slower, but always with a long-term commitment to our customers and our people.
The front and center of SEB’s Cloud mindset
With the context thus set, we told the meetup participants why SEB had chosen to use public Cloud and how we work in the Cloud.
We chose to do it as an interactive dialogue, asking each other questions and filling in the blanks.
We told why we choose to create unique, differentiating value for SEB and SEB’s customers on top of Managed Software-as-a-Service and Cloud services, rather than go down the rabbit hole of writing own, "cloud-agnostic" middleware tooling.
On the topic of Infrastructure-as-Code (IaC), we discussed how sometimes being strict from the onset creates great value in the long run. For acceptance and production environments, we don't allow any teams to use the Cloud UI (console), but ask them to apply Terraform or IaC language of their choice. Terraform is also our tool of choice from a core platform perspective, making it possible for us to manage SEB’s 800+ cloud projects/environments, including the centrally governened guardrails, cloud resources and policies that we define and facilitate. This is a complete gamechanger for how we can observe and rollout changes to our cloud presence at SEB.
Enabling sound Cloud development
The four-eyes principle is another such pillar that springs out of IaC. This principle may seem like wasting time. However, in reality, it ensures both higher quality throughput, creates shared understanding, and lowers the risk of issues in production. Our main implementation of the four-eyes principle is related to Pull/Merge Requests where the code change impacts a production environment and must go through a designated colleague before it can be rolled out.
Further, we discussed the principle of least privilege, which is a rule that applies to all our environments and teams, ensuring that the individuals only have the right amount of permissions to do their work, for only a limited period of time. Elevating one's access is fairly fast and easy through a self-service tool with a second pair of eyes assessing the elevation, but it requires each of our Cloud platform users to dedicate some thoughts to which permissions that are actually needed to perform the task at hand, rather than simply over-privilege and forever keep it that way.
Finally, we discussed how DevOps is working out for us and how we – rather than assuming that everyone is a full-stack developer – try to create a supporting community of peers around Cloud. We also discussed how we seek to ensure we have deep expertise within certain functional areas, centrally supporting all teams migrating to Cloud.
Seeing it all in action
The presentation was concluded with a hands-on demo of our self-service portal: Python-based, running on Cloud Run and utilizing Terraform and CI/CD to create landing zones with various useful bootstrapped resources for thousands of developers at SEB. As the demo gods were nice this night a sandbox gcp project could be ordered through the portal and got successfully created. And during the 10 minutes it takes the pipeline to create the 400+ terraform resources that a sandbox setup contains, we showed the merge request created by the portal, the CI/CD pipeline containing the terraform plan and apply jobs and the code base that runs it all.
All in all, we had a great turn-up, a number of good discussions and most importantly, we got to share our story with other Stockholm techies, which is what the meetups are all about – socialising and knowledge sharing.