#Microservices

This blog post is part of the Everything is Code article.

(Microsoft) Expedition Cloud

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:

Expedition Cloud: a once-in-a-generation paradigm shift

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.

Hybrid Approach

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 3^rd 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.

Prioritization

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

Designing a modern service architecture for the cloud

Microservices Architecture

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:

• #CloudMigrationFramework-5R [Coming Soon]
• #Microservices [Coming Soon]
• #APIManagement [Coming Soon]
• #ServiceMesh [Coming Soon]
• #Orchestration [Coming Soon]

Next Chapter: #DevOps [Coming Soon]