There has never been a more essential time to ensure teams work together and deliver features with speed and efficiency. Implementing DevOps practices into your workflows gives your business the structure for constant evolution, cutting costs and optimising efficiency. This ensures you can grow secure in the knowledge that you have the best systems in place to support your development, using automated processes and a personalised strategy to create resilient, future-proof growth. Here are the 4 layers of DevOps for financial institutions.

Infrastructure to Code

It is important to clarify that the definition of ‘DevOps’ deviates from the perhaps more traditional banking definition, that being a union of Development people and Operations people, but rather it is a combination of Technical Development people and Machine Operations people. The machine operators that would’ve usually built the physical computing infrastructure now work on projects together with developers, becoming a single team. Machine operators are therefore able to help the developers understand how to construct and code the infrastructure of their applications for efficiency and longevity. Essentially, recreating the physical processing power infrastructure within code.

Microservices

Microservices are about system architecture. They are a fragment of code that give every function of an application its own ‘container’. The inputs and outputs of each fragment are static. This means we can change anything in the code without it affecting the rest of the system, giving us independently deployable services, this means we won’t need to do a complete system test or full impact analysis every time we want to make a change.

The benefits of microservices can easily be seen on the world’s most popular website: Google.com, the image sitting above the search bar is a Microservice. Consider how often that image changes? Now compare that with how often you’ve seen Google take down their entire system/website to make sure the image is going to work for everybody on the endless variety of devices that visit the website.

Microservices may be small but when they are appropriately constructed in their fragments, interfaced correctly and built out, microservices can make some of the most complex systems in the world. From collateral management entirely done on the web using microservices to trading systems for bonds and equities, microservices are leveraged to help keep your systems running at all times. Microservices reduce the amount of testing that has to be done substantially, and as many of you know, testing often chews up 30% – 50% of your budget on any well-run project.

Build-to-Test

This is a change in mindset. We used to write a spec, have a committee sit on it and then sign it off, put it under change control, give it to developers to code it, then finally to the quality assurance testing team. Now when using a collection of microservices to meet a customer need, we can build-to-test. This means the code can be built inside the testing tool, the advantage to this is the ease at which we can make changes to or test elements of a system, radically changing the pace at which testing models take place. Through this, by having infrastructure-to-code, developing in microservices, and building to test (all of the above), we achieve what is known as CICD (Continuous Integration, Continuous Deployment), and that means we can put changes into production on a regular basis without impacting the client base, even while they are still using the system. So how do we actually code this?

Agile Methodologies

This is where the cultural mind shift occurs. This layer will consist of 3 elements. The 1st is the way in which we conduct our business requirements. Instead of having highly-qualified business analysts sitting down and consulting with users on how things are done, what if now the users can just ‘tell a story’. Perhaps they could say something like “I came in this morning and sat down at my desk and I put my finger on the finger print reader and it gave me a list of things that I have to do today.” That’s an example of a ‘user story’.

For all the technical people reading this: can you imagine what you would be coding if you received that story? Allow me to elaborate, it would go something like this – “I’d need fingerprint recognition, therefore biometrics. Then the application needs to automatically open upon recognition and on the right-hand side the user should see a list of actions that they need to take today.” By building entire pipelines of user stories that meet each specific user’s need, we can describe complex systems in terms that any user can describe.

These then go to squads, the 2nd element, which consists of about 7-12 people. Each squad will receive a number of user stories. What is a squad? A squad has defined roles, it’s made up of a Product Owner, Scrum Master or an Agile Coach and a number of technical and testing roles. In order for these squads to be highly productive they need to be co-operating fully throughout the day. But for those that are offshoring from east to west, or vice-versa, how can your squads be productive when there is up to a 10 and-a-half hour time difference? But if you were to offshore north to south you will be looking at an hour or two in time difference at the most, then you can begin to see highly productive squads who will all be awake at the same time.

Now the 3rd and final element, the squads will be given time boxes, typically 2 to 3 weeks, and they will sit down and create what is called a sprint plan by looking at the number of user stories they have, the size of their squad, how many they can get done within 2 to 3 weeks, and they will plan perhaps the next 3 or 4 time boxes. As they go through the process of developing, testing and putting into production they may need to make adjustments in order to meet that 2 to 3-week period, either by bringing some forward if they’re doing well and ahead of schedule or pushing a couple back to the next sprint if there’s been a delay.

