Summary: We attended a couple of presentations given by Steven Armstrong, principal automation engineer at UK-based online food delivery company Just Eat. Armstrong outlined the company’s 100% public cloud strategy (although network infrastructure is in physical data centres) and discussed the company’s evaluation of a multi-cloud service mesh.
Details: Just Eat’s apps are split between AWS (deemed to have the best storage in S3; Just Eat also uses EC2, Lambda and other AWS database services) and Google Cloud (best for Kubernetes, used by its data team), and its CDN is with Azure. Although the company is large enough to warrant an owned data centre, the decision has been taken to stay all-in on public cloud to avoid the costs and skills associated with building and operating infrastructure. The company is looking at how to be more cloud agnostic and also continually looks at ways to save costs, for example cross-platform billing.
Service mesh: The challenge of multi-cloud is the need to create a network fabric across all clouds with the services sitting underneath, and Just Eat has been investigating a multi-cloud service mesh. The service mesh separates the control plane (which controls updates to the mesh) and the data plane (which is a set of ‘sidecars’ sitting in boxes). The sidecars are layer 7 proxies that can sit alongside a deployed application service. The traditional approach is for every microservice to talk to each other either directly or via a load balancer. In a service mesh, the services talk sidecar to sidecar. The benefit is a single way to visualise and monitor traffic in real time as it moves through the platform, and alert to any issues. It hasn’t yet been deployed into production, but the evaluation has given insight into the many benefits a service mesh could deliver.
Angle: This end user is a good example of the challenges faced by deploying in multi-cloud environments. Organizations are not just backing up and hedging bets. They are trying to use multiple clouds together simultaneously.