What are known today as the KrakenD Enterprise components will be disclosed in the form of open source repositories in the following weeks, and the action has already started, don't miss it! In this post we will explain the reasons behind this decision that might sound crazy from a business perspective in the first place. Why anyone would publish the paid software increment bits of an existing free software?
A look back…
If you are reading this post chances are that you know this already, in short KrakenD is the fastest API Gateway in the market. It's built in Go programming language while following best practices and designed with performance in mind. But don't take it for granted, we encourage you go run your own benchmarks against your APIs.
KrakenD is developed by Devops Faith. We are a small group of engineers helping companies solve complex problems. Since we're all engineers here, our marketing skills are on a similar level to our skills in butterfly sexing. So we decided to communicate this big change in our product with this only tweet:
Today with this post I will extend a little bit this short announcement.
KrakenD open source, KrakenD free and KrakenD Enterprise. What Da?
When we started this adventure, we made a distinction between the commercial KrakenD products - the downloadable binary versions that have been commercialized only for a few months - and the Open Source KrakenD framework that we use ourselves as the foundations of all products.
We unleashed the KrakenD on Github right before past winter holidays. We always believed in the OS movement and it is no strange that a commercial product is built upon an open source framework maintained by the same organization.
On the other hand the free version was a packaged product (not a framework) with almost all the Enterprise features only that limited in concurrency and number of endpoints you could create. Just a teaser to make you want more and pay for an Enterprise license.
The three products (os, free and enterprise) are meant to run on-premises. It is what makes more sense in terms of performance because what is a better place to put an API Gateway than inside the network your backends (APIs) live?
But now we decided to give this scenario a fresh perspective…
Goodbye to the on-premise licensing model
So yesterday, if you wanted a full-equipped KrakenD in functionalities you needed to apply (pay) for an enterprise license. If you did we generated a license that you would install in your on-premise. All features were unlocked then and the limits raised accordingly.
What we are changing from now on is that no one will need a license to run all the existing features of KrakenD in their own datacenter as we will release them in the open source project.
It might seem a big change for us in terms of business, but we believe that the product will benefit more from a full open source model that does not conflict with the enterprise features.
From an API Gateway perspective, KrakenD functionality will be in its whole open sourced
On the other hand, the Enterprise product will orbit around the centralized management of KrakenD clusters and will also offer a hosted solution (SaaS) for those customers not willing to deploy themselves Krakend.
In addition to that, what we are not changing is that we will continue giving paid support, consultancy and expert development as this model has been working well for us.
So, what is exactly open sourced?
Unlike Netflix we won't be releasing all episodes in the first season. We will progressively release the enterprise components in our KrakenD Github page when they are core, or on its own repository if they are not essential functionality of a pure API Gateway.
A lot of components and middlewares will be going out, and time will bring even more. Here is a preview (non-limited) of functionalities that we will be releasing soon, do not take this sample as an accurate roadmap:
- Rate limit ( published!)
- Circuit breaker ( published!)
- OAuth2 client credentials grant
- Metrics proxy and router
- Security router
- Restrict connections by host
- HTTP Strict Transport Security (HSTS)
- Clickjacking protection
- HTTP Public Key Pinning (HPKP)
- MIME-Sniffing prevention
- Cross-site scripting (XSS) protection
- Cross-origin resource sharing (CORS)
- JSON Web Tokens (JWT) and JSON Object Signing and Encryption (JOSE)
- Custom caching headers
We had crossed thoughts for a long time and we had a lot of internal debate. With this change you might even think we are shooting ourselves in the foot. Maybe. But we are certain of this is better for the community and also for the product and its satellite middlewares as they will grow faster this way.
We will announce via Twitter when we publish new components, but make sure at least to star (thanks!!!) the project. Even better if you also watch it to get the notifications, and super if you decide to fork it and contribute.
Thanks for watching! :)