Sonali Deshpande Designing and provisioning multi-tier workload

Automatic Summary

Designing and Provisioning Workloads: Navigating the Modern Cloud-Based Strategies

Hello everyone, Sonali Deshpande here. I'm a cloud solutions architect at the Gemini India and very thrilled to have this opportunity to speak in this global conference, thanks to the Women Tech Network. Here, I'll be discussing a very pertinent subject in our cloud-first world - the strategizing, designing and provisioning of workloads while exploring avenues for application modernization and business agility.

Understanding The Market

With the pandemic, there has been a substantial elevation in the adoption of cloud-based strategies, owing to their high speed, agility and ability to optimize businesses for cost effectiveness and increased productivity. This has led to a shift in migration strategies towards application modernization and refactoring. The need to standardize and automate the deployment of infrastructure and platform is crucial under these circumstances, paving the way towards leveraging infrastructure as a code or configuration as code libraries.

Today's Enterprises - Cloud Transformation Journey

When an enterprise embarks on their cloud transformation journey, they usually opt for a private cloud strategy, evolving towards a public cloud strategy as the level of confidence and maturity improves. With experience, companies often switch to a multi-cloud strategy or a hybrid model for better cost optimization, vendor neutrality and for business continuity and disaster recovery purposes.

Let's consider the diverse workload types of the enterprises in question - compute workload, web workload, batch workloads and serverless workload. Compute workload comprises of virtual machines for compute memory configurations and different storage services, while web workload consists of integrated databases or storages with app containers.

Achieving End to End Automation

The prime challenge is to build an effective strategy for full automation in the complex scenario of a multi-cloud, multi-tier situation. This involves defining the modernization criteria, understanding the application type and its integration with peripheral systems and making the correct decision on deployment models. The modernization criteria could include performance elasticity, cost reductions, security, high availability, agility improvements, innovations and relative ease of migration.

Mapping Modernization Criteria Across Deployment Models

A suitable example here would be the performance criteria, where infrastructure as a service, platform as a service and container as a service would be effective options. The high availability criteria would be best handled by the infrastructure or platform as a service, since it offers ready availability SLAs.

Reusability and Accelerators

The major cloud providers, such as AWS and Azure, provide their own infrastructure as code libraries. However, to standardize the infrastructure, the Terraform tool could be beneficial. Terraform allows for the easy deployment of scripts onto the platforms using DevOps pipelines, ensuring predictable and consistent movement towards building the target state of the application. In addition, it retains the state of the target platform, facilitates cost saving on unusable platforms and enables faster deployments and feature release.

Successful Deployments: Some Examples

For example, in a Platform as a Service scenario for a web application migrating to Azure, the components catalog will be comprised of web app model, MySQL model, active directory and application gateway. Similarly, in a Container as a Service scenario, the components catalog will have Kubernetes for container orchestration, logic apps for serverless workloads and Cosmos DB for as data storage, among others.

Using patterns and component libraries effectively, cloud platforms can be built, providing successful end-to-end automation. Once you have gone through careful planning and followed the outlined pattern, the application becomes ready for cloud migration. Remember, every application is unique and might require slight deviations from the plan, which can be managed accordingly.

That wraps up our session. If you have any questions, feel free to ask. And once again, thanks to the Women Tech Network for making this possible.


Video Transcription

So today's session is about designing and provisioning workloads. Uh Hello everyone. I'm Sonali Deshpande. I'm a cloud solutions architect at the Gemini India. Uh First of all, I would like to thank women tech Network for giving me this opportunity.This is my first time ever experience uh as a speaker in global conference and I really want to thank in I and team here. Uh I'm a cloud solutions architect, having experience in cloud assessment and transformations and infrastructure as a core libraries. Uh So we are in today's uh cloud first world and uh enterprises are moving towards gearing towards app modernization or you know cloud native approaches. Uh And they have significant footprint of their highly business critical applications which require faster time to market speed, agility, etcetera.

So especially post pandemic, what we see is cloud market is rapidly growing and uh businesses wants to be agile, bring value to the infrastructure and cost optimization and increase productivity. Uh As I said, cloud migration strategies are mostly gearing towards uh application modernization and refactoring.

