DevOps in Financial Services: Benefits, Myths, Case studies

There are multiple reasons for financial companies to adopt working according to DevOps workflows. Better predictability, smoother operations, lower expenses, and more…

The financial industry has always been among the most innovative and technologically advanced areas of business. Nowadays, in the technologically advanced and digitized world, the customers want their finances to be available on the move, managed with convenient apps and their Personally Identifying Information (PII) like banking card numbers to be kept secure.

DevOps is the modern way to organize the business processes, software delivery pipelines and operational workflows to increase reliability, deliver more value and optimize the expenses.

In order to comply with these requirements and remain competitive on the market, financial industries have to leverage all the benefits and best practices of modern IT technology to ensure the reliability of product releases, the uninterrupted end-user experience along with reduced operational expenses. Implementing DevOps in the financial services sector can help accomplish all of these goals, and below we explain the benefits of the transition to DevOps culture for financial companies.

Benefits of using the DevOps practices in financial operations

DevOps is a set of operational patterns, best practices and tools aimed at optimizing every aspect of business operations, not limited to IT operations. Here are the main benefits of utilizing the DevOps approach for financial institutions:

• Security and compliance. The financial industry has to comply with multiple regulations to ensure the security of customer data. DevOps principles of Continuous Integration (CI), Continuous Deployment (CD) and provisioning the immutable Infrastructure as Code (IaC) result in automated software lifecycle pipelines with no room for human error or malicious intent.When the software is thoroughly tested using automated test units before building the new code batches and pushing them to production, the security concerns are addressed from the get-go. Besides, once the regulatory compliance is reached and codified, the same scenario is multiplied and repeated, largely removing security and compliance concerns from the product development lifecycle.
• Automation of routine operations. DevOps tools are intended to provide in-depth automation of multiple processes involved in software development and maintenance. Server provisioning and configuration, database backups and restoration, software updates and rollbacks, testing environments setup, software delivery pipelines, production servers monitoring and logging — all of these daily routine tasks can and must be automated.Once the DevOps engineers design and implement the automated workflows and pipelines, the IT departments can finally begin devoting their efforts to improving operational versatility and infrastructure performance, instead of having to permanently budge through repetitive, low-skill and time-consuming tasks.
• Better predictability of the release cycle. This is the natural outcome of the previous paragraph, as when the majority of processes is operated, the degree of predictability grows dramatically, so the business is able to deliver more value to their customers, through ensuring rapid feedback implementation and uninterrupted product operations.
• Better collaboration between teams. DevOps culture concentrates on communication and collaboration between various departments. As financial businesses nowadays are either geographically distributed or outsource some chunk of their operations, effort concentration and effective collaboration are important concerns of operational stability.“You build it, you run it” is one of the main DevOps principles. Ops have a say on the stage of software design, so the Devs can adequately evaluate the number of resources needed for their software to work and plan its architecture accordingly. Vice versa, Ops are involved on all stages of software development and help the Devs implement the customer feedback faster, so the code is not tossed over the wall to be somebody else’s problem.

Despite multiple tangible benefits, there are some concerns and myths surrounding the use of DevOps approaches, which hinder the speed of DevOps culture adoption across the financial industry. We briefly list and dispel them below.

Myths that hinder DevOps adoption in the financial industry

Money likes silence, as we all know. In the financial industry, this means the stability of operations, constant availability of services, predictability of outcomes. DevOps methodology is a major disruptor of the old ways, and so many financial businesses are afraid to begin their DevOps journey amidst the Early Majority of the innovation cycle, the ones that reap nearly all the benefits.

There are 3 major myths about the DevOps approach, currently popular amongst the majority of financial institutions. We dispel those myths and hope that your company does not give them credit, or you risk to fall into the late majority or even laggards category and lose your competitive edge. The myths in question go as follows:

1. DevOps is a mix of Dev and Ops engineers in one team
2. DevOps cannot run the legacy infrastructure used in banks and other financial companies
3. DevOps principle of releases changes is detrimental for the financial sector
4. DevOps must encompass the whole company to be effective

All of these myths are utterly and totally unjust, and here is why.

Myth 1: DevOps is a mix of Dev and Ops engineers in one team

This belief was born in the early days of DevOps era and is still popularized by the “IT experts” who have little hands-on experience and do not know what is DevOps. Actually, the difference between the traditional and the DevOps workflows looks like that:

A developer has his own development environment, where he writes the code. Once the new batch of code is written, build and testing servers must be provisioned by the Ops personnel to build and test the code. After the bug fixes, the Dev tosses the code over the wall to be the Ops problem from now on, and the Ops have to make sure the code runs well in production. If after the release it turns out there are still bugs in the code, the Ops have to revert the changes and the cycle begins anew. The Devs and the Ops rarely interact

We don’t need to mention all the flaws of this approach, like siloed tasks and responsibilities, configuration drift, multiple approvals, operational bottlenecks, high risk of faulty releases, constant stress for all the parties involved. This is exactly why the DevOps approach was founded almost a decade ago.

A DevOps engineer is an Ops engineer, who has a say in software development. They do not enter the game when the product needs to be deployed and maintained, and they do not provision/configure the servers manually. DevOps engineers discuss the requirements and modus operandi of the future software with Devs at the start of the project, so the Devs know what resources will be needed, and the Ops can decide how to allocate them best.

