The beginners guide to DevOps - Financial Services Edition

Do you find yourself asking What is DevOps (Developer-Operations)? Why should I care? How can DevOps help my business?

These questions have come across my desk quite a bit recently, particularly from customers in FSI, and this guide is aimed at answering the basic DevOps question and how it relates to your industry.

There are a lot of very smart people working in FSI - I happen to think the products that FSI workers deal with on a day to day basis are more complex than quantum physics - but due to regulatory, compliance, and governance pressures FSI isn't the fastest moving industry in terms of technology. Despite that, our FSI customers have realized that to provide their customers with a 'friction-less banking' experience they need to build digital products quicker, faster, and better, otherwise they risk disruption from the more nimble FinTech organisations.

DevOps can assist with lowering barriers of innovation in FSI and it comes down to changing three core components.

People, Process, and Technology.

DevOps at its core is all about Development, and not a lot about Operations. I'm sorry IT guys and girls, but the more you're involved - the slower the process. Pure DevOps allows for much faster levels of innovation, as the creators inside an organisation can create, deploy, test, and iterate at a much faster pace. You don't have to go full DevOps on all your services though - and not even companies like Amazon do. For example important APIs that are built to last decades and deal with critical financial services probably don't need a DevOps model, but a lot of customer facing applications can benefit greatly from improved DevOps processes.

But what about risk, compliance, bugs, and so forth? Enter microservices architectures. Microservices really complements DevOps, and is almost required, because it breaks down your applications into small manageable bite sized chunks. Smaller teams (dubbed 'Pizza Box' teams at Amazon) can manage the entire life cycle of a small component of your application - which directly reduces risk. One developer can't take down your entire system with some dodgy code if it's broken up into hundreds of small services, and developer teams can work much more rapidly if they don't have to go through cumbersome governance layers that large monolithic applications with hundreds of developers working on them require.

Leveraging microservices orchestration platforms like Azure Service Fabric or Kubernetes, you don't even need the cloud to have microservices architectures, although using these platforms in conjunction with the cloud can help in other aspects (such as burst compute capacity for increased regulatory pressures).

So how do you get there?

You need to start looking at your people and break them down into much smaller independent teams that are responsible for the life-cycle of a single service.

New advances in technology such as containerization, event driven server-less compute, and orchestration platforms make microservices manageable at large scale, allowing you to manage hundreds of not thousands of microservices easily.

This then allows you to use smaller teams and smaller isolated services (microservices), which will open you up to new processes. Because the impact of buggy code or rogue actors is greatly reduced, you'll be more open to automated testing, automated CICD pipelines (continuous integration and continuous deployment), and faster times to innovate.

Obviously it's a little more complex than this, and getting from traditional monolithic platforms to a faster and nimble DevOps model takes time and trust, but I see a lot of potential in the FSI industry to adopt these services... On premise or in the cloud.

So what do these technologies mean exactly?

Microservices.

Microservices is an evolution of Service-Oriented Architecture. Service-Orientated Architecture (SOA) is an architecture which requires applications be more aligned to business process as opposed to technology process, and technology decisions should be abstracted away. For example, a business function in banking might be credit risk assessment, therefor an application should be built in alignment with efficiently doing credit risk assessments, as opposed to being constrained by the technology underpinning that application.

SOA started leading developers down the path of smaller independent services that performed a business function as opposed to a technology function, however SOA became insufficient to power really large hyper-scale applications like Amazon.com, Office 365, and Google's platforms. These companies have huge development teams, massive applications, zero downtime requirements, and needed to take SOA to the next level.

Enter microservices.

Microservices are even smaller services that act completely independently of each other, and are typically responsible for one business function. In the case of Amazon.com, they have divided up all their retail offerings into a microservice each, and then other supporting services to handle things like login requests. So for example, one microservice handles their clothing portion of amazon.com, and another might handle their technology portion of amazon.com.

The benefits here are many. Smaller development teams can work on a service without having to worry about stepping on the toes of other developers. Code can be updated easier. Failure of one service won't bring down the entire application (with the use of a circuit breaker). And individual components of the platform can scale independently, meaning it's more cost efficient.

Microservices come at a cost however. Communication between services can be a difficult problem to solve, along with other constraints such as discovery of new services, management of service failure, management of hundreds if not thousands of services and their code base, and other issues. In 2015 Martin Fowler famously recommended that small companies and startups don't leverage microservices as the cost is too high, however things have changed. Advances in technology over the last couple of years have helped solve some of these complex issues...

Containerization.

You've probably heard of container technology such as Docker or Linux containers, and you might be wondering what the fuss is about. Containers in a nutshell are basically application virtualization that decouples the application from the operating system, much like classic virtualization decouples operating systems from hardware. That means an application can easily move between operating systems, datacenters, clouds providers, and so forth.

Containers have really helped solve some of the issues with microservices, as they allow discrete services to run independently of the underlining operating system.

Containers opens up some very interesting possibilities beyond just solving part of the microservices cost. Because containers change the relationship of application-to-virtual machine from 1:1 to Many:1, they allow a much denser cluster of applications per virtual machine, which in many instances can result to cost savings.

As an example if you have 100 virtual machines in your datacenter running one component of an application on each, it's almost guaranteed that most of those virtual machines are running with capacity to spare. The traditional approach is if you need more capacity (compute, storage, etc) then you provision a new server or virtual machine, and doing so you will quickly run out of resources. This problem plagues many companies from smaller organisations to the largest enterprises.

Using containers however allows you to run multiple applications per virtual machine. This means if you have spare capacity on one virtual machine you can run more applications on that virtual machine, and consume that capacity without having to provision a new one. This also applies to cloud services, as traditional autoscale groups on the cloud also only have a 1:1 relationship between virtual machine and application.

Containers themselves don't solve the cost of microservices. Managing hundreds of containers by themselves is a difficult problem still, but fortunately a few big players have released platforms to assist with this.

Container Orchestration.

Enter in platforms that orchestrate the containers; platforms like Kubernetes, Docker Swarm, and Azure Service Fabric. These platforms help run massive numbers of containers and microservices at scale, and the creators of those platforms (Google and Microsoft) have democractized their platforms which help run their clouds... for free!

These platforms manage the life cycle of your container based (or process based) microservices. They handle the problems such as discovery, failure, provisioning, de-provisioning, monitoring, scaling, and so forth.

It's worth noting that these platforms abstract away infrastructure, allowing container based applications to scale across a private datacenter into the cloud, across clouds. Azure Service Fabric for example runs on AWS, the private datacenter, or even Google cloud. Likewise Kubernetes runs on the private datacenter, Azure, and AWS.

Leveraging orchestration technologies means developers can focus more on development, and less on operations, and have platforms that come with a lot of redundancy, resiliency, and scalability out of the box.

Conclusion

Binding all these concepts together allow you to break your application down into manageable chunks and handle a lot of the hard problems of managing these applications for you.

The challenge especially in FSI is you can't completely change all your applications at once, and you shouldn't attempt to do so. The change to a streamlined DevOps (and DevSecOps, another topic) needs to happen over time in small chunks, preferably starting with a new initiative instead of trying to engineer your older applications.

If you want to know more, talk to us about how we can help.

About the author.

Dave Enright is a leading cloud consulting based in Singapore, working for Telstra's Business Technology Services team.

You can contact him in regards to DevOps and/or Microservices: dave.enright@team.telstra.com