This method enables us to have defined deliverables that can easily be changed. Now, why is that valuable? Ask yourself – how many times have you expected your next-year’s budget to be changed after 3 months, or 6 months, or 9 months? How many times has that happened to you in the past? By using these Agile methods, the ability to chop and change means that you can better control your budgets in a very volatile world, and let’s face it, the world has changed.

According to the RightScale 2019 State of the Cloud Report from Flexera, the two top priorities identified by cloud users were moving more workloads to public cloud and reducing cloud costs. Those two goals are deeply connected: the more aggressively you migrate, the more important cost discipline becomes.

The Scale of the Cloud Cost Problem

Public cloud spending has become a significant line item in enterprise IT budgets. The major providers—Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform—collectively generate tens of billions of dollars in annual revenue from cloud infrastructure services. A large portion of that revenue reflects spend that organisations could reduce or eliminate through better cost management practices.

The Flexera report found that cloud users estimated their wasted cloud spend at roughly 27%, while Flexera’s own measurement placed actual waste closer to 35%. That gap—between what teams think they waste and what they actually waste—is itself a problem. It means most organisations are underinvesting in optimisation relative to the opportunity.

One driver of this waste is the inherent complexity of cloud pricing. Major cloud providers offer hundreds of thousands of individual price points, and monthly bills can contain millions of line items. Pricing changes frequently, new instance types and services launch constantly, and cloud purchasing decisions are increasingly decentralised across teams. All of this makes it difficult for any single team or individual to maintain a clear picture of where money is going.

1. Identify and Eliminate Wasted Cloud Spend

The first step is to find the waste that already exists in your environment. Several patterns account for the majority of unnecessary spend:

• Instances running 24×7 when not needed: Development, test, and staging environments are common culprits. These environments typically do not need to run outside business hours. Implementing automated scheduling to start and stop instances based on working hours—or on demand—can cut costs for these environments significantly without affecting developer productivity.
• Overprovisioned instances: A common pattern is selecting a VM size based on peak anticipated load and never revisiting that choice. Many workloads run well below the capacity of the instance type they were assigned. Identifying instances consistently running below 40% CPU and memory utilisation and rightsizing them to smaller instance types is one of the highest-ROI optimisation activities available.
• Orphaned and unused storage: Unattached storage volumes, old snapshots beyond your retention policy, and unused load balancers or IP addresses accumulate quietly and add up over time. Regular audits of storage resources—and automated cleanup policies—can eliminate this category of waste entirely.
• Idle resources: Instances that are running but serving no traffic or processing no work (load balancers with no targets, databases with no connections) should be candidates for termination or consolidation.

2. Take Advantage of Provider Discount Programs

All three major cloud providers offer significant discounts in exchange for committing to a level of usage over a period of time. The naming and mechanics differ by provider, but the principle is consistent:

• AWS Reserved Instances and Savings Plans offer discounts compared to on-demand pricing in exchange for a one- or three-year commitment to a defined amount of compute usage.
• Azure Reserved VM Instances provide similar discounts on Azure virtual machines for one- or three-year terms.
• Google Cloud Committed Use Discounts offer reduced rates on Compute Engine resources in exchange for usage commitments.

The challenge with commitment-based discounts is accurately forecasting baseline usage. Committing to too much capacity results in unused reservations; committing to too little leaves savings on the table. The best practice is to analyse your stable, predictable baseline workloads over a meaningful time period before making commitments, and to use on-demand or spot/preemptible pricing for variable or burst workloads.

Spot instances (AWS), Preemptible VMs (Google Cloud), and Azure Spot VMs offer further discounts—sometimes 70–90% off on-demand pricing—for fault-tolerant, interruptible workloads such as batch processing, CI/CD pipelines, and machine learning training jobs.

3. Rightsize Your Instances Continuously

Rightsizing is distinct from eliminating idle instances—it focuses on instances that are active and serving a purpose but are using a larger (and more expensive) instance type than the workload actually requires. Because cloud workloads and usage patterns change over time, rightsizing is not a one-time exercise.

Effective rightsizing requires:

