Ajai Peddapanga recently delivered a session for his Azure Cloud Solution Architect colleagues to help them guide customers when evaluating Azure Kubernetes Service (AKS) and Azure Spring Apps. In this post we share highlights from the Q&A portion of the presentation to fellow Microsoft employees.
Rather than trying to choose a single platform for all your applications, Ajai and his coauthor Asir Vedamuthu Selvasingh encourage companies to shift their thinking to take full advantage of the flexibility and elasticity of the cloud—not to take an A or B approach but to take an A+B approach. Their book How to Choose the Right Azure Services for Your Applications—It’s Not A or B for free, and there is also an on demand webinar where they discuss their recommended approach. We hope the Q&A below sparks your own ideas. We’d also love to see your own questions in the comments!
Matt: How do you get a customer to be receptive to taking an A+B approach? What questions do you ask? How do you make the “light turn on”?
Ajai: I think the Aha moment will come when they see that the cloud is a game changer. That they don’t have to think in terms of A or B anymore. Apart from that, there are multiple factors that contribute to A or B thinking. Understanding which factors are contributing to it is important. For example, if politics and control are the main factors, then it’s going to be an uphill battle. On the other hand, if the customer is thinking A or B because of on-prem design patterns they are used to; then it’s easier to get them to see there is a better way of doing things in the cloud.
Matt: When you get customers to the point where they get that the cloud means they don’t need to focus on upfront investments and long lead times, what’s the next phase of the journey like? Do they start to get creative and inspired and want to experiment? Does it help them make decisions or slow them down? Or slow them down just enough that they make the right decisions?
Ajai: I think it’s a journey. Usually when app teams realize what cloud can do for them, they get excited, and start spinning up Azure services left and right. Yea, I think they go into this experimentation phase, which is a good thing, but from my side, I would tell them do all your experiments in sand box environments with no customer data. Because the downside of this experimentation is, every team starts creating Azure services with their own subscriptions resulting in a messy and unmanageable Azure environment. No that’s not what we mean by A+B. Even in Azure you would work on the core foundation that applies for all Azure Services, we call this the landing zones, and then start consuming the services that you need through the landing zones.
Matt: When you are working with independent teams who must work with “1 platform” team stakeholders, like IT teams that hold the keys to the network, what helps the independent team free themselves up to do things differently? What helps win the gatekeepers over to trying an A+B approach, or at least removes them as blockers for other teams at that customer?
Ajai: At the customers I worked with, I have seen two scenarios:
- Application teams / Business make the decisions in terms of which technology to use for their applications, because usually they are the ones paying.
- In some cases, Infra / central platform teams make the decisions.
But I think in either case, the trick is to reframe the conversation to bring the focus back on the usecases. Just yesterday, I had this conversation with a customer in the context of modernizing their apps. The customer reached out to me asking for help with blue-green deployment. He asked, “AWS has a very good document on blue-green deployments, does Microsoft has one too?” I took that as an opportunity to ask the “Why?” questions. What is driving the requirements for blue-green deployment? Can we take a step back and talk about the business objectives and the SLA a requirements? How many applications do you have? And have you already decided where they land in Azure? etc., etc. Long story short, I reframed the conversation into “let’s understand the use cases first before getting into the weeds.” Unless you understand which Azure Services you are going to use, discussing blue-green deployments doesn’t make sense. The customer happily agreed, and the next step is a discovery meeting to understand their use cases and then decide the proper destinations in Azure for their applications. In fact, the customer came up with the title of the meeting. He called it “Azure Destination Planning - Business Use Cases.”
Matt: It sounds like if a customer cares about “future proofing” then an A+B approach is maybe a little easier to take with them, at least to get them exploring options. What are some tips for leading an envisioning session or architecture discussion starting from that point?
Ajai: I think that’s a great point. I would say, future proofing indirectly leads to the A+B approach. For example, one of the ways of future proofing an application is to take a modular or microservices based approach where each module has an independent life cycle and an independent technology stack. The idea is, you want to upgrade or add specific features to your application without having to tear down the whole thing. Let’s say there is a messaging module in your application, you should be able to upgrade your messaging platform from RabbitMQ to Azure service Bus without impacting your entire application. So, this modular approach naturally leads to the A+B way of doing things. Basically, now at the module level you are choosing the right Azure service. This also helps with responding more gracefully if certain services were to be discontinued.
Matt: With the RIoT example at Bosch, they landed on Dapr because they were focused on future proofing their work, and they knew that they had to do something different than they had done with their monolithic app for the sake of flexibility and scale. If they hadn't been aware of Dapr or hadn't been comfortable taking on the Kubernetes learning curve, how would you have advised them?
Ajai: Great point again about why they chose Dapr. If they didn’t have the hard Dapr requirement or the AKS skill set, I would recommend walking through the A+B principles we laid out before and arriving at the service that best meets their requirements. Just go back to your use case 
. It’s amazing how many technical folks spend endless hours doing feature comparison between 2-3 services without any regard to the business problem they are trying to solve. Who cares if a service has really cool AI capabilities if what my application needs is the ability to handle a million customer requests a minute? You see what I am saying?
Matt: When has a customer surprised you with their choices?
Ajai: My surprise is actually about low PaaS adoption. Somehow customers are still not seeing the tremendous benefit of platform of as service. My question is “If you can achieve same or better results with less work why wouldn’t you?” I actually think a shift to A+B mindset will lead to more PaaS adoption among our customers because now you are not thinking about a huge platform for your entire organization but limiting your focus and scope to a single application. The risk is low, and they can try more cutting-edge technologies relatively easily.