jively

Apologies - this was an accidental duplicate, how can I delete it?

Tyk.io | Mid-level Go Developer | London, Singapore | remote | Full-time

We’re looking for a Go Developer that can work with our open-source engineering team and cloud edge to deliver the next generation of the Tyk API Management platform.

Interested? Find it more and apply here: https://tyk.io/about/team/mid-go-developer/

Here's what you will be working on:

- The open source API Gateway - Our multi-data-center distributed API platform - The next-get cloud infrastructure of our public SaaS

Tech Stack: Go, more Go, React, with a sprinkling of Python, JS and gRPC

Read more about the role and apply here: https://tyk.io/about/team/mid-go-developer/, or email us directly at talent@tyk.io

You’re staking your IP on the financial health of your company. If you have a promise to push OSS then you also provide motive for sabotage.

It sounds extremely paranoid, I know, but escrow is a much safer option because when you pass that on to the client it forces them to really commit as opposed to not caring if you go bust.

To put it another way: you get a commitment from them in terms of having to pay the fees for escrow, which is more than they would have to do if you made a public promise. That’s a longer term commitment, so you can wrap that into a longer term deal, which in turn can help you stay sustainable for longer.

What caseyf said - this should be covered by software escrow, making an OSS commitment public is dangerous as it can put your IP at risk.

Though software escrow comes with added costs so it’s really down to the individual contract.

Tyk and Kong are similar in terms of what they do, though with a Tyk we bake a lot of key functionality into the core instead of asking the community to build them for us.

We also don’t have the concept of proprietary plugins, so where Kong is “Open Core” (for example if you want to use openID connect you need to buy enterprise, with us it’s just par for the course), we bake everything gateway-related into the open source version and don’t hide the ball. Our “value add” is in our dashboard GUI (proprietary) and multi-cloud/multi-DC server (also proprietary).

Also, in Tyk you can model your api routing as a file, with Kong you need to specify all routes as API calls to the gateway, so backing up/version controlling your APIs is difficult without using a community-provided solution. (Though don’t get me wrong, both Tyk Gateway and Dashboard are entirely API driven, so you can do everything programmatically or declaratively).

Lastly - we have a compatability promise of “no breaking changes within major versions”. It’s harder to do, but makes our users happy :-)

Ah, and in terms of extensibility, we provide middleware and event hooks that can be hooked into with any gRPC compatible language and offer native binary (FFI) Support in Python and Lua, we also have a baked in ECMAScript interpreter which is fast (it’s written in Go), but being an interpreter doesn’t have the expressiveness of some of the other extension options)

In terms of other implementations, in open source there’s not many thst have quite the breadth of functionality we offer.

To be fair though, the other solutions out there (especially coming out of the Go/K8s/CNCF communities are very impressive.

Tyk provides pluggable middleware written in Python, it’s very likely you get something like this going because the plugins grant access to the gateway redis cache so you can store data as well as advanced rewrites that can do some pretty complex routing.

[Caveat emptor: I’m the CEO of Tyk] Tyk is an open source API gateway written in Go, it’s been battle tested in production PCI compliant environments and offers a large selection of security features.

It’s also customisable in other languages other than Lua (Python, JS, and anything gRPC) ;-)

I meant that there are well discussed strategies for handling calls that are RPC-oriented rather than CRUD, not that there are REST libraries that have solved the problem.

Ultimately we find ourselves building 80-90% CRUD operations with edge cases that don’t entirely fit with the straightforward RESTful toolset, and in those situations making a call on how to handle it in code is a topic that has by now been more or less discussed to death and becomes a stylistic choice.

REST isn’t a protocol, there is definitely interpretation at work.

I was using the term “RPC” to cover topics that are outside the scope of CRUD, “do a thing” as opposed to “manipulate a thing”.

My biggest issue with GraphQL is the fact that what essentially used to be a database operation has now become a (coordinated) batch API query. So the operation has been split into microservices, then re-joined using a GraphQL interpretation SPoF, all so that client business logic can be encapsulated as a query string, instead of securing that effort as a specialised API endpoint.

Moving flexibility to the client comes with all the inherent risk of that flexibility being available to (in a browser sense) a risky client.

RPC over REST is a solved problem IMO, arguments about REST RPC semantics become ideological after a while.

True, in general any framework that claims to help build REST APIs can put you in a situation where it forces assumptions on you.

Then the interpretation becomes the pattern, and it becomes a self-perpetuating fallacy.

Correction: if Tyk Cloud has a custom domain (CNAME) setup for you then it can ignore https - it’s not a self-service option though.

The benchmarks for Tyk here seem somewhat off - it doesn’t look like it was set up correctly for production use.

> A better approach is to use a “set-then-get” mindset, relying on atomic operators that implement locks in a very performant fashion, allowing you to quickly increment and check counter values without letting the atomic operations get in the way.

In a highly distributed system you’d probably want to avoid a centralised data store altogether for fast moving data like rate limits. CRDTs and bucket weighting might be a more effective strategy.

The article states that tracking per-node could cause a problem with race conditions but that assumes it’s the counter that’s the problem. If the node cluster is aware of the other nodes and the relative load of the cluster, you can use this value to weight the isolated rate limiter and the only data that needs to be shared can be broadcast between the nodes using a pub/sub mechanism.