Then the standard lift and shift approach and the top trends impacting the cloud adoptions are the cost agility, portability, multi cloud strategies to avoid vendor locking, et cetera. So in this scenario, how do we standardize and automate the deployment of infrastructure and platform, how to leverage infrastructure as code libraries or configuration as code libraries to represent the target state of platform? That is the ask here. OK. Uh So let's take a pause and let's take a look at the uh problem statement and details. Yeah. So when the enterprise start their cloud transformation journey, they start with DC exit or a data center exit kind of a scenario. Uh When they start initially, they have less confidence in the public cloud uh in terms of securing the workloads and they opt for private cloud strategy as and when the maturity increases, uh and they come to know that, you know, you can still manage uh secure workloads in public cloud.

Uh They go for a MOOC cloud strategy and a hybrid cloud model. Yeah, some data on the on premise and uh some uh landscape in the Azure or any of the cloud providers. Yeah. Um over an experience uh with these uh single provider, uh they now decide to move on to a multi cloud uh scenario uh where they want to give a solution for their business continuity, disaster recovery kind of a sort of solution because certain services may not be available at one hyperscale in one region and they want to take benefit of those kind of things.

Also in terms of cost optimization cost negotiation. And also to avoid the vendor lock in kind of a scenario, they can get into a multi cloud and a hybrid scenario. Let's look at the workloads uh of the enterprises. The those for different types, a compute workload, a web workload, uh compute workload compromise. Uh you know, comprises of uh uh infrastructure kind of a workload where you have the virtual machine storage where you have to configure the compute memories if you RM. And uh also in terms of storage, you have to configure your disk and uh different storage services, uh workloads, web workloads, you will have your apps plans. Um You might have integrated uh you know, databases or storage with the web workloads as well. Uh batch workloads. This again falls in the compute category, serverless workload where we are seeing, you know, function as a service model. And uh now with the latest cloud optimized and uh native platforms, we have uh cober native or containerization as one of the uh workload category. Let's look at our application deployment uh view. Uh We, we need to have the uh uh you know mechanism to deploy our applications as well as infrastructure platform to their different environments, you know the development testing, staging and product. Similarly, with application, we have uh different environments and we need to move to the productions. That's the end goal. Yeah. Uh Likewise, we have uh if it's not uh only enough if we have applications, uh automated deploy platform also go uh in line with the application. Yeah.

And on top of this, we also have to adhere to the different slas like cost agility up time, slas faster time to market, et cetera. So we are talking about here a multi cloud, multi tier uh scenario and option and in this complex scenarios, how do we achieve end to end automation? So building that strategy is in a very important aspect for a successful uh cloud transformation or a move to cloud program. So that's the ask here. Uh I have moved to the next slide. And what you can see is the strategy accelerators and how we can achieve the end to end automation. So building a successful strategy understanding the type of application and its integration uh with its peripheral system that is going to help us build the well-architected decision framework. So we start with uh you know, categorizing our uh enterprise applications into different uh categories here like as you can see on the screen portal. Uh so your web application workload can go into the application and the component catalogs of portal and web friend. You can have web services, microservices kind of a thing into services or transactional uh application types. Then you have integration storages, uh S SI S SAS kind of uh applications into a business intelligence stack. Then you can have that such as as your of the application category.

Then comes your deployment models. Yeah, infrastructure as a service platform, as a service container, as a service and a function as a service. Then we have the modernization criteria that needs to be defined. Yeah, so we have a modernization criteria like performance elasticity, security, high availability, cost reductions, agility, improvements and innovations and easy to migrate. So how do we map? Let's take an example of portal and web front. So uh we have a standard vanilla web application, for example.

Yeah, the variant could be having a content management system, integrated word price or a drupal or uh you know any content management system integrated. One more variant of this could be, you know, web server, fully managed and then the integrated database, uh my SQL kind of a database with it. And then when we say mapping this uh modernization criteria across the deployment model. So let's take an example of performance. When we say performance as a modernization criteria, we can provide a solution uh in the deployment model of infrastructure as a service platform, as a service container, as a service. But we may not go for function as a service where we want to carry out a specific uh compute or a workload operation. Yeah, uh performance could not be a criteria there. Maybe load is one of the criteria we can address but uh performance will be better handled in the infrastructure or pa or cause kind of a scenario. Uh Then when we take an example of high availability. Yeah, so pa could be a suitable thing uh infrastructure as a service. Uh Here, we need to ensure that we are designing uh the architectures adhering to the sls of the cloud providers. Yeah.

