Capital Markets Face Learning Curve with Container Tech

Last year, two of its bank clients asked London-based data sharing and workflow automation specialist ipushpull if the vendor could deliver its application in containers.

Ipushpull has always used multiple means of deploying its platform or services; for example, as a self-contained virtual machine or a scripted deployment onto a client machine. But these deployments—which David Jones, CTO and co-founder at ipushpull, describes as an “enormous headache” and “extremely time-consuming”—often have to be customized for each bank’s policies, packages, or whatever version of Unix they are running as standard.

But the request from the banks showed the company that container technology has reached a sufficient level of maturity to be considered in a cautious industry like financial services.

Following an extensive trial in beta, Jones says ipushpull has just moved to a containerized migration approach, with Docker as its container, and Amazon’s Elastic Kubernetes Service (EKS) for orchestration. The container holds the application, while the orchestration service allows different containers to interact with each other, and to scale up and down.

Jones says the firm faced a “steep learning curve” with using EKS. He says in adopting the technology, firms need to re-architect to a certain extent by breaking down the application they plan to add to a container into separate microservices. Jones says these microservices are really the benefit of containers, as users can scale each component up and down individually.

For example, ipushpull has one microservice for handling client requests, and another for logging activities. If the logging activity is not considered that important, it can be assigned fewer containers. “You can have a small number of containers handling your logging, while you have a large number of containers handling client requests,” Jones says.

While developers are attracted to containers due to the technology’s flexibility and faster development times, it also requires a very different approach to working with applications. Vendors who jump straight in the deep end without first learning to swim in a dynamic environment will find the adoption process that much longer and painful, Jones says.

Security within containers is one of the key areas developers need to pay close attention to, particularly in the highly regulated and data-sensitive environments of investment banks and asset managers.

“Containers are not as mature as the virtual machine environments that have been used for a long period of time. Some of the security capabilities present in virtual machine environments are missing,” says Gosia Steinder, an IBM Fellow and a research lead in IBM’s hybrid cloud efforts for the finance sector. Steinder says there is a need to make container platforms as secure as virtual machine platforms. 

Steinder says the key problem is a container’s large “attack surface”, which is the interface between the kernel and the container. The kernel is a core program that is a part of the operating system, and acts as a bridge between the hardware and the rest of the system. “Which essentially means that you cannot run the containers multi-tenant on the same host. It is too easy to break out of the container. At least, that is the perception,” she says.   

‘Designed to Be Ephemeral’

Lucy Kerner, senior principal global cybersecurity evangelist and strategist at Red Hat, says some companies fail to understand container technology because of the completely different way of thinking it requires.

She recalls a client who was using a well-known security tool and complained about it not working with containers. “The security teams did not realize that you are dealing with a dynamic infrastructure. Containers are coming up, they are coming down—they are designed to be ephemeral. They are designed to be re-spun up constantly. You can’t be using these perimeter-based security tools that are tracking IP addresses. That is what they were trying to do; they were like: ‘I can’t keep track of all these IP addresses.’ They are not supposed to,” she says.

Kerner says security issues around containers should be tackled with a multi-pronged approach. “You want to hire [for new roles], but you also want to make sure that you are teaching others in your organization who do not have ‘security’ in their titles about security. And that you are teaching the security teams about these newer technologies.” She says compared with security teams, developers tend to be more familiar with Docker.  

Alongside security, the lack of maturity has also been a hindrance for some. Trading technology vendor TradingScreen began looking at Kubernetes and Docker some six or seven years ago.   

At the time, the technology was not to the level the firm felt comfortable using. “I think back in the day I would be comfortable using it in a social media platform, but I wouldn’t be using it for a trading platform where high availability is absolutely key,” says Chris Kingsbury, CTO at TradingScreen.

He says the documentation was also very poor. “You could never actually find one set of documentation that explains how to use it. We spent probably six months on and off prototyping it for a UAT [user acceptance testing] environment and we never got it to a point where it was stable enough for us to actually deploy,” he says.   

So the company stopped looking into it. Then, earlier this year, it decided to revisit the technology, and is now actively migrating a large part of its stack over to Kubernetes for deployment orchestration, primarily within TradingScreen’s own datacenter.  

Kingsbury says that the technology has gotten a lot simpler and has higher production quality. He says one of the problems with Kubernetes and Docker is they can be limiting in the type of communications that can come in and out of a particular container, and the vendor has struggled to get them to work with its own technology stack.

He says many of these issues have been resolved over the years, but obstructions remain; getting one datacenter to talk to another, for example, is still tricky. “We are going to be running it probably for the next year within our development in UAT environments, and only once we are truly comfortable with it, will it start to enter our production system,” Kingsbury says.   

Banks Slower to Adopt 

The more banks embrace the technology, the more appeal it will have for vendors who offer software applications and services to these banks.  A year ago, ITRS introduced support for containers on its monitoring platform, Geneos. Guy Warren, CEO at ITRS, says high trading volumes are hard to manage on a fixed trading estate. Software placed inside containers can expand elastically to take on any extra workload. Where there are unknown volumes of work, with a need for control over fast deployment, dynamic environments like Kubernetes can fit in well.    

“The uptake by the banks is relatively slow compared to other industries,” Warren says. “They are a bit more constrained over security requirements and controls and audit than a normal eBay, or choose your favorite commercial company, are.”  

Some of the big banks have announced their embrace of containerization. Standard Chartered recently partnered with Amazon Web Services (AWS), and said it was using EKS to “run significant applications and quickly introduce new services.” Goldman Sachs has also invested in the technology, forming a partnership to implement Red Hat’s Open Shift CNV platform.  

Another factor behind the growth of containerization has been banking’s growing appetite for cloud technology, which has made adoption easier.

Jones from ipushpull says cloud services “provide all the tooling for orchestration services, like Kubernetes, they provide all the kinds of deployments, the CI/CD [continuous integration/continuous delivery] platforms that the containers really hook in very well. I think it fits very nicely into bank’s cloud migration projects.” CI and CD together refer to a type of method that allows developers to make more frequent code changes.  

While ipushpull leverages Amazon’s EKS for orchestration of its containers, Jones says ipushpull is agnostic about whichever cloud service a bank is using. “They could be on Amazon, Google, Azure, or they could have their own datacenter. But we just have to write code once and then we can deliver to any of those different environments, that is the big benefit for a vendor,” Jones says. 

Unlike with some other newer technologies, such as blockchain, which is still in a trial phase for many organizations in the capital markets, containers are finding quicker acceptance. 

“Blockchain is an interesting technology without many concrete applications, whereas [with] Docker, developers and infrastructure teams at banks can see the benefit,” Jones says.