Super helpful, thanks. What I mean is something akin to a single-node daemon with network capabilities. Something as basic as a memcached or redis type of interface to start.
A friend with specific knowledge about these suits just informed me that these lawsuits are in fact incredibly common. Many large companies have multiple open audits with the feds at any given time over alleged discriminatory practices - in fact so many of them occur that there is a cap set for how many of them can be open at any given time. This is less political or specific than it appears at face value.
Because settlement happens after a lawsuit is brought? Settlement is a means of reaching agreement before a trial, and is encouraged by the court as to save the court resouces, if parties can work it out amongst themselves
There is such a point where money would exchange hands before a formal suit between two private actors. For instance, I might want to settle with you quickly and privately to avoid having to admit what I did.
The government, on the other hand, wants the publicity of having filed the suit to deter other companies from doing the same thing. I don't believe they frequently settle before filing a formal suit.
> Is there a point at which money would exchange hands before a formal suit is filed?
For a purely monetary resolution to avoid a lawsuit, yes, but in regulatory cases rather than disputes between private parties where such an outcome is often preferred to a lawsuit occurring, the government will often not be interested in such an outcome, and will instead prefer a consent decree with behavioral restrictions that have strong legal consequences. These have to have an actual active case, as they are are court orders to which both parties stipulate, not private agreements. (“Settlement” can cover either type of resolution.)
There are literally 1902 results for "discriminating" on the DOJ's press release search page, and they only go back as far as 2009. That's also for the ones they chose to publicize. I appreciate that you think this is unnecessary - I do too - but the facts don't bear in your favor.
The word "discrimination" also appears on this page 22 times: https://www.dol.gov/newsroom/releases/ofccp . This is only a precisely targeted case if we ignore all other cases like it, of which there are many.
Conversely, there is the XY fallacy: when one [frequently condescendingly] assumes they know better than the person asking, errantly classifies it as an XY problem, and fails to answer the original question.
Yes. Sometimes X is a hairy problem and perhaps well beyond the scope of what anyone cares about, and Y is a well thought out distillation of a sub-problem.
One of the problems I have with stackoverflow is crafting a question so that only those who have the potential to answer the question will answer it. Unfortunately there are always the folks who want to be first to answer the question and don't understand the fullness of the question and proceed to give a quick, poorly thought out solution. This then keeps others from chiming in.
For example, in one question I was asking about JS array performance and was using bubble sort as just a way to exercise arrays. Immediately I get folks mocking me for using bubble sort -- they completely missed the point of the question.
False positives on xyproblem appear to be much more rare and much less harmful than true positives.
At the end of the day a good question provides both context and an indication of things that the asker has tried/learned so far. The person being asked is a person, not an answerbot.
Tyk offers a more “batteries included” approach to Kong, and so doesn’t rely on external plugin authors to extend the ecosystem. 100% of our dev team are constantly working on our open source components and we like to keep it that way.
Because of that, Tyk isn’t “open core” like Kong is, there’s no lock-in or levers to get you to buy our value-adds like our Management Dashboard GUI or our Multi-Data-Center clustering add-on - you should be able to do all API Management without having to pay us a penny.
A simple example is OpenID connect support, this is a Kong enterprise plugin, with Tyk that comes as part of the normal gateway.
In terms of performance Tyk and Kong are pretty close now (Tyk pre 2.6 was slower) but we believe we now have parity, especially when switching on things like analytics, auth and rate limiting.
Tyk works very well in k8s though we don’t have a helm chart yet (coming soon).
You can also deploy Tyk as pure SaaS (fully managed), hybrid cloud (we handle back-end and control plane, you install gateways local to services) and full on-prem (install anywhere: K8s, AWS, GCP, Azure - even on Arm servers). We’re unique in that regard.
Tyk has always been separated into control-plane and operations-level components (our gatewaybis very small), so we don’t see that as something new to crow about. If you use our Dashboard, it moves the configuration and data layer out of the gateways and moves it centrally. If you use our MDCB system (enterprise) you can extend that capability across clusters in different clouds to get really targeted, distributed API governance.
There’s a bunch of other things that are different too, but they are more functional.
> you should be able to do all API Management without having to pay us a penny.
I contacted Kong sales once about OpenID connect support, they basically dismissed us as too small. Needless to say we took Kong out of our stack and won't consider it again.
That's unfortunate, there is a good open source one that I have used and works well. The enterprise one is definitely more verbose but the open source one works well!
Kong has an OpenID Connect plugin that comes with Enterprise, but there are at least three OpenID Connect plugins made by the community, one of them is from Nokia.
I work for Kong and I am an author of that enterprise OpenID Connect plugin. Maybe that is a biggest exception to me, as otherwise I'd say that almost all of my code and related goes directly to OSS.
For the interested, that Nokia Open ID Connect plugin is here [0]. I had to hack around with it a bit to get some extra functionality and support ADFS [1].
That sky background is a 3MB 1080p video file. Very unnecessary and removing it will fix the problem. Also please remove the scrolling interference, it just makes it hard to continue through the site at my pace.
I've used both, Kong is more "pluggable" and easier to extend in my experience. Also, the ecosystem and community around Kong is much stronger than Tyk's which is amazing.
I'd argue Tyk is easier to extend Tyk, as they include many plugins already baked-into their OS gateway. If you want to extend Kong with some custom plugins I think Lua is your only option. With Tyk you can use pretty much any programming language to write your middleware. Gets my vote
Kong is arguably more popular than Tyk (and other similar gateways) when it comes to adoption (55M+ downloads and more than 70,000 instances of Kong running per day across the world), and faster when it comes to performance. BBVA - a large banking group - wrote this technical blog post a while ago comparing Kong's and Tyk performance: https://www.bbva.com/en/api-gateways-kong-vs-tyk/\
Kong OSS is 100% open source, not limited to non-commercial use.
Kong is basically a programmable runtime that can be extended with Plugins [1]. There are more than 500+ plugins that are available on GitHub that we are (slowly) adding to the official Hub, among over 5000+ contributions. You can talk to the community at https://discuss.konghq.com/
Kong is also lightweight with a lower footprint, which is required to support both traditional API gateway use cases and modern microservices environments (Kubernetes sidecar, for example). Because of that, our users are basically using one runtime for both N-S traffic (traditional API Gateway usage) and E-W traffic within a microservice oriented architecture. You can easily separate data and control planes to grow to thousands of Kong nodes running in a system.
There are users/customers running 1M+ TPS on top of distributed Kong clusters spanning across different platforms (containers, multi-cloud, even bare metal) with less than < 1ms processing latency per request. One of the reasons for this is that with Kong you can include/exclude plugins that you don't use instead of having a heavier all-in-one runtime like many gateways do.
As a result to Kong's adoption, the business is also growing very rapidly which will allow us to better deliver OSS features moving forward :) [2]