So pa gives us the ready to make uh you know, 99.99% up to 9 9% availability uh slas so some of the cloud providers uh claim to provide that kind of availability. Of course, we have to follow their uh best practices in terms of designing our uh applications and their platform with those guidelines. So what we can make use of these guidelines uh from the major hypersal like Aws well architected framework, Azure architecture center where they have clearly defined uh you know architectural patterns for your different type of workloads. Let's move on to re reusability and the accelerators.

So cloud providers like Aws or Azure, they provide their own infrastructure as a code libraries uh platforms like cloud formation for Aws for Azure, it is uh you know arm templates. But when we look at the uh look at it from the standardization perspective, we can for a tool like terraform which allows us to uh standardize the infrastructure as a code libraries using the hashi common uh you know HCL languages. And uh also deploying these uh uh scripts into the onto the platforms using the devops kind of a pipeline. Yeah, Azure DeVos or a Jenkin uh tools can be used here. Uh And uh Terraform tool also provides the out of the box libraries for the platforms like Azure, Aws, Google Cloud and many others. Yeah. Uh When we talk about the configuration and code, uh we can look at the tools like Chef Puppet, uh those kind of tools will help us the uh configuration of the uh workloads at a scale. Yeah. So what we are doing here is we are achieving uh predictable and consistent in a predictable and consistent manner. We are moving towards or building a target state of the application. So we have done a careful planning of your application type.

We have a guideline architecture that is in place. And then for uh application that is a candidate now for moving to the uh you know cloud, we can use that model as a reference and then apply. Uh Of course, there will be some deviation, uh you know, every application is not seen and there will be different deviation scenarios. And that at that point of time, we can address them in the best possible situations. Yeah. Uh when we say retain state of the target platform, so tools like terraform help us to retain the state as well. Yeah, so if your uh specific data center is down or the region is down, and if you want to spun up that uh region in a fraction of seconds, we can always go back to the version within the state and also uh you know, deploy and spin up the V uh the platform in a fraction of second when we say cost saving on unusable platforms.

So once the dev and testing and Q A are executed and those platforms are no more required, we can destroy those, destroy the pi pipelines unwanted once our production workloads are ready. Yeah. Uh With this overall automation, we achieve faster deployments, new feature releases in less time or within a fraction of uh time period. And we also achieve the speed here. This is the way we achieve end to end automation. Now, let's look at one of the example here, a reference pattern for a cloud computing model for a platform as a service scenario. Let's take an example where we have to migrate the web application which is to be taken on the Azure platform. So what we see here are different connectivity mechanisms between your on premise and Azure. So you can have express route uh for point to site connectivity. We can have uh gateways configured and through dmzs and application gateways, you can have securely connecting to your web app.

Uh So what forms your components here? Yeah. So, so your application type remains here, a portal or a web application and your component catalog will be comprised of now a web app model. Uh My SQL model could be active directory application gateway and uh there could be other networking kind of components in terms of gateways, express routes, et cetera. But you can have uh these kind of uh you know, infrastructure components built on hand uh before uh what you do, what enterprises do is they define these kind of uh networking or the uh structure uh in advance. And then on top of that, we build our application platforms. Yeah. Uh So in terms of AWS, maybe we can have elastic be stock and the variants of the R DS or equivalent uh database. Yeah. So this is the reference pattern for the uh uh cloud uh computing model platform as a service for a web application. Uh Another scenario is container as a service uh where we have uh Cober native service. Uh uh We have, you know logic apps, serverless workload in terms of Azure functions. Uh and uh API application also configured uh through uh API gateways and also the container services. Uh We have Azure SQL databases, Cosmos DB.

Those are the data storages along with uh the uh primary data storage is like you know, blog and the file story. So all these can form a component catalog for you and it is just a matter of following the pattern and then picking up these components from your libraries and building that platform architecture uh for a specific application which is moving to the cloud. I think that's about it.

Uh Pretty much uh I am here to take uh questions now if you have anything So thank you everyone. I will sign off from the session now. Thank you once again woman in tech network for giving me this opportunity. Thank you.