• Collecting CPU, memory, network I/O, and disk I/O metrics over a representative time window (typically 30 days or more).
• Identifying instances where observed utilisation is consistently well below the capacity of the current instance type.
• Testing on a smaller instance type in a non-production environment before making changes to production workloads.
• Re-evaluating instance sizing after significant application changes or traffic pattern shifts.

Cloud provider native tools (AWS Compute Optimizer, Azure Advisor, Google Cloud Recommender) can surface rightsizing recommendations automatically. Third-party cloud cost management platforms offer similar capabilities across multiple providers in a single interface.

4. Automate Cloud Cost Governance Policies

One of the defining characteristics of cloud infrastructure is the speed at which resources can be provisioned. That agility is valuable, but it also means that costs can escalate rapidly if there are no guardrails in place. Teams spin up resources for experiments, and those resources are never cleaned up. Developers choose large instance types for convenience and never revisit the decision. Without systematic governance, waste accumulates faster than any manual review process can catch it.

Automated cost governance policies address this problem by continuously monitoring the environment and taking action—or raising alerts—when predefined conditions are met. Useful automation patterns include:

• Scheduled start/stop policies for development and test environments, triggered by time of day or day of week.
• Idle resource detection that identifies instances with low utilisation over a defined period and either terminates them automatically or flags them for human review.
• Tagging enforcement that prevents resources from being created without required cost allocation tags, enabling accurate attribution of spend to teams, projects, or cost centres.
• Budget alerts that notify teams or trigger automated responses when spending approaches or exceeds defined thresholds.
• Reserved Instance utilisation monitoring to ensure that purchased commitments are being fully used.

The key insight is that cloud cost optimisation is not a project with a finish line—it is an ongoing operational discipline. Automated policies allow organisations to maintain that discipline continuously without requiring constant manual effort.

Cloud Cost Optimisation Delivers Immediate and Compounding Returns

Unlike capital expenditure on physical infrastructure, cloud costs respond to changes in real time. When you stop an instance, the billing stops. When you downsize a VM, the savings begin immediately in the next billing cycle. This means that the return on investment from optimisation work is nearly instantaneous.

Organisations that build continuous, automated cost management into their cloud operating model—rather than treating it as a quarterly exercise—consistently achieve lower unit costs as their usage scales. The combination of eliminating waste, rightsizing resources, leveraging commitment-based discounts, and automating governance creates a compounding effect: each layer of optimisation makes the next layer more effective.

The underlying goal is not simply to spend less on cloud—it is to get more business value per dollar of cloud spend. Organisations that achieve this can reinvest the savings into further innovation while continuing to scale their cloud usage confidently.

We call it DevOps but much of the time there’s a lot more discussion about the needs and concerns of developers than there is about other groups.

There’s a focus on improved and less isolated developer workflows. There are many discussions around collaboration, continuous integration and delivery, issue tracking, source code control, code review, IDEs, and xPaaS – and all the tools that enable those things. Changes in developer practices may come up – such as developers taking ownership of code and pulling pager duty.

We also talk about culture a great deal in the context of developers and DevOps. About touchy-feely topics like empathy, trust, learning, cooperation, and responsibility. It can all be a bit kumbaya.

What about the Ops in DevOps? Or, really, about the other constituencies who should be part of the DevOps process, workflow, and even culture? Indeed, DevSecOps is gaining some traction as a term. DevOps purists may chafe at “DevSecOps” given that security and other important practices are supposed to already be an integral part of routine DevOps workflows. But the reality is that security often gets more lip service than thoughtful and systematic integration.

But what’s really going on here is that we need to get away from thinking about Ops-as-usual (or Security-as-usual) in the DevOps context at all. This is really what Adrian Cockcroft was getting at with the NoOps term; he didn’t coin it but his post about NoOps while he was at Netflix kicked off something of an online kerfuffle. Netflix is something of a special case because they are so all-in on Amazon Web Services, but Adrian was getting at something that’s more broadly applicable. Namely that, in evolved or mature DevOps, a lot of what Ops does is put core services in place and get out of the way.

Ironically, this runs somewhat counter to the initial image of breaking down the wall between Dev and Ops. Yes, DevOps does involve greater transparency, collaboration, and so forth to break down siloed behaviors but there’s perhaps an even stronger element of putting infrastructure, processes, and tools in place so that Devs doesn’t need to interact with Ops as much while being (even more) effective. One of the analogies I like to use is that I don’t want to streamline my interactions with a bank teller. For routine and even not so routine transactions, I just want to use an ATM or even my smartphone.

