A blog on open source by Slobodanka Vlaskovic, Senior Consultant, Architecture & Integration, Devoteam
On Monday 1st October, I had the privilege of attending an open source meetup called Istio London: our fourth production is ready at the offices of Capital One near Old Street, the heart of London’s tech start-ups.
Given how well the event was received, I want to share some thoughts in order to inspire more involvement from colleagues in future meetups.
As a newcomer to this occasion, along with many open source enthusiasts, Kubernetes users and supporters, my awareness was raised about the need to keep one’s knowledge up-to-date in this ever-changing technical world.
This blog does not delve deep into an Istio service mesh implementation, but rather it aims to act as a trigger for anyone searching for new challenges while seeking to create a stronger IT ecosystem.
Istio is an important open source service mesh project created by Google, IBM, Lyft, Red Hat and many other players in the open source community.
Incidentally, the name Istio means sail in Greek. Many of the complementary terms of the open source ecosystem have a similar derivation. For example, Kubernetes is Greek for helmsman.
Istio addresses the challenges developers and operators face as monolithic applications transition towards a distributed microservice architecture. To see how, it helps to take a more detailed look at Istio’s service mesh.
The term service mesh is used to describe the network of microservices that make up such applications and the interactions between them. As a service mesh grows in size and complexity, it can become harder to understand and manage.
Istio makes it easier for organisations to embrace a number of industry trends, such as containers, microservices and serverless computing by the way it handles the routing, load balancing, flow control and security needs of microservices.
A service mesh also often has more complex operational requirements, like A/B testing, canary releases, rate limiting, access control, and end-to-end authentication. Read more about Istio.
What I love about Istio is the idea of centralised operations sitting within a decentralised architecture.
In this age of an API-first approach and microservices-based design (both terms refer to building client applications for mobile devices), adding control is the biggest challenge a development team will experience in enterprise projects.
Istio is an open source project that is itself built upon open source components (such as envoy). The industry at large has come together to rally around the service mesh concept, and vendors have attempted to integrate with Istio in various means such as:
Red Hat: OpenShift Service Mesh
Google: Apigee Adapter for Istio
Pivotal: and Istio
Advancing the ecosystem for microservices in the enterprise through global use of Istio to increase reliability and availability, which results in the highest level of customer experience, sounds perfect indeed and is now possible. Using Istio globally makes teams cross-functional and technology-agnostic.
Amazing too is the fact of scaling a product community along with both customer and user feedback worldwide for fast growth and thus higher quality.
Here is a sketch in chalk of a high-level architecture that helped us (me, at least) visualise what the presenter was talking about. 
For anyone wondering what an Istio meetup looks and sounds like and would like to attend future get-togethers, here’s a flavour of the talks that were delivered:
The opening talk of the evening, Observability tools and patterns with Istio by Nick Joyce of Realkinetic, examined the challenges faced by microservices on an application when faced with a production issue and demonstrated the value of Istio’s telemetry as well as standard features such as circuit breakers, health checks, retries and rate limiting.
The next talk, Service Mesh Network Security by Andrew Martin of Control Plane, discussed how Istio tackles the complexities of microservice security through a service mesh and a unified identity, all with zero application changes.
The final talk of the evening, Multi-cluster routing: a multi-mesh approach by Matt Turner of Tetrate, demonstrated what he believes to be the correct approach to resolving the problem of cross-cluster / VPC / data centre connectivity through the use of separate service meshes, with their own blast radii, to send traffic between each other as and when necessary.
“The trouble is, you think you have time.” Buddha
The richness of the evening didn’t leave much time for Q&A, at least for those of us who didn’t head straight over the road for another craft beer! Therefore, I would kindly ask you Apigee and/or 3Scale experts for your opinion on these points:
- With both Istio and any API management platforms applying the highest levels of security even to developers who need to work on both of them, why should developers have to negotiate security access separately for each? Couldn’t security access on one side be made redundant in the case where, for instance, Google’s Apigee Edge is running on top of the Istio’s component named Mixer?
- I would also like to compare 3Scale’s API gateway, APIcast, with natively extending Istio using the 3scale Istio Adapter. Does anyone have hands-on experience of such a scenario?
If you have any thoughts and experience, let’s discuss!
For those who would like to read more (and contribute), please visit: https://istio.io/ and https://twitter.com/IstioLondon. Istio is on reddit, too.
I look forward to your feedback.
Thanks to our friends at @IstioLondon for having us for a specially crafted event at @CapitalOneUK in London.
#ISTIO is the next big thing! Istio meetups take place in the evenings from 6-9pm and attract around 150 people. Who said Mondays can’t be awesome?!
About me: Introduced as an integration specialist – head in the clouds daydreaming about APIs and microservices.
Istio London: (our fourth) production (is) ready.