The main benefit of DevOps approach is that the Devs and Ops communicate and collaborate with each other to remove lots of waste and increase the predictability and reliability of software delivery.

Myth 2: DevOps cannot run legacy infrastructure in banks

Stability is essential for banks and other financial companies, as the downtime of their services means literal money losses every minute. This is why the banks are strongly conservative towards the infrastructure management — the systems they use are built for years and decades, and nobody is willing to make any rapid changes to the architecture or workflows.

However, operational stability is actually the main goal of DevOps workflows and practices. The server configuration procedures are described with Kubernetes and Terraform manifests. This means the cloud infrastructure is managed as code, excluding the possibility of manual repetitive setup and configuration drift. Ansible and Jenkins allow building the pipelines, where every action is automated — from code building to provisioning the testing environments, testing the code and packing it for release, updating the production servers without service interruption through rolling updates, etc.

As a result, implementing DevOps in banks results in better security, uninterrupted server availability, faster updates. DevOps tools can handle legacy on-prem infrastructure just as well as the public cloud because the system stability and performance are the goals of DevOps practices.

Myth 3: DevOps practice of faster releases can be detrimental for the financial sector

This myth is also based on the fear of service outages, as the previous experience shows the managers that releasing the updates quickly can lead to major bugs making it all the way up to the production servers, obviously leading to costly service outages. The core issue here is that the managers do not take into account THE REASON for faster releases — automation.

With DevOps, the testing happens all the time, automatically, through unit tests. The code building pipeline can be built in such a way that EACH COMMIT BECOMES A RELEASE if the code passes the tests correctly. In addition, all infrastructure components and code are reusable, which shortens the setup time and effectively reduces the time to market for new products and services.

The best thing — the releases do not require shutting down the production servers for updates, as DevOps tools like Ansible and Jenkins enable the rolling releases. Every production server is updated in turn, while the customers are rerouted to other servers, WITHOUT ANY SERVICE INTERRUPTION. This is why DevOps approach to software delivery actually leads to better customer experience and does not pose the risk of hasty and faulty releases of the past.

Myth 4: DevOps is a tectonic change that must be applied to the whole company at once

This is also a logical outcome of the previous 2 myths. The management values stability and predictability overall, especially in financial services, as not every change is for the best. As digital transformation and implementation of DevOps methodology require a full overhaul of the existing business processes and workflows, the management is often mistaken to think the change must be done in one huge effort.

Actually, the transition to DevOps can take as many time as the company requires. It can involve one pilot project at a time and your team will be prepared for gradual changes once they come. This helps to set the KPIs, envisage the milestones and track the progress. After all, as the report on the State of DevOps adoption in 2017 shows, there are immense tangible benefits of the transition to DevOps, and 41% of the respondents to Atlassian survey reap these benefits already.

Case studies of adopting DevOps in the financial services industry

IT Svit has completed several projects implementing DevOps for financial industry businesses. We briefly outline them below.

Case 1: Infrastructure setup & optimization for a cryptocurrency exchange

The customer had the infrastructure with DigitalOcean and used Elastic Beanstalk App for the app deployment. The whole process took around 3 hours, and the process of build, testing and staging server setup was manual.

We designed and implemented the software delivery pipelines using Ansible. The app deployment now takes 5 minutes and all the software development workflows are automated.

Case 2: Infrastructure audit, optimization, and CI/CD

One of IT Svit customers had the infrastructure deployed with AWS, but lots of their services were not utilized to the full extent. We have audited the existing systems, optimized the resource allocation and eliminated all services not critical to the project success. This allowed the customer to save around 68% of their OPEX with AWS.

The second part of the task included the infrastructure setup and implementation to support the development and operations of the customer’s app — a cryptocurrency trading SaaS. We suggested splitting the monolith app into microservices in order to enable CI/CD and simplify the monitoring. The app has not been down ever since.

Case 3: Proof of Concept development, security and infrastructure optimization

A customer from France contacted us with an idea of a cryptocurrency exchange with direct conversion of fiat into cryptocurrency. We developed a Proof of Concept for the customer, which allowed him to secure the investment for the next round of development, which he ordered from us.

Now we ensure the security of operations, provide infrastructure maintenance & ongoing support, as well as cloud monitoring using Prometheus & Grafana. We instituted the CI/CD pipelines to support the ongoing product development, and have optimized the infrastructure for a couple more times to ensure the optimal performance and resilience of the production servers.

Final thoughts on DevOps benefits for finances

We hope this long read was informative and interesting and helped you explore the benefits of adopting a DevOps approach to software delivery for financial services. We also hope that we succeeded in dispelling any misconceptions you might have had regarding DevOps practices and their implementation in the real-world financial companies.

The cases described above clearly illustrate IT Svit expertise in delivering DevOps services to businesses of any size in the financial industry. If you are currently looking for a reliable outsourcing team, which will be able to deliver DevOps-as-a-Service and help your company reach success — IT Svit is ready to help!

If you enjoyed this article, please hit the clap button! Also you can check my previous stories:

10 disruptive DevOps trends of 2018_2017 was a great year for DevOps. Continuous and ever wider adoption of Kubernetes, its long-awaited native support in…_hackernoon.com

DevOps Team Roles And Responsibilities_A good DevOps team is a mix of Developers and Ops Engineers who can do each other’s work, isn’t it? Well, it’s as far…_hackernoon.com

Originally published at itsvit.com on September 11, 2018.