The future of banking is on the cloud. In a previous post, I highlighted the need of legacy institutions to transition to a cloud based architecture, and as you can realize by now, it is beyond the need to serve digital customers.
However, as a legacy institution who is willing to shift to the cloud, there are several aspects you should keep in mind before embarking on your journey.
These aspects not only encompass crafting your cloud architecture but also enabling it and thus in today’s blog post, we will learn about each of these in detail.
Table of Contents
- Architecting Your Cloud Architecture
- Understanding Compliance Considerations
- Security Across Access Points
- Engineering for Resilience
- In Conclusion
- The Reference Shelf
Architecting Your Cloud Architecture
As you begin to embark on your journey towards the cloud, it is important that you instill a laser focus on architecting your cloud architecture for maximum efficiency and productivity. Strategizing early on about the core areas worth focusing, and crafting a plan to embark on a step by step deployment will not only save you the hassle of technical debt, but also costly remediation arising from failed compliances, operational efficiency and security breaches.
While there are various aspects you should consider while crafting your cloud architecture, shared below are the 5 most significant ones.
Landing Zone
One of the first and most important aspects you need to focus your attention on is crafting the landing zone. Since your landing zone will effectively be the first base of your cloud architecture, investing time and resources in designing a multi account structure will ensure that you are always compliant with best practices and standards. Ensuring your landing zone is perfectly built to suit your exact needs, will pave the way for building the right access controls, monitoring and logging capabilities, network topology and above financial management.
Storage and Container Services
Next to the landing zone, you need to focus on storage and container services. Defining early on in the process, how much storage and computing capacity you will need depending upon the workload of your enterprise will establish the base for accurately deciding on the various types of computes available in the market. Depending on the holistic needs of your enterprise, you will need to choose between server-less, container or virtual machines for computing and object, block or shared storage, thus earmarking its importance.
Shared Services
While it is true that there will be components within your enterprise which operate in isolation, these days in most cloud based architectures, components and processes almost always rely on shared services.
Thus depending upon the holistic needs of your enterprise, you need to decide on a clearly defined tooling strategy such as DevOps, FinOps, SecOps or RunOps.
Investing an ample amount of time and resources in first understanding how each of these tooling strategies function, followed by comprehending how each of them interfere with each other and your cloud platform and its services will ensure that all operational capabilities are established up front.
Governance & Data Platform
As you might already be aware, the selection of different database types determines how they cater to your enterprise, and accordingly what security controls need to be established.
Choosing the right platform, that is relational, graph, or NoSQL will establish the data classification, regulatory and jurisdictional requirements you need to meet further in the process, thus benchmarking the importance of this stage.
Security Services
Undoubtedly one of the most important aspects of your entire migration process, comprehending and establishing appropriate security policies will ensure that your cloud architecture is protected throughout its crafting and enabling phases.
Right from network segregation and access control to key and user management, you need to make use of the right tools to appropriately protect your network boundaries.
Additionally, you need to implement a cloud native security service such that appropriate guide rails are in place to offer holistic and thorough protection.
Understanding Compliance Considerations
When you are in the midst of migrating your legacy architecture to the cloud, it is important to ensure that you meet the compliance requirements of your enterprise, industry and above all regulatory bodies.
However, while at first glance this might not appear to be a challenge, in reality, without proper knowledge and an invaluable set of architectural parameters in place, you might risk exposing yourself.
Thus, it goes without saying that it is important to adopt enterprise sufficient and cloud native compliance monitoring tools such that you have real time visibility of all operations happening on your platform.
Additionally, it is crucial that the tools you implement have the ability to instantaneously alert supervising teams upon the occurrence of any suspicious activity on your cloud architecture.
Lastly, as you design your cloud architecture from scratch, it is of critical importance that you codify a robust set of security policies into your IaC (Infrastructure as Code) and automate the same.
From a data compliance perspective, automating your compliance policies will ensure that you are not only compliant across multi cloud technology estates but also actively meet all your enterprise’s data collection, classification, regulatory and jurisdictional requirements.
Security Across Access Points
Next to meeting compliance requirements, ensuring holistic security across your cloud enterprise is of crucial concern. While you might not be aware of this, the term “shared security” in cloud services essentially translates to the fact that it is the responsibility of both the parties (provider and user) to ensure security across all operational cloud infrastructure.
However, meeting this requirement is far more complex than meets the eye.
Cloud infrastructure experts across the board agree that adopting a “defence in depth” strategy is the most suited approach for designing and implementing security.
In contrast to relying on a single layer of security, establishing a multi layer approach, ranging from perimeter control and DMZ layer to user and third party access, along with a private subnet layer is crucial.
Along with implementing the security technology of your choice, it is important that you enforce security policies within each layer, such that logistical segmentation can be achieved between account and private networks while establishing a blast radius to ensure any damage to core operations during a security breach is kept to a minimum.
Engineering for Resilience
Lastly, as you strive to develop a cloud architecture which meets the needs of your enterprise, it is important to realize that at its core computers are machines and there might be instances where machines might fail. Thus, it is crucial that you have practises in place, which assist you in engineering for resilience.
For instance, in order to develop enterprise level resilience you can conduct workload level risk assessments across your enterprise in order to ensure appropriate standards are applied throughout.
Along with this, based on your enterprise’s appetite you can choose between several layers such as multi region, placement groups and multi availability zones.
Let’s understand each of them in detail.
- Multi Region: In this model you can orchestrate architectures across multiple geographies and ensure that they are isolated from each other, such that maximum protection can be achieved upon the occurrence of a catastrophic event. Given the architectural complexity, data replication and engineering efforts involved in adopting this model, it is advised that you reserve this just for your most critical workloads.
- Placement Groups: Categorizing the different workloads you have in place as per their critical definitions (such as RTO and RPO), followed by deploying them as cohesive placement groups can go a long way in developing resilience in your cloud architecture.
- Multi-Availability Zones: Lastly you can implement an architecture which uses multiple isolated zones within the same region. This can be achieved by deploying virtual machines in various multi-availability zones, ensuring that none of them act as a single point of failure moving ahead.
Additionally, in order to avoid vendor lock-ins you can also consider multi cloud deployments, however take into account the engineering and architectural complexity involved in this adoption beforehand.
In Conclusion
The future of banking and financial services is in the cloud and thus it is high time that you start investing resources in earmarking your transition.
Now that you are aware of the various aspects you need to consider before crafting and enabling your cloud platform, what do you want me to cover next? Let me know by commenting below.
Thank you for reading and I will see you in the next one.