Customers across the world are facing the challenge of business success due to their complex application portfolios. Business always needs to change at a faster pace to be competitive in the market, but the complexity of the landscape and technical debt always pull things back and slow down the release of new features for the end-users resulting in revenue leaks and lower profits. Public cloud has proven itself an option to adopt new business models at a faster pace, reduce OPEX cost, and increase profit gains for customers. But when an organization lacks the required level of understanding and experience, then cloud adoption can be challenging and organizations can struggle with the translation of on-premises requirements to cloud concepts, capabilities, and security models. Agility towards adopting new business models, adding new features, scalability, reliability & security of business-critical applications are always a top priority for the customers which are directly linked with business objectives.
OneDeliver has conceptualized its Cloud Adoption Framework aligned with Well-Architected Framework to help build enterprise-scale cloud foundation for their Cloud Adoption journey.
There are scenarios where customers have initiated their cloud adoption journeys on their own and realized that instead of saving costs, they have ended paying more. And the reason behind this is gaps in building their cloud foundations aligned with a well-architected framework. Now the question is ‘What is cloud foundation?’ There are different views and answers around this topic. Here I am sharing my views around what a cloud foundation and its different blocks should look like:
Shown above is how the different blocks and enterprise-scale cloud foundation would look like, provided, it is aligned with the well-architected framework. A customer’s cloud adoption approach would have a higher probability of success and reap maximum benefits of cloud when it is aligned with a well-architected framework, especially with its 8 core design focus areas. Cloud adoption framework aligned with 8 core design areas of WAF would look like as below:
Customers sometimes trigger their cloud transformation journey on their own, but due to a lack of experience and methodology, they end up spending more with no or very minimum benefits of cloud adoption. The key to success and reaping maximum benefits of the cloud adoption journey is its 8 design areas which are cloud-agnostic and help our customers to define the enterprise-scale architectures. Given below is the summary of these design areas and their context towards the on-premise requirements mapping to the cloud:
- Enterprise enrolment and Azure AD tenant – An enrolment often represents an organization’s hierarchy, including departments, accounts, and subscriptions. This hierarchy represents the cost centers within an organization. This should be the starting point for categorizing the applications in migration waves and deployment topology on the cloud. Migration strategy aligned with accounts, organization, line of business & business criticality would help discover any blockers early and its mitigation plan to assure the success of the program.
- Identity & Access Management – Identity access management defines the boundary and foundation of any secure and fully compliant architecture in the cloud. Any design for IAM and Azure RBAC must meet regulatory, security, and operational requirements before it can be accepted. The technical team look at this design pattern from an authentication and authorization perspective but always miss the other important aspect like which all processes will get impacted when an application moves to the cloud. For example, how the release, operations, roles and business processes will get impacted and what we would need to do to minimize those impacts.
- Management group and subscription organization – Management groups should be used for policy assignments vs. billing structure. For example, workloads requiring the same level of security policies & compliance can be kept under the same management group. It supports a maximum 6 level depth but keeping it low is always advisable to keep the hierarchy reasonably flat. The policies can be defined at the level of Management Group->Subscription->Resource Group->Resource. Management group & subscription hierarchy is the key to revising & realigning the access policies, cost management, and operational process in their better controls that should be well thought through during the architecture blueprint phase itself. Mapping of management groups & subscription hierarchy with different environments will always help ease the operational processes around it.
- Network topology & connectivity – Network topology is a key focus area and is considered as a primary focus area by technical teams to start with a blueprint. It is a recommended approach that should be designed by considering the different requirements like organization & accounts ownership of applications, workload, priorities & objectives of different accounts toward cloud transformation, end to end network connectivity from Azure to on-premise, one Azure region to another, any other cloud, etc. Mapping the on-premise VLAN topology of internet & intranet facing applications with Azure VNet / Subnets. Design considerations about end-users & their geographic locations, no single point of failure, secure and resilient design.
- Management & Monitoring – In the context of the enterprise-scale architecture, centralized logging is primarily concerned with platform operations, meeting business KPIs, and continuous improvements of quality and cost. Logging & monitoring should be defined with a thought process of capturing relevant telemetry and generating relevant reports/dashboards. It should be focused on the platform, application, and security-centric logs with standardized and cloud-native services. Reports captured should also be mapped to actions for quality, cost, availability and security improvements to help environments to be always compliant and consistent.
- Business continuity & disaster recovery – Agility & availability of the system are the key drivers for customers to trigger their cloud journeys. There are challenges around performance, provisioning on-demand, and reliable architecture to support their operations. Considering the customer challenges around availability, reliability, and performance, it is to be ensured to map the customer requirements like network connectivity, region break down, backup strategy, RTO & RPO in the BCDR architecture design blueprint.
- Security, Governance & Compliance – Security & compliance is an important topic for businesses to have an assurance to meet the regulatory requirements when it comes to running the applications on the cloud. Design should address the encryption, key management, security monitoring, audit policies, platform security benchmark, and a framework to enable the security.
- Platform automation & DevOps – DevOps approach is very critical for enabling the target operating model and should be defined for application and central teams. DevOps strategy should be built around mapping the customers’ existing operations and development process with their target operating models on the cloud. There should be a clear definition of roles that would be required, tools, and processes to operate the application post cloud migrations. The cloud target operating model should be able to explain what remains ‘AS IS’ and what changes or improves post-cloud migrations around the operations. Automation should be used to manage policy definitions, role definitions, policy assignments, management group hierarchies, and subscriptions to standardize the cloud platform provisioning aligned with enterprise-scale architectures.
In this way, if we considered the 8 design areas of Well-Architected Framework during the define phase of the cloud adoption framework. It will help our customers to reap the maximum benefits of the cloud transformation programs and will give following key benefits:
- Cost optimization
- Operational excellence
- Performance Efficiency
- Architecture reliability & availability
- Always secure, compliant, and latest