Cloud computing is one of the most cutting-edge technologies nowadays. More and more organisations move their solutions to the cloud. This transformation is beginning to take place in banking as well, but banks have their specific requirements and limitations. What should we pay attention to and how to approach such a transition?
Cloud and its applications
Cloud technologies nowadays are being used in a growing number of ways. Their undoubted advantages are the possibility of free scaling a solution, accounting depending on the actual use of resources, the ease at which new modules and whole systems can be implemented, and also not being forced to deal with several areas connected with infrastructure or platform, as this is the cloud supplier’s responsibility, which a client does not want to deal with.
Thanks to flexibility of scaling, the cloud seems to be the best solution nowadays for all sorts of organisations which offer their products to a large number of customers. It is particularly useful in the areas, where a rapid increase of number of users or the use of system resources take place (startups, mobile and network games, promotional systems). In such cases, it is hard to provide suitable infrastructure for proper work of systems early enough if a traditional model of the organisation’s systems is used. Creating IT systems in a cloud model is the response to these needs.
Of course, the ways of using the cloud are not limited to the above mentioned areas. There are more and more organisations, even the big ones, which prefer to place their systems in the cloud, due to its other, earlier described, advantages. There are challenges connected with it, but in no other corporations are they as serious as in financial industry. To begin with, let’s look at a few definitions.
Cloud services models
Cloud services may be provided by suppliers in several ways as pictured below:
IaaS – Infrastructure as a Service
In this model infrastructure is the service provided, which means the supplier deals with equipment, most often providing virtual machines, although there are also options with dedicated physical machines. The supplier is also responsible for the network infrastructure, including load balancing, mass storage sharing and management. The client chooses an operating system and can install any software that he provides himself or receives within operating system distribution. Amazon WS EC2 service is an example of such a model.
Kubernetes – Running and managing software in containers
In this model (a variant of IaaS model) the supplier provides a ready operating system together with supporting containerization, with a dedicated management mechanism (e.g. Kubernetes). In such case, the client must supply their software in standardised containers (Docker), but thanks to this the solution may become more efficient than in a model with virtualization, allowing big flexibility, automatic scaling and many other mechanisms provided by the whole ecosystem. Apart from Kubernetes software, one may also use other solutions in this model – e.g. OpenShift. Microsoft Azure Kubernetes Service (AKS) is an example of a public service.
Cloud services in this model provide a selected software development platform, based on a chosen language and an application construction framework. Client is not free to run their own components, being limited by the accessibility of the technology, but the platorm enables automatic scaling and simplifies the maintenance and management of the solution. Google App Engine is an example of a public service.
Apart from pure PaaS, there are several variants of this technology, e.g. mPaaS (Mobile platform as a service), CPaaS (Communications platform as a Service), iPaaS (Integration Platform as a Service) or dPaaS (Data Platform as a Service).
Serverless Computing
Serverless is another model or variant of PaaS, where the client is responsible only for providing function (that is why another name is FaaS – Function as a Service). The function is provided in the form of handling defined events code, including internet requests. The provider is solely responsible for the remaining work – load balancing, scaling, function controller service, providing isolation and security. Of course, in this model there are physical servers, but there are no logical ones. As a client, we are not aware of where and in how many machines our function will be run. Charging per service here is based on memory used and consumed processor time. Amazon WS Lambda is an example of such a service.
SaaS - Software as a service
In this model we talk about providing a ready business or technical service - e.g. sending text messages. The client buys such a service and whether it is provided in a cloud model or not, doesn’t cause any change in the logic of its implementation. Of course, the client has no control of or even knowledge about how a certain service is provided, a particular task is simply given to the supplier.
Deployment models of cloud services
Cloud services can be located (independently of the model of work) in different places of the infrastructure. Depending on the location, we can talk about different variants of services:
Private clouds
Cloud services can be run internally, within an organisation, on its own servers and in its own data centres. They are then called private (or on-premise or dedicated). Running services in the cloud mode may still facilitate deployment and changes in the architecture of the solution, and also enables the cooperation of several persons and entities (internal and external) who provide software for a given institution. Such a model is also used when, due to regulation and security requirements, running a public model is not possible. Its disadvantages are the necessity of investing big capital, building internal competences and brings about difficulties in adapting to variable load comparing to a public cloud model.
Public clouds
In this model a service is provided by an external supplier. The service may be shared between several data centres, each of them may work for several clients. This model is the most efficient in terms of costs and enables effective scaling and adapting to even the most short term changes of load. However, there are challenges to face here, particularly in banking, challenges connected with regulations and security requirements.
This is a variant of a public cloud, which is not accessible for anyone interested, but for the selected ones, connected with membership in certain organisations or with similar area of activity. In such a model, the way of operating may be dedicated to specific requirements of a certain area – in banking it may be special management of a customer's data, in line with GDPR, or log service which guarantees accountability and access control, and other requirements of financial supervision. Particular members of such a cloud share the running costs and use the dedicated solutions which are available within the cloud.
Hybrid cloud
This model connects the above mentioned variants. The client may have their own cloud (with limited power) as well as use a public or a community cloud. Management software enables easy software and load transfer between them. The division may be horizontal, that is depending on the system load and also limited by the area of application – i.e. a part of services may work within a private, a part within a community, and another part within a public cloud.
The advantages of cloud technologies from the perspective of the Bank
Providing production solutions faster
Using cloud technologies and architecture based on microservices facilitates introducing software changes within small areas of architecture. Providing software may concern particular services, not whole modules or layers of a system. That is why, comparing to a monolith model, they are more easily realised and tested, and supported with automatisation, also more easily deployed.
Implementing new technologies more easily
Within the idea of microservices, particular services are independent of one another, also in terms of technology used. Using containerization and cloud services enabled the use of new technologies without influencing the systems working so far. It minimizes the risk and accelerates the adaptation process of new technologies.
Creating dedicated environments
In banking there is often a need of creating dedicated work environments, in terms of testing and production. It is most often due to specific needs of business. Traditional approach requires investments in infrastructure, network configuration etc. Running a dedicated environment in cloud infrastructure is analogical to running standard software, administrative work is limited.
Dealing with variable system load
In banks there occur certain system load peaks, whether regular – connected with End Of Day service, or irregular – connected with ancillary systems failure or marketing actions organized. Cloud technologies enable automatic scaling of overloaded services, allowing for optimal use of infrastructure owned, and in case of cloud services of a public cloud – practically unlimited scaling. There is also the question of costs involved, because the bank doesn’t have to create oversized infrastructure to be used during rare load peaks.
Increasing business innovation
Reducing implementation barriers and taking advantage of microservices, recommended in cloud solutions, facilitates implementing new services based on integration with external partners. Facilitations connected with organizational work allow for a wider scope of prototyping solutions.
Challenges connected with moving to the cloud
Regulations
Government and financial supervision regulations define several limitations for creating the bank IT systems. These include the questions connected with the requirements of protection of access to processed customer data, possibility to audit customers’ activity, accountability of employees’ work. It also concerns the question of physical location for data processed (a particular country).
In case of private clouds the above mentioned problems are addressed in the same way as in the case of other internal systems of the Bank. The difference is service in public clouds. However, one can observe the development of market offer and appearance of services in which the supplier guarantees data processing limited to a particular territory.
It should also be taken into consideration that some of the Bank’s systems do not process customer data in the form which is limited by regulations. This type of systems (e.g. connected with marketing, or testing environments of main systems) can be safely moved to a public cloud.
Customer data security
Customer data protection is also enforced by regulations, also in connection with GDPR directive. Data processing within a private or a branch cloud should not be contrary to the requirements of these regulations, and managing this data shall not be different than in case of internal systems of the bank.
The challenge here is dealing with customer data in a public cloud. Here, the bank does not usually have full control of the way data is served by the cloud provider. Still, there are mechanisms, depending on the kind of data and the way of processing information, which enable securing information. It is possible to use pseudonymization or customer data encryption, where the keys are only owned by the bank and they are not disclosed to the cloud provider. Nevertheless, such a solution affects the efficiency and additionally complicates implementing certain mechanisms, e.g a search engine, where search index contains fragments of actual customer date, and the sole encryption is unpractical or not efficient enough.
General security
Constructing proper security mechanisms is a challenge in cloud solutions. It concerns not only a public cloud (where, of course, due to the cooperation with an external provider, it is a much more important issue), but also a private cloud. Certain mechanisms must be adjusted to significantly distributed infrastructure, dynamic scalability of particular modules and significant independence of particular components.
Such an environment enforces the use of suitable tools for monitoring, particularly suspicious activity occurring, security breach, the use of data and estimated levels of risk of certain threats. Mechanisms of automatic recognition and informing operators about attacks should also be implemented.
Apart from suitable tools, it is necessary to implement and control suitable security policies and standards concerning data encryption of transmitted data, using tokens, dealing with sensitive data and generally speaking, running components in the cloud.
The necessity of sharing responsibility with a provider
This challenge is a question of applying suitable philosophy. Legally, it obviously requires suitable agreements, but accepting and controlling the risk from third parties is necessary. It also means creating proper relations with the provider and avoiding a situation of being dependent on him (Vendor Lock In).
The hardness of the very process of transformation is a considerable challenge. Of course, moving to the cloud requires a lot of organizational, legal and financial changes, apart from creating the very strategy and vision of changes. The transformation process from the technological perspective is only an element of the whole venture and support for it can be received from trusted system providers of the bank.
Obviously - gradually. We recommend Agile methodology and beginning from a private cloud, into which, initially, services of one system may be transferred. It is optimal to move the architecture of the systems of the bank to the model of microservices and using containerization of software. Additionally it is advisable to work on automatization of the construction, testing and deployment of software (Continuous Integration & Delivery). It is also important to use proper tools in monitoring, tracking data processing and performance analysis in a distributed cloud environment.
It is also crucial to pay attention to building competences connected with security and regulation requirements in terms of distributed environments, where a part of responsibility concerns external partners.
The above mentioned steps will later enable fluent implementation of solutions in a public, branch or hybrid cloud and affect minimizing the risk connected with introduced changes. It is also necessary to remember that certain systems of the bank may never be moved to the cloud – every module and service should be separately considered, and the advantages and disadvantages of moving them to the cloud should be analyzed.
[EDIT] More about cloud: What a cloud solution should look like?