Continuous Delivery at Scale involves software development with a large number of contributors and dealing with delivering software to a large, varied user base. It means innovating at scale to have high impact through continuous delivery practices for software developed by large, global teams and used by many different types of users worldwide.
Hi everyone, so nice to speak to so many of you hear today.
My name is Sara Bergman, I’m a software engineer at Microsoft Development Center Norway. I’m Swedish but I have lived here in Norway for one and a half years now.
Today I will be talking a bit about engineering and continuous delivery at massive scale.
There will be a Q&A at the end so prepare your questions for then.
Alright, so why am I the one talking about continuous delivery at massive scale?
Currently I’m a software engineer, like I said, in a team called People Infrastructure.
We are an infrastructure team which provides people profiles and profile images for both Consumer and Enterprise scenarios through a series of APIs. Here I have put some of the user facing applications we serve. So if you have every seen you image or name in one of those (or a few other’s) of Microsoft’s services, hello, that’s me!
If you haven’t seen your image when you were supposed to…eh..sorry that might have been me as well.
Our services have over one billions monthly active users and they runs on thousands of machines across the globe. Which to me is truly massive scale.
Continuous Delivery at Scale, what does that mean?
We need to debunk this in a few steps.
So firstly, what is Continuous Delivery?
It can be summarized as the ability to get changes of all types—including new features, configuration changes, bug fixes and experiments—into production, or into the hands of users, safely and quickly in a sustainable way.
Sounds easy? Perhaps not, but done right it can reduce both cost, time and risk of delivering changes. This can build a foundation for rapid experimentation and innovation.
But when you start talking truly massive scale, does it mean anything else? Is the challenge different?
So firstly we need to figure out what we mean by massive scale, because it can really be many things.
I think it can be all of the above or just a subset of the above.
One example is the open source project, the Linux kernel, a Linux system only runs on one machine at the time and if I may say so, only caters to a specific kind of user.
But the massive scale of Linux comes from the number of contributor the project have had over the years. In 2017 it was over 15 000 developers and I expect there are more now.
So in my day to day life, I have all three of the above.
When the scale of the service goes up so does the complexity of the solutions. In smaller systems there are a lot of edge cases you don’t have to consider but in a very large system, they are not edge cases but use cases.
And doing this while staying agile, fast moving and continuously delivering, is a truly delightful problem.
So we need a number of tools in our tool belt to be able to handle this scenario
I though I’d show an example of one of these edge cases that is a serious use case for us.
Why does the number of machines matter you may ask? Isn’t the system distributed? Well yes, the service I work with is a distributed system and there isn’t much need for communication between the different machines in the system. Easy peasy. We are also a so called One-Hit service, meaning we get a request, do our server-side magic and give you back an answer. Easy peasy.
But ponder this scenario, you have a dependency on a different service, and they are not distributed. You are mindful of this so you design your service to only call this centralized service every second day for each user. We don’t want to take it down! For one machine, this works fine. But then you deploy the change to all your machines but there is no staggered start. And oops, centralized service down.
I think yes! Except there is no Olympics.
Working at Microsoft means that that you get to collaborate with a ton of people, each with their own unique background, from which you can learn a lot! But truly you get to work with people from all sorts of different teams, from all over the world. My team’s closest partner teams sit in Seattle, Prague, London and in India. And sometimes we visit them, here we are 4 of us in the HQ in Seattle, taking one of the campus shuffle buses.
Empower every person and every organization on the planet to achieve more.
This the is Microsoft mission statement.
To me, the key here is every person. That is bold.
