The past month of work on Kernl has seen a lot of great infrastructure improvements as well as a few customer facing features that I’m pretty excited about.
Customer Facing Features
- Direct Uploads to AWS S3 – When Kernl was originally created all file uploads were stored directly on Kernl’s servers. As we grew, this became an unsustainable solution, so the process changed to just use Kernl’s servers as temporary holding space before putting the file on S3. This month we made this process even better by having files upload directly to S3. For you, this means faster uploads and less time waiting to get updates out to your customers.
- Expiring Purchase Codes – You can now create purchase codes that expire on a specific date. This allows you to sell your updates over time, instead of having to give them away for free for the life of the plugin or theme.
- Max Download Purchase Code Flag – You can configure a purchase code to only allow a certain number of update downloads. This will help resolve any issues with customers sharing purchase codes amongst themselves or across multiple installations.
- JS Cache Busting – As customer facing features get rolled out Kernl automatically busts the client-side javascript cache for https://kernl.us. This should help prevent confusion and remove the need for any sort of “hard refresh” when new features are released.
- plugin_update_check.php Bug Fixes – There was an edge-case bug where some code in this file would collide with an old version of WP-Updates plugin update check file. This happens when a customer has your plugin and also has a really old version of somebody else’s plugin installed. This update takes care of that collision permanently.
- Client-side JS Errors – A few minor miscellaneous bug fixes were performed on the front-end of Kernl.
Infrastructure
- MongoDB – The month started off with Kernl’s database moving to it’s own server. This was a temporary step that aimed to make the move to a highly available setup easier.
- Mongo Replica Sets – After the first MongoDB move, the next step was to make the setup highly available. Kernl now has 3 Mongo databases (1 master + 2 replicas). In the event that the master database goes down, Kernl automatically fails over to one of the replicas with no downtime.
- Memcache – Memcache was moved to it’s own server to make it easier to increase the number of items that Kernl caches over time. This piece of the setup doesn’t need to be highly available. If for some reason it goes down, Kernl will continue to operate fine.
- Nginx – Nginx is used by Kernl both as a front-door to the application as well as load balancer between the app servers. This was moved to it’s own server which allows it scale up when we need additional capacity. In the future (hopefully soon), we’ll use a floating IP address to give this portion of the infrastructure the ability to fail over to a backup Nginx server.
- Multiple App Servers – Kernl’s app servers can now scale horizontally. We’re currently running 3 app servers which Nginx load balances traffic to. This setup allows us to add app servers easily as our traffic grows.
- Automated Deployment – Kernl can now be deployed with a single command.
What’s Next?
- Caching the repository list that you see when you set up CI builds.
- Get a rich text editor set up on the installation and description fields.
- Theme change logs.
- Wrap up infrastructure work.
- Sign in / Sign up with BitBucket & GitHub.
- Slack Integration.
- HipChat Integration.