Thoughts on operating your IT an applications in a cloud-native way
Work in progress – A rather long article in snackable chapters that will be added and extended in the coming weeks.
The content of this article represents my personal opinion that is based on my daily experiences as CTO of Microsoft Switzerland, working with organizations that run or plan to run their IT and applications on Microsoft Azure.
Azure evolves continuously, as my knowledge – And the more I learn, the more I have the impression that I know very little. In this respect, this article does not pretend to share any dogmatic truth, but simply my current thoughts – I am truly thankful for any feedback that will help in continuously improve this content.
I talk with many organizations, in the most recent years mostly enterprises. The common denominator: Looking for (business) agility.
Technical and business model innovation is disrupting industries. Business leaders of established organizations demand their companies to (digitally) transform, to get real-time, end-to-end insights of their companies, customers, and processes – Of their (aggregated) data – to be able to rapidly take fact-/data-based decisions that can be implemented quickly.
These series of blogs that compose into the Everything is Code article aims to give you some hints on the necessary transformation steps and how to approach the transformation process.
In this context, moving to the cloud* becomes the opportunity to achieve this highly demanded agility. Be careful, however, because doing the same things in the cloud that you on-premises will bring you costs saving, scalability, better resiliency, more possibility to deploy near your customers, better security but won’t bring you agility.
To achieve agility you will need to adopt a cloud-native approach. In the following 4 chapters, I will try to describe what does this means, using examples from our own transformation** and knowledge acquired in my daily work helping organizations during their journey to cloud.
Eventually, these steps will enable you to increase your capability to deploy features and updates to production, leading us to the title of this post and my guiding-line for this article:
because it is my profound conviction that the only true measure of your (IT) agility is the number of deployments you do to production.
To give you an idea, as per today in an always evolving practice (devops is a journey!), we do
… and this is the number that I personally consider the real measure of (IT) agility.
As we will see with details in the upcoming posts composing this article, your deployment capacity depends on a few macro-factors that I like to summarize as:
Before moving to the next chapter, just a glimpse of what we will discuss in part /05/ where everything comes together:
* Even if most of the things that I will mention could be rather cloud-agnostic, my expertise is on Microsoft technologies and Microsoft Azure. In this context and in transparency, Cloud becomes here almost a synonym of Microsoft Azure.
** I am referring here to the migration of our internal IT and applications used by Microsoft employees from our data-centers on-premises to Microsoft Azure.
…and clearly, it is not real if it is not on a t-shirt:
Expedition Cloud is a web site that collects great information and testimonials about how our internal IT organization has migrated the majority of the infrastructure and applications used by Microsoft employees to Microsoft Azure. While you can find all the details here:
I would like to rapidly list a few milestones and lessons-learned of that expedition that are relevant to our mission-to-agility, along our guiding-line: #OnlyWhatYouDeployMatters.
Please note that for the matter of keeping this post short and aligned with the goal of the article, I am quite simplifying the message and adapting it for story-telling reasons.
The migration approach that was taken was relatively simple: Move as much as possible to public cloud, and move the remaining to a modern private cloud – As part of a Hybrid Cloud Strategy.
Additionally, the idea was to move
commodity software, like email, to SaaS offering – From Microsoft or from 3rd parties.
strategic software, into which we wanted to invest, to PaaS.
all the rest that just needed to be maintained to IaaS.
The migration has been a fantastic occasion to re-visit our IT portfolio:
This has allowed us to eliminate around 30% of our on premise footprint, counting for thousands of servers and VMs
We were also able to move around 15% of our functionality to SaaS
We identified less than 5% of functionality that would target the private cloud.
For the remaining 50% of the application portfolio, the target was Azure, with the approach explained before.
For IaaS, we proceeded really fast by lifting & shifting pre-production systems, which allowed us to rapidly gain important experience.
For the other applications, we started an in-depth portfolio analysis, to identify which apps to move first. We soon realized that this approach was not adequate and it was delaying our transformation.
Taking some risks, we drastically simplified the selection criteria. Fundamentally we said, if it is not business critical and if it is technically not too interconnected and challenging, we will move them first. Astonishingly, 75% of the applications were identified as first-movers, including naturally all new applications.
We started thinking differently
While we were successfully migrating applications, we started thinking a differently. First of all, we started to think that
IaaS may well be seen like the next data center to close…
(I let you reflect on this one…)
We realized that we wouldn’t really transform focusing on moving applications to the cloud. If you do the same in the cloud as you do on premises, the benefits you get are limited: Some costs saving, scalability, better resiliency, more possibility to deploy near your customers, better security. That’s it.
What we needed to do, was
breaking down the application silos and think in business capabilities, in unique, discrete business services. This fundamental change is what enabled us to adopt a highly efficient devops culture, a key aspect in our mission-to-agility.
Let’s see a concrete example of this new business service driven architecture talking about our finance applications
Finance Applications (An Example)
When we surveyed our legacy set of 36 on-premises, standalone applications used in procurement, we discovered a significant functionality overlap among them.
We broke down the complete feature set within each apps to separate core functionality form duplicated features and we have used this information to build 16 discrete services, each of which has a unique set of functionality, presentation layer, and master data.
These vertical, discrete services have well-defined and well-managed APIs, that are used to bring them together into the different end-to-end User Experience layers, within a modern microservices architecture.
And why is this key to our mission-to-agility? Next chapter will tell you this, while at the link below you find the whole story of this transformation
The 16 discrete services mentioned before are “isolated units” that are developed, tested, deployed, and maintained by a autonomous, small devops teams. While I will go more in the details of how devops teams work efficiently in the next blog post, here is important to understand that
the concept of a microservice, intended as a unit of capability that undergoes the same needs for security and scalability, is the precondition, the necessary architecture, to enable true devops.
In this context, devops teams need to define and manage interfaces (APIs) smartly, while they have total freedom beyond these APIs, including the choice of the technologies they use to develop.
Deep Dives related to this chapter
If Microservices bring a lot of advantages, this type of architecture also bring a few challenges. The first two that come to my mind are:
Challenge #1: Communication between Microservices
Challenge #2: Communication between consumers and an application
I will be dealing with these challenges and going deeper on Microservices in upcoming posts, including: