Tyk and AWS


#1

Imported Google Group message. Original thread at: https://groups.google.com/forum/#!topic/tyk-community-support/cYK__B_WmXc Import Date: 2016-01-19 21:03:18 +0000.
Sender:Chris Gilligan.
Date:Monday, 15 December 2014 00:32:25 UTC.

Hi,
I was wondering if there was a version of Tyk that is targets towards AWS based services or is there an AMI image i could use on AWS to test with?

The reason i am asking is AWS is a little different than other environments but you do mention being built for the cloud. AWS is the biggest one out there so i was hoping you may support their services. It seems your application needs Redis and MongoDB. Redis is easy on AWS as they provide a HA solution for that but MongoDB would require us to setup our own HA MonoDB environment requiring more instances and costs where as DynamoDB or S3 would be much cheaper option depending on what you are storing in there and means the only boxes we would need to manage would be the boxes we have Tyk on.

Also can you provide a little info on how the HA setup works with hosts coming up and down and sessions been split over the hosts? Will all that be fine due to the MongoDB and Redis DB? It would be great to see some AMI images for this product on the AWS marketplace.

Regards,

Chris


#2

Imported Google Group message.
Sender:Martin Buhr.
Date:Monday, 15 December 2014 09:13:22 UTC.

Hi Chris,

There isn’t currently an AMI for Amazon, we’re looking into getting tyk onto the marketplace and how exactly we would achieve it (there are some hoops to jump through). We are working towards docker integration in the upcoming version, which should make it easier to launch tyk using Docker, and very easy to deploy onto any cloud architecture.

With regards to MongoDB, you can deploy and run tyk without MongoDB, Tyk only requires MongoDB for analytics data collection, the dashboard and centralising API Definitions (e.g. if you are running multiple tyk instances and want to manage them using the dashboard) in the upcoming release we are working towards adding third-party data-sinks for analytics data (for example: CloudWatch), and making this interface easy to extend so further data sinks can be created as part of the open source project.

I should elaborate on this point:
Tyk can store configuration locally or in Mongo, it only loads configurations at start-up or during hot-reload, which means once a configuration is loaded, there are no more active hits to the database except if analytics data is being purged (and this can be handled by a dedicated process if needed).
If deploying without a DB (which most of our users do I believe), you can manage configurations using Puppet or Salt to sync the files from a repo or a NAS share, and then hot-reload them using an API call when the files have synchronised
If using the database and have a license, the dashboard will notify all running Tyk hosts that they should hot reload, these can be spread across multiple machines or on a single machine as multiple processes or both.
Hot reloading is done with zero downtime, any requests currently being processed will complete their middleware chain until they upstream API has responded.
Tyk stores analytics data in Redis for a “purge period”, when this time elapses, data is shovelled across into MongoDB for long term storage where the dashboard can run data pipelines
We have some users that have decided to collect data, but de-activate the purge so they can manually do it into their own BI solutions
As for session splitting and instances going up and down, Tyk runs as a series of nodes, you can have one or you can have many, they have idempotent configurations which are stored locally on the host (if not using MongoDB as a central configuration store) and can be destroyed or activated as needed, all sessions are stored in Redis, so long as your Redis cluster is healthy and active, so will the session data.

With Tyk we took the approach that you should be able to install and run Tyk with minimal external dependencies, and that it should be flexible enough to work with your existing set-up without imposing any usage patterns on you, which is in part why we haven’t put Tyk on Docker yet or pre-baked AMI images - it’s such as small application that requires very little to run, so deploying it as part of a devops solution should be trivial.

MongoDB is primarily used as a data sink (because it has great data-processing capabilities, the way you can run data-pipeline requests makes it trivial to create aggregate data out of vast swathes of raw analytics) to support the dashboard, which means as part of an overall Tyk deployment it’s a non-critical requirement - it doesn’t get hit often, and it is mainly used by the dashboard.

But you are correct in that we have’t provided a simple demo environment, we hope that the docker integration will address this to some extent.

Let me know if you have any other questions.

Cheers,
Martin


#3

Imported Google Group message.
Sender:Chris Gilligan.
Date:Tuesday, 16 December 2014 07:03:40 UTC.

Hi Martin,
Thanks for the great info. To give you some background we are looking to deploy a website onto the cloud in a dev, staging and production. Staging and production will be in a HA setup so would defiantly need at least 2 Tyk instances in each environment. Part of what attracted me to Tyk is the dashboard so as long as it meets our requirements we would be purchasing the license to get access to that.

I am assuming apart from great states the dashboard allows us to configure the instances etc and we would want that config pushed to all instances. Redis cluster is something we will already have for our own internal cache so as long as it will not need a huge amount of redis storage i don’t see that being an issue. Rest based API is also great for us for reload etc but i do worry about keeping the config in sync over multiple machines as on AWS it would need to get the config again each time a machine comes up. It can be done and we will do that for windows but i don’t have a lot of linux experience so would have to leave that to another team member overseas. The analytics is a big thing for us so it does make it seem like we may need MongoDB.

As to using CloudWatch as a datasink that would be interesting if we can get the history and details.

I work at a multinational company so i still need to get my choice of API gateway though the security boards approval and other steps but wanted to make sure i had all the info first as that is not a process to be repeated if it can be avoided.

Regards,

Chris


#4

Imported Google Group message.
Sender:Martin Buhr.
Date:Tuesday, 16 December 2014 08:54:41 UTC.

Hi Chris,

Thanks or the background on it, it does make things clearer.

With regards to a Tyk setup for you, I think it’s perfectly achievable but you will need MongoDB in this case, as it’s the most reliable way of pushing and managing configurations to the various instances as they come up and shut down without any complex file-management and synchronisation.

When Tyk is setup for being database backed it basically has the following bootstrap process:
Load configuration
Check state
Set up DB connection pool
Pull App Definitions that are active from MongoDB
Assign routers and states
Connect to Redis (each API has it’s own connection pool)
Ready
On reload, the router and middleware that handle incoming connections are re-initialised with steps 4-7, while any remaining connections are completed with the old configuration.

The licensed version ships with a tyk-host-manager which handles hot-reloads for you, this is installed on each Tyk node (you may be running multiple processes on a single host, e.g. one per core on different ports), the reload manager will receive a ping when a change is made to a configuration and initiates a reload on each node on it’s managed system.

With regards tot he the MongoDB requirement, for analytics it’s really core, it’s aggregation framework is one of the reasons we picked it as a data store. There are MongoDB AWS AMI’s on the marketplace that would probably suit the load, alternatively a managed third-party cluster such as Compose.io might also be a good place to look for a cost-effective Mongo installation.

Have you tried the dashboard yet? It will manage a single API and 7-days of analytics data without a license :slight_smile: If you do get down the path of software selection, ping me an email and we can set up a demo license for you if necessary.

Let me know if you have any further questions, you can get in touch with me directly at mar…@jive.ly.

Thanks,
Martin