MiQ and Tyk
Programmatic marketing agency MiQ is using Tyk to provide a central API management platform for developers as part of a well-connected and monitored API ecosystem.
Who is MiQ?
MiQ is a leading programmatic media partner for brands and agencies. Headquartered in London, MiQ has offices across North America, Europe and Asia Pacific. It works with the world’s leading brands and media agencies such as Marriott, Dell, Mercedes, Microsoft, GroupM, Dentsu Aegis and IPG. Named fourth in The Sunday Times International Track 200 for 2019, the Fastest Growing Tech Company of the Year at the 2017 Stevie Awards and awarded Most Effective Use of Data at The Drum’s Digital Trading Awards USA 2017, MiQ operates globally from 18 offices located in North America, Europe and APAC.
Why did MiQ need an API gateway?
Before the introduction of an API Gateway, developers at MiQ used to have their own implementations of API monitoring and alerting, which would need to be changed whenever a new metric or alert was needed. When someone in product management asked how a particular API was used, or whether its usage increased, or what the error rate was, it took time for the teams to be able to provide the answers.
Different teams had their own logic for handling authentication and authorisation, including who had access to endpoints and what type of access they had. Every team was running their own service in a different way, building their own dashboards, with their own management.
“It felt like the situation, where we didn’t have a central way of managing our APIs, was not sustainable in the long term,” says MiQ’s Senior Engineering Manager, Rohit Srivastava. “If we didn’t start to centralise these things we wouldn’t know how many solutions around API management were being developed in silo. We needed a centralised framework and a centralised team to take care of all of these things.”
At the same time MiQ migrated to a complete microservices-based architecture, with support for both API and event-driven communications. “As our teams completely adopted this architecture, we needed an ability to monitor and manage the API calls and usage centrally. Hence we started to look for a managed system,” Rohit adds.
Why Tyk?
MiQ explored and ran POC’s on a number of API management solutions along with service mesh solutions. After a full review of the company’s requirements, Tyk was chosen as it offered all the functionality that was needed and provided local customer support, all in a more cost efficient manner.
MiQ started running Tyk to support all of its platform services APIs, using Tyk’s API property to start with and then Tyk PUMP to provide the metrics to give the central platform team greater insight into the services they were supporting. For example, with Choreography, MiQ’s proprietary workflow orchestration service, “users can create ETL workflows to communicate among multiple microservices, with an endpoint to create a workflow, pause it, resume it and schedule it. We wanted to track each and every endpoint,” says MiQ’s Technical Lead, Akash Srivastava. “We also wanted to track which team was calling the endpoint and by how much.”
According to Akash: “During our exploration Tyk was the best choice which offered a balance in terms of our requirements and investment.”
How is Tyk working with MiQ?
“It is a central kind of system for us sitting as an entry point for any kind of API,” says Rohit. “We would never expose all our APIs externally, directly. That’s why any API going externally has to go through Tyk.”
MiQ has around 30 APIs (both internal and external), with monthly traffic of around one million calls/requests and a peak rate of around 50 requests per second. With more than 65 developers and upwards of 700 registered users for the end product, both the developer experience and security were key priorities.
The implementation was “fairly easy and took less than a week,” according to Rohit. He explains:
“The Tyk setup was pretty straightforward and it kind of just works out-of-the-box. We had every component packaged in helm charts, which made installation as simple as running a few commands. Tyk documentation helped us really well here as production guidelines were available well in advance, like capping MongoDB for our analytics database, which makes sure everything is in check.”
One major use case for Tyk is key rotation where API keys created with an expiry date of three months are now rotated. “When we see this key is going to expire in the next, say twenty days, we send an email to the user with a newly created key so that they can rotate this key and if they still don’t change it we’ll delete the older key. This is very important in terms of security,” continues Akash.
The ability to track metrics has been important to MiQ, enabling it to monitor, report and act on real-time data. It’s Observability Dashboard has been designed to show what is happening on each instance level for any service, including service uptime, the total number of calls, API latency and the percentage of APIs that have resulted in an error – and setting alerts when thresholds are exceeded or spikes are identified.
How is Tyk benefitting from MiQ?
The benefits can be understood by the nature of the relationship between Tyk and MiQ. It is more of a partnership than a client and supplier relationship, and this has helped both teams build better products. MiQ has:
Contributed to Tyk’s open source helm charts for Kubernetes deployments, which has helped both teams manage deployments better.
Recommended product enhancements and new features via the support portal, which has made Tyk more feature-rich, e.g. gRPC backend support and support for SSE and webSocket.
Tyk’s architecture has allowed MiQ to easily extend use cases through plugins and APIs and the MiQ team has asked for these features to be incorporated into Tyk’s codebase.
There are other features that are in the pipeline like auto key renewal and advanced tracking in the PUMP, which MiQ will be sending to Tyk for further review and incorporation in the codebase.
How is MiQ benefitting from using Tyk?
“One major advantage was to streamline the security implementation for our microservices,” reports Rohit. “Since all the calls go through Tyk we have service communications easily handled by API keys.”
This has created a superior developer experience. Developers now only have to focus on their service. Everything else happens via Tyk, like authentication, authorisation, API access, caching and so forth.
The flexibility that Tyk provides, as well as the ability to seamlessly integrate with MiQ’s monitoring stack (based on Prometheus and Grafana), has been very beneficial.
Rohit continues: “Everything just works without any issue. The dashboard and portal are very helpful in integrating with older services or on-boarding a new service. The Tyk PUMP has helped us a lot in customising the metrics we capture. This has become a standard for developers while debugging issues.”
Endpoint tracking is helping developers monitor how their APIs are performing in order to assess what they can improve upon. The log browser has also proven useful for recording and referencing one-off issues, with the MiQ team able to check requests and resolutions.
“The benefits for me are monitoring and ease of customisation, caching and running natively on Kubernetes,” Rohit adds.
“We have our monthly all-hands and the third slide is always Tyk. This slide presents our API Gateway, in terms of failure rate, success rate, latency, top use cases and how many error calls there are.”
“I still remember our tech leadership team asking last month why it was 99.9 and it now seems to be 99.65. What are the reasons for this? It’s very easy for the development team to click on the API Gateway and show them what the reasons are and why these things happen. This is the day-to-day impact. Previously we could not answer the question quickly, if at all. Tyk has enabled us to answer questions like this in two or three minutes.”
What does the future hold for MiQ? As Rohit explains, “MiQ will continue to build new and modern capabilities and at the same time sustain what’s already in place. That’s the focus for us. Sustain, at scale.
From when we chose Tyk to now the number of microservices within MIQ’s ecosystem has tripled, this would only grow further.
With Tyk in place we project significant time savings as developers would not need to spend much time on implementing features like rate-limiting, throttling, circuit breaker, cache, etc as these are provided out of the box as a setting in Tyk.
When we deployed the API Gateway it was only REST. It was only HTTP calls that we were expecting. We have started conversations around gRPC to integrate our highly scalable messaging solution based on Kafka.”
Tyk has been working well for MiQ. “It’s been relatively easy for us to customise it our own way,” says Rohit. “I feel there is far too much friction when it comes to raising a pull-request and merging it with open source. I typically work with seven other providers and I know how painful it is to merge a pull-request. I think Tyk is a first class citizen for us there.”
What lies ahead for MiQ and Tyk?
In future the MiQ team wants to work even more closely with Tyk to make sure that they are adopting new features released the right way and, with increasing use of microservices, they are exploring how a service mesh offering from Tyk would fit into the MiQ ecosystem.
As this collaboration grows further and the Tyk codebase becomes more familiar to the MiQ team, more contributions to the codebase can be made more easily, instead of building extensions to support use cases.
And finally, the quick-fire round!
If Tyk was a car, what would it be?
A Tesla – it’s modern and requires less maintenance.
Would you rather fight 100 duck-sized horses or one horse-sized duck?
One horse-sized duck.
