Cloud Native Lock-In Strategies are Complex: Adopt the Industry’s Best Kept Secret As Your Solution

As the FS industry's demand for cheap, flexible, modern infrastructure services continues to gain momentum, there is a rapid push to assemble a robust cloud strategy. This is a heavy task: the key outputs will likely lay the foundations of Banking Industry's technology roadmap for the next 4-5 years. Now that all their cards have been laid down on the table, Banks are facing some serious questions challenging their true commitment to technology-first as well as their overall appetite for change.

The Cloud Exit Strategy position in this strategy is paramount. Companies are looking to shrug off the bitter-sweet era of the "omnipresence vendor"; a time where software lock-in and bank-vendor interests were intertwined across most areas of the bank. The Exit Strategy is empowering: it is allowing banks to set a safe level of vendor boundaries whilst also benefitting from cloud-native vendor products & services.

The Necessary Performance-Commitment Trade Off

By design, Cloud-native features offer tempting ROI but can somewhat tie you to the unique solution. Adopting a cloud native feature requires some faith: for example, in the feature roadmap, the ongoing reliability and investment.

Alternatively, a blind Lift-and-Shift mentality will lead to activities such as snapshotting VMs and ingesting them directly to the target VM provider service. This is mostly portable but with zero cloud advantage with a potentially higher TCO.

Serverless is a key example of this trade-off. A well-architected serverless implementation can offer vast cost and speed benefits ranging from near-instant scaling, top world resilience, to drastic reductions in running costs. AWS Lambda, for example, is widely considered the most mature FaaS (Function as a Service) offering, allowing the engineering team to think of nothing but the provisioning of the intended code. The ROI of adopting FaaS is staggering: some calculations of a 3-tier autoscaling Rails application serving 100k page views a day on EC2 costs roughly $427.04. Using Lambda and API Gateway, this would conservatively cost tens of dollars[1].

But the road to serverless is usually not an easy one. This will likely require platform re architecture and the evolution of your SDLC across areas such as code deployment, logging, debugging, configuration and even how the code is actually written. Thus, up-front adoption outlay is required but will usually offer a rapid break-even position.

Top cloud feature considerations

Generally, the more services used the more the danger of "lock in". Even some of AWS EC2 config items can be considered AWS specific. The below is an indication of some services in general that require consideration from lock-in perspective:

Function

Considerations

Config Management

Most Cloud Providers have their own config management tool (e.g. CloudFormation). Whilst these offer the right level integrating into the ecosystem, there are a wealth of mature Open Source alternatives such as Terraform. Open Source adoption in some cases is considered a worthy tradeoff dependant on the organisation’s Risk Appetite.

Microservices/ Containers

Componetising an application into a series of stateless microservices is a great strategy to stay cloud-agnostic. Containers were built with flexibility and portability in mind. As long as consideration is made with regards to any native orchestration layers, frameworks such as Mesos and Kubernetes are fantastic at abstracting away underlying infrastructure services. Reference Contino’s Container Debate (1h 40m video) for some in depth pros and cons of each offering, including native flavours (e.g. AWS ECS).

FaaS

Many flavours also exist for FaaS but it is early days: these include Azure function, Fissino.io and Apache OpenWhisk. Although still in an incubation stage, OpenWhisk may be an Open Source alternative to keep an eye on.

Without going into the gritty details, a large Lambda exit play would likely be a complex undertaking of significant size. This risk of exit needs to be offset against to the large ROI offered.

Serverless components (e.g. API Gateway)

Depending on the function, AWS is by far the most advanced in terms of serverless architecture and components. Careful consideration around the required capability should be maintained on the architecture and the serverless workings, as well as any viable alternatives. The most useful components should be adopted given their benefits to the application.

DBaaS

DynamoDB, Aurora, Google Cloud SQL, Azure SQL Database, for example, are all offerings that offer superior functionality and ROI than a simple Database app running on top of a VM.

Complex organisational data sets could be one of the more complex exit considerations. Only by analysing the given varieties of schemas, sizing, availability requirements and in-house capabilities can a strategy for an exit solution be devised. A deep dive into a migration strategy and data sensitivity is key in selecting the right way to deal with each of the given databases.

It is also likely that a “one size fits all” DB exit strategy will not suffice for the Bank’s high quantity of customer sensitive, transaction and market data.

Elements when considering Lock-In and consequent Exit Strategy