It’s up to Ops to build and operate the infrastructure supporting those streamlined transactions. Provide core services through a modern container platform. Enable effective automated developer workflows. Mitigate risk and automate security. But largely stay behind the scenes. Of course, you still want to have good communication flows between developers and operations teams; you just want to make those communications unnecessary much of the time.

(At the same time, it’s important for Dev and Ops teams to understand how they can mutually benefit by using appropriate container management and other toolchains. There’s still too much of a tendency by both groups to think of something as an “ops tool” or a “dev tool.” But that’s a topic for another day.)

Modern container platform

A DevOps approach can be applied just about anywhere. But optimizing the process and optimizing cloud-native applications is best done on a modern platform. Take it as read that most IT is going to be brownfield and DevOps may even be a good bridge between existing systems, applications, and development processes and new ones. But here I’m focusing on what’s optimized for new apps and new approaches.

You need scale-out architectures to meet highly elastic service requirements. Application designs with significant scale-up components simply aren’t able to accommodate shifting capacity needs.

Everything is software-defined because software functions, such as network function virtualization and software-defined storage, are much more flexible than when the same functions are embedded in hardware.

The focus is on applications composed of loosely-coupled services because large monolithic applications can be fragile and can’t be updated quickly.

A modern container platform enables lightweight iterative software development and deployment in part because modern applications are often short-lived and require frequent refreshes and replacements.

As I wrote about in The State of Platform-as-a-Service 2016, a PaaS like Red Hat’s OpenShift has evolved to be this modern container platform, embracing and integrating docker-format containers, kubernetes for orchestration and using Red Hat CloudForms (based on the ManageIQ upstream project) for open source hybrid cloud management.

Automated developer workflows

When thinking about the toolchain associated with DevOps, a good place to start is the automation of the continuous integration/continuous delivery (CICD) pipeline. The end goal is to make automation pervasive and consistent using a common language across both classic and cloud-native IT. For example, Ansible allows configurations to be expressed as “playbooks” in a data format that can be read by both humans and machines. This makes them easy to audit with other programs, and easy for nondevelopers to read and understand.

A typical automated workflow begins with operations provisioning a containerized development environment, whether a PaaS or more customized environment. This provides an example of how a mature DevOps process separates operations and developer concerns; by providing developers with a dynamic self-service environment, operations can focus on deploying and running stable, scalable infrastructure while developers focus on writing code.

Automation then ensures that the application can be repeatedly deployed. Many different types of tools are integrated into the DevOps workflow at this point. For example:

• Code repositories, like Git
• Container development tools to convert code in a repository into a portable containerized image that includes any required dependencies
• Vagrant for creating and configuring lightweight, reproducible, and portable development environments¥IDEs like Eclipse
• CICD software like Jenkins

Mature DevOps systems may even push the code directly to production once it has passed automated testing. But this isn’t about removing Ops from its role of ensuring stable and robust production systems. Rather, it’s about automating the processes to ensure that deployed code meets set criteria without ops needing to be directly involved with each deployment.

Mitigate risk and automate security

Ops is also ultimately chartered with protecting the business. This doesn’t mean eliminating all risk – which can’t be done. But it does mean mitigating risk which is accomplished in part by managing the software supply chain and by automating away sources of manual error.

That’s not to say that security is purely an ops concern – hence the aforementioned DevSecOps term. Creating a mindset in which everyone is responsible for security is key as is the practice of building security into development processes. Security must change from a defensive to an offensive posture that is both automated and constant.

Among the practices to be followed in such a proactive environment are:

• Components built from source code using a secure, stable, reproducible build environment
• Careful selection, configuration, and security tracking of packages
• Automated analysis and enforcement of security practices
• Active participation in upstream and community involvement
• Thoroughly validated vulnerability management process

I think this quote from Gartner captures the required dynamic well: “Our goal as information security architects must be to automatically incorporate security controls without manual configuration throughout this cycle in a way that is as transparent as possible to DevOps teams and doesn’t impede DevOps agility, but fulfills our legal and regulatory compliance requirements as well as manages risk.”