carloscastilla - Fotolia
Businesses not ready for network implications of cloud native architecture
Composable applications can be built from connecting microservices that run in their own containers. This cloud-first approach requires a new approach to networking
The next iteration for cloud computing, Cloud 2.0, promises to deliver a flexible IT architecture where applications are built out of microservices running in containers, all orchestrated through Kubernetes.
But containerised microservices need full network support, and this presents a massive overhead for DevOps, delegates attending the Cloud Native Computing Forum (CNCF) conference in Copenhagen were warned this week.
In a keynote presentation, Lew Tucker, CTO for cloud computing at Cisco, said: “We are rethinking networking for microservices. Distributed computing is not very easy. It is complex because microservices need to communicate.”
The challenge facing users of container technology is that a container running a microservice has a network IP address, which needs network management. The IP address is used to enable other containers to communicate with it, in order to build applications based on a microservices architecture.
But to support networking, every container needs to provide network security, firewalls, load balancing, messaging queuing and other essential network services. Addressing this overhead is the next phase in the evolution of cloud native computing, according to the CNCF.
Ed Warnicke, distinguished consulting engineer at Cisco Systems, said: “Networking in Kubernetes is growing and something will have to give because you don’t have enough CPU clock cycles. We need a better way of thinking about the network.
“With Cloud 1.0, we forgot that all these things were a cost centre. What you want out of your network is reachability and isolation. You also want serviceability.”
Daniel Berg, distinguished engineer at IBM Cloud, said: “Network components in a cloud-first architecture are fragile. The network is the unsolved problem of cloud, and open source. We need the network to be a first-class citizen of a cloud system. I have hit the network problem – our IP tables went out and it took out production servers.”
In a user panel discussion on the challenges of implementing and deploying a cloud-native architecture, Sarah Wells, technical director for operations and reliability at the Financial Times, warned that when a microservice architecture starts to experience problems, it can quickly fail, which can be far harder to trace than failure in a monolithic system.
“Operating a microservices system is a whole different thing,” she said. “You need to work out how to [manage it] because the kind of failures you get are less predictable. You can easily fill up your InBox with alerts if you carry on with a naive monolithic approach [to monitoring].”
This is a situation that Monzo Bank experienced at the start of January this year. In a post describing the outage, Wayne Tsai, a back-end engineer at Monzo, said it had occurred because of overloading its asynchronous messaging system, NSQ. “We had accidentally stopped message processing of all messages being queued to NSQ,” he said.
When the service was unpaused, the messaging services began to process the huge backlogs and became saturated with messages, said Tsai. “We had distributed millions of messages into our own services – effectively a self-denial-of-service attack – and this was when the problems became more serious. Some customers experienced failures to load the app and a small number of payments began to fail.”
Networking mesh for cloud-first computing
In a bid to simplify networking in a microservices architecture, the CNCF networking community is looking to develop a network mesh of open source shared services, where container-to-container communications can be managed.
Brandon Philips, CTO of CoreOS at Red Hat, said that because a container has an IP address and can provide simple metadata, it is possible to start to create networking rules around it.
IBM’s Berg said the network should be part of the fabric of how developers work with applications, but he added: “We can’t expect all developers to understand complex networking issues.”
A standard approach to connecting and communicating with microservices is needed. Standardisation and uniformity simplifies management. But scaling each microservice individually will be a challenge, warned Tony Lock, distinguished analyst at Freeform Dynamics.
That is why organisations with large-scale microservices systems are building and deploying their architecture in a uniform way. Oliver Beattie, head of engineering at Monzo Bank, said: “Uniformity is very important. It gives us a platform that is easy to manage. If you can centralise something, you can manage it much better.
“RPC [remote procedure call] is an example of this – all our services talk to each other in the same way and there are strong reasons to use RPC, unless there is a weird use-case that doesn’t fit in.”
A number of projects are under way to address the challenge of software-defined networking in microservices. FD.io (Fast data – Input/Output) is a collection of several projects and libraries that aims to support flexible, programmable and composable services that run on a generic hardware platform. Meanwhile, Istio is an open platform to connect, manage and secure microservices.
Swiss auction site Ricardo.ch is one of the companies trialling Isto. Cedric Meury, head of platform engineering at Ricardo.ch, told Computer Weekly: “The downside of microservices is that the contracts between them have to somehow be encoded and if you don’t have the best testers and developers, a contract will break and the front-end will fail. This increases exponentially, the more services you have.”
Meury said every developer has to write client code, server code and web code, along with supporting a host of other networking protocols, and all of this boilerplate code needs to be put into a services mesh.
“You can just deploy a function and drop it into the mesh, which handles all the networking, measuring logging and tracing,” he said. “There is no way around having a service mesh. We are going in this direction with Istio for a couple of our APIs [application programming interfaces].”
Many of the tools being developed to support cloud-native networking are very new, so it will take time for products to mature to a point where organisations can use them in production systems to provide the network mesh for their microservices architectures.
