Working at a hybrid cloud concept
Hey Aleksei, please give us a first introduction to the product we are talking about.
Yes, sure. Since 2018-2019 we are working on a hybrid cloud setup with a big focus on security and governance standards. With hybrid I mean that we are connecting our classical infrastructure (international data centers) with a cloud based environment. Our aim is to grow more and more towards Azure cloud and lowering the amount of on-premise infrastructure we have right know. But first, we want to master the hybrid setup, to translate our skill in operating the data-center infrastructure to cloud workloads, then go full public cloud with Azure, AWS, and GCP.
That’s not easy to achieve, but we are working with high effort and motivation on this initiative.
Why did you start the cloud move?
The biggest reason is the near-infinite scale possible only in a cloud environment. You have the capacity for your application resources to grow along with transaction volumes. That is somewhat a limiting factor in a private data center. In the cloud, we can scale the services horizontally to as many replicas as we like and not be limited by network restrictions. The massive amount of transactions we have to handle daily and even bigger one in the future is the primary reason for the clod move.
Why hybrid cloud?
There are several reasons such as information security, flexibility, and cost.
The hybrid setup is more complex to maintain but it allows us to migrate to public cloud with the pace we are comfortable with. We don’t migration all hundreds our applications and databases all at once rather when each application team is ready. We started with establishing a mesh that spans across the entire hybrid environment. It allows services to securely talk to one another across cloud and data centers. At the same time, we can securely keep sensitive data sets on our premises until we are not restricted by regulations as well as organizational maturity.
What are the technologies you are working with?
It would take quite some time to describe all the tools and systems we are working on and with. That’s why I brought you this illustration to give an overview of our software development process.
Within this process, we allow our engineering teams to deploy, design and develop their applications with a lot of empowerment. The teams can write software using their own tools, choose best-fitting languages and frameworks for the job while still adhering to the same strategy and general practices. We emphasize the importance of agile and continuous delivery practices and focus on fully automated pipelines.
At first, we start with requirements automation using tools like JIRA and CONFLUENCE. We are defining the product we want to develop and its acceptance criteria for the software to pass the test automation at a later stage. So we start with practices like "behavior-driven development," where we bring together the whole team, the product and business stakeholders, the engineering roles, pretty much everyone, and develop software together – as a TEAM. So we don't work in business and IT silos, but in a product team.
We use Azure DevOps as our version control system and a system where we write our continuous delivery pipelines as code. It includes the complete automation of the testing process to ship new features daily or even more often. Most of our testing tools are focused on testing automation, as you see from the diagram, the remainder is used for exploratory, scientific testing of behaviors we might have not identified yet.
For packaging, infrastructure provisioning, and delivery, we use standard community tools like DOCKER, TERRAFORM, and Azure DevOps. I already mentioned a service mesh that we have – it allows us to do things like automated service discovery, to handle failures in the system using circuit-breaking and retry policies, to release new features to certain “canary” groups of users, and so on. As you see, that it’s really some advanced stuff that we do!
We adhere to DevOps principles in daily work of our teams. It means that the autonomous teams not only design and develop their application, but also ship and operate them. We have a suite of observability, cost management, monitoring, and IT operations tools that let our capability and development teams to have their apps healthy and under good governance.
What makes it so special to work on this case within Arvato Financial Solutions?
This case is fascinating in general and specifically fun to work at here at AFS. It is because you feel like working at a fintech with all the modern and cool stuff, but we also are a big company that could and should take care of standardization, governance, policies, practices, and so on. You can achieve big things here while still working with edge technologies. It's a good autonomous environment we are working in. All the capability teams have their autonomy, but they also have a reliable baseline. You work in a product team on building and running something from start to end. That gives you a sense of achievement and makes you proud when seeing your product being used by so many people.
That’s why our team members feel very comfortable working here at Arvato Financial Solutions.