Why you should modernise your Cloud environment first before you think about modernising applications
Preface to Modernisation in the Cloud
Modernisation is a frequently used term in any technical sphere and it is increasingly applied to a Cloud situation: we want to modernise this into that. Modernisation relates to both where you were and where you want to go; and often it is recognised that even then, that is just a stepping stone to something else.
Modernisation is about exploiting the benefits of Cloud technologies generally acknowledged to be:
Elasticity and ability to scale,
reliable availability,
operational ease leading to organisational agility,
security, and
cost-effectiveness.
In this, the first of three blogs, we explore why you should consider building a modern environment first, one which is architected to AWS best practice, before you think about modernising the way you run your workloads.
In the second blog, we explore how to start leveraging the benefits of the Cloud, by optimising how to run legacy workloads with minimal code changes, new code using newer features available in AWS Cloud.
In the third blog, we explore the final nirvana - striping down the monolithic applications into pure Cloud-native services - which integrate together to provide your users with the functionality they need, and deliver significantly more benefits than legacy technologies.
Why Modernise the Cloud Environment?
When you start your journey with Cloud, whether that’s a migration or first build, it’s a bit like moving house. You set it up how you think you want it, and everything from the old place found a new home, but it was never ideal.
These are some of the challenges you may have with your current environment:
It grew organically over time, without standardised processes in place from the outset.
You didn’t map out how to assign applications to accounts:
some applications were all in the same account,
whilst in others, multiple accounts were set up for different teams.
You put your different Production and Non-Production accounts on different VPNs
You didn’t plan out how to assign users to applications or development environments:
some roles were over-segregated, making the environment difficult to manage and work in,
some were under-segregated making security difficult to manage
You didn’t think too much about overall security posture
Many users have access to resources they don’t need and shouldn’t be using
You have no way of knowing for sure that everything is secure
You are lacking ’Observability’ - the ability to see what’s happening in the different layers of the environment.
Your Business Continuity is based on the premise that presumably it’s all recoverable somehow.
Modernising your Cloud environment is like being able to design a new home that’s perfect for all the stuff you have now, and everything you plan to do in the next few years. It has locks on all the doors - even the internal ones, and security cameras installed inside and out.
Designing the perfect home, there would be a few things you would think through before you start. Likewise with Cloud environment modernisation - here are the things you’d want to think through before you start.
Account Structure
Though designing account structure and Identity & Access Management (IAM) is not rocket science - it’s worth implementing a best practice approach from the outset, as this will stand you in good stead once you begin to scale. In AWS environments best practice is usually with the Well Architected Framework.
For example: you might have customers who need dedicated AWS Accounts and others happy to be co-tenanted. Or you might want to design an environment which can scale to many AWS regions, in order to host the application and data within the closest AWS region to the customer both from a latency and data sovereignty perspective.
Consider the current state of your application development architecture: are you looking to continue support for VMs or move to Containers or even serverless? All these have a bearing on account structure.
AWS Organizations
Consider using AWS Organizations which allows you to programmatically create new AWS accounts and allocate resources, group accounts to organise your workflows, apply policies to accounts or groups for governance, and simplify billing by using a single payment method for all of your accounts.
AWS Control Tower
AWS Control Tower provides a straightforward way to set up and govern new, secure, multi-account AWS environments based on AWS best practices. These include the Principle of Least Privilege to ensure users only get access to the resources they need to do the job. Preventative and Directive Guardrails are then applied through the Control Tower dashboard.
A preventive guardrail ensures that your accounts maintain compliance, because it disallows actions that lead to policy violations.
A detective guardrail detects noncompliance of resources within your accounts, such as policy violations, and provides alerts through the dashboard.
You can use the blueprints available in Control Tower to set up the most commonly used Guardrails.
You can standardise the provisioning of new accounts using a pre-approved account configuration template.
AWS Control Tower can also be set up to provide centralised logging for all AWS CloudTrail events throughout all AWS accounts in the Landing Zone.
Directory Services
Plan how you want to define, enforce, and audit user permissions across AWS services, actions, and resources, using IAM, AWS Single Sign-On and SAML Integration to federate Azure AD.
Security Features
AWS provides a comprehensive suite of security and identity services and features to enable you to improve your ability to meet core security and compliance requirements, such as data locality, protection, and confidentiality.
Plan to improve your security posture, reduce the risk profile of your environment, and gain the visibility you need to spot issues before they impact your business. Select the components you will need in your environment and connect them together through Security Hub to create a single dashboard where you can view the health of your security posture.
It provides Observability which goes beyond mere monitoring (even of very complicated infrastructures) and is instead about building visibility into every layer of your business.
Data Protection
It’s probably not just your data, but also your customers’ data, and maybe, even their customers’ data. Implement appropriate safeguards that help protect data in transit and at rest by using natively integrated encrypted services.
Consider Business Continuity: do you need another account in the same or a different availability zone? Are you meeting data sovereignty and other compliance requirements?
Network Design
You will need to map out a network baseline, IP addressing scheme, connectivity and routing model, and consider remote access connectivity and whether this architecture design is scalable to meet future requirements.
Automation and Infrastructure as Code
Last but by no means least: automation. Automate everything you can. Implement Infrastructure as Code, using AWS CloudFormation to manage the lifecycle of AWS resources, to maintain reusability and auditability.
AWS CloudFormation provides a common language that allows you to model and provision, in an automated and secure manner, AWS and third party resources needed for your applications across all regions and accounts via a plain text file. This gives you a single source of truth for your AWS and third party resources.
Benefits:
Flexible and Declarative
Customisation through Parameters
Automation and Deployment
Cross account and Cross region management
Bottom line
A reminder that as you plan to modernise your environment, keep the Well Architected Framework in mind.
As a result, because you thought about reliability, built in security and operational ease (by using the right tools and automation), it means that even as you scale, your modernised environment will stay secure, reliable and easy to manage.
You will also have increased visibility which gives everyone invested in the business greater insight into issues and user experience, and creates more time for more strategic initiatives, instead of firefighting issues. It’s also critical to the overall success of site reliability engineering (SRE) or DevOps organisation models. As you will read in our next Blog on Cloud Optimisation, in modern DevOps development processes, developers need visibility into operational performance as much as traditional ops teams or SREs.
If you would like to discuss any of these concepts in relation to your organisation, or need help with implementing any of them, PolarSeven is just a phone call away. We would be happy to give you a free consultation to discuss your unique situation.