In Short

The role at Lely was a bit of a combination between on the one side helping out the central Azure team, and on the other side establishing sustainable IT capabilities within Lely in a more broad sense.

Details of the Role

The central Azure team within Lely was responsible for the management of cloudresources within Azure for the whole of Lely product development and innovations. From a technical side, they are responsible for managing networking throughout the whole tenant as well as outward facing, proper resource sharing, SaaS embeddings such as DataBricks, and costmanagement. Within that domain, I was involved with most of the projects involving sending data to Azure and further analysis. Not directly as a data engineer, but merely from a cloud engineering perspective. That’s still quite a big domain, and I would deal with a lot of context switching throughout those days, nonetheless one of the main components was the installation and the adoption of KEDA on top Kubernetes, in order to provide some sort of function-as-a-service functionality towards development-teams. Next to that I was involved with costmanagement, namely the ingestion and reporting of Azure related costs, and later on cost optimisations.

From a technical point of view a very interesting position since I was able to touch upon many different facets of Azure and because we were working mostly in a new tenant there was not a whole lot of legacy involved, allowing us to focus more on the newer Azure features. Nonetheless, you do not simply go to a new Azure tenant without effort and as such a lot of our work also included the migration of older applications and services.

From a sustainable IT perspective, I was mostly operating on my own. Strenghtened by goodwill from management to embrace more sustainable practices, in collaboration with the sustainability office I organized a digital cleanup day to identify other sustainability enthousiasts and together with them I identified several potential future projects. The most important aim was to gather data around IT emissions in the first place. For a more detailed analysis on IT emissions and the involved data, see here. Some of the projects we envisioned included: implement measuring steps within CI/CD pipelines, developer education through workshops, enterprise guidelines about green coding practices, cloud emissions measurements through the Cloud Carbon Footprint, and many more. As such, I’ve spent a lot of time testing tools out there, but also inviting several parts of the organization into cooperation. At the end of the day, I am happy to have reached so many people but for a variety of reasons we could not get further than setting up the Microsoft Azure Emissions Impact dashboard.

Technology Stack

For my work with the central Azure team, the most important central components were obviously Azure, terraform, Kubernetes, ArgoCD and Gitlab. Within Azure I was working with AKS, EventHubs, various database solutions, various storage solutions, Eventgrid, Data Factory, Azure Functions, Azure App Services and various aspects of networking. Next to that, I’ve setup KEDA on top of AKS and provided the developers with containers to run their python code. And within the migrations I was involved with a lot other Azure components around monitoring.

For the costmanagement analyses, I used DataBricks, PySpark, and the new Lakeview dashboards.

And for the sustainable IT efforts I spent a lot of effort in deciphering the results from the Cloud Carbon Footprint, and identifying its shortcomings. For some of those I did open Pull Requests, but other issues such as missing new Azure services, SKUs and instance types were sometimes more concerning. All in all, it remains tough to assess the footprint behind your cloud resources.