Articles

and more emphasis on moving forward than on avoiding
breaking changes.
That’s the same shift you’re seeing across Microsoft. Over
the last decade, building Azure has taught the company a
lot about the advantages of microservices for what would
otherwise be large, monolithic applications. The original
service front end managed resources like compute,
storage, networking and the core infrastructure
components – for the whole worldwide service – in a single
app. It was a large and complicated codebase, running in a
single data center, and it took up to a month to release an
update – after it was finished and tested – which meant it
was only updated once a quarter. Plus, the management
tools for all the different components were secured by a
single certificate.
Rewriting that as around 25 different microservices makes
it easier to develop, test and release new features. New
features can be “flighted” to a test system to see how they
perform, and releasing updates takes no more than three
days … even though the resource providers that manage
compute, storage and networking now run in the individual
data centre. That improves performance because there’s
far less latency when, for instance, the compute used in the
Azure data centre in Australia is managed by a resource
provider running in that same data center rather than in
Texas. Putting compute and data together isn’t just faster,
and easier to scale; it makes things more reliable, because
you’re not relying on the network between data centers for
management. Limiting each microservice to operating in its