If some variance is permitted (+/- a margin either side of the limit) then having the nodes synchronise their “token weight” based on the size of the cluster means that the nodes can then manage the rate limit in-memory without ever needing to track in a data store.

It does trade-off accuracy, but for accuracy you can then revert to the set-then-get centralised counter, the trade-off being performance because of increased round trip time to the day store.

In most rate limit scenarios, at least from what we’ve seen, extreme accuracy isn’t usually that important vs. being able to scale amd rate limit without having to also scale a data layer to handle the counters.

(Full disclosure: I work for Tyk): The free version of Tyk isn't hobbled, we don't withhold functionality from the open source gateway at all (in fact, that's where most of the new tech development goes).

All features are available and usable, even analytics gathering, though not with our dashboard (but that doesn't stop you using ELK or some other time series DB to store and analyse the data - that's why we have Tyk Pump, to remove any dependencies on our paid-for software).

The dashboard for our gateway is indeed closed and we charge for it, however if you are only running one gateway, then it's completely free.

For non-profits, we offer significant discounts, so it's worth getting in touch with us to see what we can do to help you out :-)

Love the simple pricing, though you may want to be even clearer with your plans. I used to run a a cloud based load testing service, it's a tough gig because it's hard to differentiate.

An upheaval in the way we see our role in the universe? Re-invogorate the race to space? I think there's plenty of things that follow "then what?".

Not really, firebase is a database that has a RESTful interface (and events and all kinds of other cool stuff). with this you set up endpoints, point them at cloud functions that may or may not interact with AWS' DynamoDB and your own services to provide functionality but I think you need to worr it all up yourself.

Prediction: Amazon buys a cloud IDE platform.

Hetzner is amazingly cheap, but nowhere near as big. DO is indeed much cheaper. AWS is cheap, but performance varies too. Also, Azure (?)

You can always get in touch with me directly on our community site if you have any questions, we're a friendly bunch :-)

Therein lies the rub - if you are working with AWS' key-value store, and then also their Lambda system, then you don't really develop server side - you develop everything client side (mobile app) and just use the cloud as a dumb logic store.

I shouldn't see why not. Tyk has a pretty small footprint and supports SSL end-to-end so transmission of data is safe. It obfuscates API keys so they can't be pulled if you keystore is compromised and all analytics also use the obfuscated keys so that security is ensured in log data.

However, we'd probably need to do an audit. Worth a check though.

I think AWS is going after the Parse / Heroku market here, the combination of Lambda and this gateway make it more suited for that kind of implementation, they are missing out on the larger features that enterprise needs - the blog post doesn't really go into detail on how SOAP conversion works, and I doubt it's a cakewalk.

It's in legacy API services that places like Mashery and Apigee make all their real money, and I can't see large enterprises shifting their legacy services to EC2. It's quite forward looking. The satire on how EC2 may be deprecated is really not far off from where things are heading.

I always find it quite funny when only single OSS projects are mentioned as alternatives, there's so many more full-featured projects out there: Tyk (https://tyk.io) API Umbrella (http://apiumbrella.io/) and ApiAxle (http://apiaxle.com/) to name some. For more fine grained approaches there's also Vulcan (http://vulcanproxy.com/)

Agreed that it's moving down the value chain, many other open source projects out there doing similar things. There's also Tyk Open Source API Gateway (https://tyk.io) and API Umbrella (http://apiumbrella.io/), and APIAxle, though that's been around for a while now.

Also API market is intended to grow to $660 million in US by 2020 and over a billion worldwide (http://blogs.forrester.com/michael_yamnitsky/15-06-07-the_ap...). So it's definetely not small.

It is? http://downforeveryoneorjustme.com/https://tyk.io

API Managmeent market is quite big, makes sense for Amazon to get on board.

Imagine this: You are BigCorp USA Inc. and have a bunch of internal SOAP-based web services that are 10 years old and cost a fortune to maintain.

You hear someone will pay you to use them, but SOAP sucks. So you could either go and change your APIs (and probably break a bunch of internal processes) OR you could use a gateway to sit in front of them and translate in bound / outbound requests. Now you can charge people for your APIs!

Scenario 2: If you're an indie dev/ startup but dont want to run EC2 infrastructure, Lambda + Gateway = Cloud service, without any heavy lifting, servers and cost effective. It's development lego. Kind of like Parse.

Scenario 3: You have an API for your app, now you wnat third party devs to use it.Your API is not set up for that kind of access (multi-user security, throttling, quotas, analytics etc.) - solution: shove a gateway in front of it.

Hah! Indeed :-)

You could always use an open source gateway like Tyk (https://tyk.io) or API Umbrella (full disclosure: I run Tyk.io, and this news is... disheartening).

Done and updated - thank #TheRealLukeB! :-)

Tyk (self-hosted) offers a dashboard and analytics for free out of the box. :-)

Tyk Cloud was very much built to make the open source and free versions better (and sustainable), so I think there's probably some differences in motivation.

Ultimately we're trying to solve the same problems, which is great, we're seeing more and more projects try to make API management better, just noticed the other day that a new ruby-based app has shown up called API Umbrella (http://apiumbrella.io/)! It's getting busier, which is great news for API developers.