At Financial Engines, we have been working on building our API platform.
Being part of Apigateway Team, our responsibility is to expose our API’s to our
partners and internal applications alike. This will help us to migrate away from
monolithic to distributed microservices based architecture.
Like any other enterprise project, we also have our own set of functional and
non-functional requirements such as low latency, high throughput, security,
reliability, high availability, Opex and Capex costs etc.
Also, one of the primary parameters is that we want a SaaS cloud platform to
avoid Opex costs. After evaluating multiple API Gateways against our own set of
parameters, we chose Apigee Apigateway.
In this post, I would like to go over our implementation journey, our learnings and
things we really liked about Apigee and things which Apigee could improve going forward.
Below is the diagram showing our evaluation matrix and how we selected Apigee.
Update - Apigee got acquired by google and will become very intrinsic to Google Cloud Platform.
What are API Gateways? In distributed systems, API Gateways are typically used to handle
cross cutting concerns such as enforcing authentication,authorization,security,logging.
Below diagram shows very simplistic view of how we are planning to introduce API Gateway into our ecosystem.
After evaluation, next step was to understand how Apigee worked.
In simplest terms, Apigee is layer 7 proxy, it provides us ability to intercept
request and response and execute custom code. You can use default policies and
also create own custom policies such as oauth2, rate limiter etc. You can write
Like any other solution, Apigee brings its own terminology which is fairly easy to
understand. On high level, Apigee has concept of Orgs/environment, proxies, policies.
Apigee request response flow is primarily driven by xml workflow as you can see in below example.
Below diagram shows our deployment and conceptual model showing prod apigee org and
3 environmments which proxied to our respective dev, test, prod environments.
Please note that, I have changed the domain to xyz.com for simplicity and security reasons.
Next step was finalizing how our developers will deploy and test the changes. We used
grunt based deployment workflow where developers were able to directly deploy
to cloud test org and test the changes they intended to do.
Once dev deployment workflow is setup, We were able to stand up the infrastructure
very quickly which consisted of one main core proxy and one oauth proxy for our
authorization needs. For authorization, we propagated signed JWT’s to the backend
services. Using our auth libraries, microservices were able to validate the jwt
and extract the userInfo and apply authorization accordingly.
Let’s go over how Apigee deployment looked like.
In Apigee, we created a main proxy and oauth2 proxy. oAuth2 proxy was responsible for
generating oauth tokens and handling the validation for generated oauth tokens.
One of the strongest features of Apigee which Team really liked was ability to deploy
older versions quickly. This feature helped a lot during development and gave us
good fallback option should we need to rollback our deployment.
Other most important feature which was quite handy many a times was ability to trace
live traffic. We used this feature many times in dev/test to troubleshoot many issues.
Apigee also provides request level UUID which we hooked up with our backend
infrastructure to track request lifecycle. We also enabled detailed logging for
each request response in apigee and redirected the logs to our splunk platform
which helped us correlating apigee logs with our backend microservices logs.
It provided additional insights using splunk custom reports.
Apigee also provides great analytics for the traffic such as request processing
latency, response processing latency, average response time, breakdown by HTTP
status codes, proxy errors and target backend microservices errors.
We also utilized default analytics and reports provided by Apigee where we
were able to breakdown traffic by each client/partner and application which enabled
us to troubleshoot issues much faster.
Overall, we were able to go live within 8 weeks with full fledged observability and
production ready stack. During first year of implementation, we rarely faced any
issue and found Apigee support very helpful whenever we had some interruptions.
We extended the platform later on to expose API’s via our API platform for different
clients such as internal SPA’s, external SPA’s, Partner secure server side apps, Partner
SSO using SAML, OpenIdConnect and also onboarded many backend services.
We learned a lot during the journey and enjoyed the implementation with a wonderful
Team without which whole journey would not have been as exciting as it was!