A Cloud Lock-In and Exit Strategy should also be reviewed against a number of non-technical perspectives. The following are some additional key areas to consider when considering Cloud native decisions:

T&Cs - What are our responsibilities as a customer in general, and what happens when things go wrong? e.g. a successful DDoS attacks.
Intellectual Property (IP) - how is the IP managed and what are your/the vendor's rights on the IP stored
Liabilities - what is the vendor/customer liable for in the case of a breach of any of the agreed conditions.
Pricing - what is the cost of the service and what is the volatility of ongoing costs. In the case of an Exit, what are the costs involved, including a migration and the alternative hosting service.
Fallback - for each of the positions taken in a cloud strategy, what is the fallback position including required agreements, network infrastructure and test strategy. Be prepared.
Roadmap - product roadmap: what is the dependency of your business on the future roadmap of the service, and what is the risk of deviation
Exit Logistics - who or what constitutes an exit, on what grounds can these be triggered, and who needs to sign off and be deliver the execute.

Two Differing Approaches to Cloud Lock-in

In my opinion, if the Cloud era has brought one single important idea to fore it is this: a bank cannot simply abscond all responsibility of a business component through a vendor-based agreement. A successful organisation functioning in synchronisation with technology needs to be fully committed to the capabilities, tools, and processes that are required to achieve success. And the higher the business value of the items, the higher the warranted technology investment and prioritisation.

This links to the trends of the uptake of Public Cloud across Europe over the last 12 months.

Take the following example of the 2 common contrasting cloud strategies:

Bank A fully commits to Cloud and initially focuses on the best solution to separate the bank's concerns as much as possible from the cloud providers, using architectural & contractual means of measurement. Effectively, the bank has taken on the role of Vendor Manager where it elects to operate as a hub with spokes of services tailored for for usage as and when required
Bank B fully commits to Cloud, and initially focused on exploring the new technology to business challenges and prioritises those that return maximum value. These companies value curiosity above all and set about experimenting with proving out this theoretical ROI. They in many cases succeed in implementing new platform and set the tone of their organisation’s cloud capability. This bank has taken the role of “The Explorer", and as a side effect, is investing and prioritising in the capability of the teams to investigate and derive their learnings that will in turn, drive the strategy.

Implication of Cloud Migration Personas: “Vendor Manager” vs “Explorer”

Bank A is now fully invested in trialling different tools and assembling papers and decks, and in extreme cases, begin constructing complex Cloud Broker Layers. Unfortunately, at least 1 year into the project they are yet to achieve any ROI or convince their colleagues of the benefits available, or even hint at the possibility of a potential enterprise cloud adoption model (cost, authority, usage). At this stage, any plans for cloud adoption starts to lose momentum.

Bank B now has a few applications running and can demonstrate some extraordinary abilities such as provisioning infrastructure on demand, an end to end API-driven CD Pipelines, and full auditability and visibility of their stack and the changes in a single pane of class. In many cases they are achieving significant ROI in a very short time sparking further interest.

During this “exploration”, Bank B may have made use of some cloud-native features. However, the rationale for adoption as well as exit strategies were formulated during the architecture and implementation phases. Most importantly, this team has been empowered to try, learn and now has direct experience of their application in cloud. This knowledge puts Bank B in the best position to execute an exit.

The Cloud Lock-In Secret

Counterintuitively, the bank that is too fixated on an exit strategy gets bogged down by Planning and never dives deep enough into the new waters of cloud to fully understand it. Potentially, by the time the A strategy has been defined, a new phase of cloud will have dawned and require a reassessment of all the assumptions.

If an Exit is required, the bottleneck and the challenge to execution will undoubtedly be the capability, experience and skills of the organisational teams. By up-skilling and empowering the entire team in “Explorer Mode”, the teams will understand the pros and cons of various cloud technologies and characteristics will provide the best team to navigate their way through an exit, migration or any changes or catastrophes.

In my view, the best approach to avoid an unhealthy vendor-customer relationship is to focus investment on building out the capability and skills of your internal teams, empowering them via training, processes and resources to operate at an optimal level. Giving them experience to get hands on and understand these technologies will ensure that also Cloud Lock-In is a moot point, given the internal teams have the ability to put the right strategies in place. Where teams have real world experience and maintain an emergent design that include exit strategies where required they don’t spend their time writing Powerpoint decks being bogged down in analysis paralysis.