Another fantastic week in the Kepler HQ here in Helsingborg, Sweden and this week it is launch weak, and we have a lot of new features that we have been cooking for some time.
After a round of feedback from our first 100 beta production clients, we discovered that we needed to improve some areas of our product to cater to the needs and be on the far front of what other hosting providers in Sweden are doing.
Today’s launch is our new load balancer upgrades! So let’s get the technicalities out of the way.
Layer 7 load balancing operates at the highlevel application layer, which deals with each message’s actual content. HTTP is the predominant Layer 7 protocol for website traffic on the Internet. Layer 7 load balancers route network traffic in a much more sophisticated way than Layer 4 load balancers, particularly applicable to TCPbased traffic such as HTTP. A Layer 7 load balancer terminates the network traffic and reads the message within. It can make a loadbalancing decision based on the message’s content (the URL or cookie, for example). It then makes a new TCP connection to the selected upstream server (or reuses an existing one by means of HTTP keepalives) and writes the request to the server.
Benefits of Layer 7 Load Balancing | NGINX Load Balancer. – https://www.nginx.com/resources/glossary/layer-7-load-balancing/
Layer 4 load balancing operates at the intermediate transport layer, which deals with the delivery of messages with no regard to the content of the messages. Transmission Control Protocol (TCP) is the Layer 4 protocol for Hypertext Transfer Protocol (HTTP) traffic on the Internet. Layer 4 load balancers forward network packets to and from the upstream server without inspecting the content of the packets. They can make limited routing decisions by inspecting the first few packets in the TCP stream.
With our new upgrades, we have totally rebuild our load balancer infrastructure and servers. Kepler Hosting does not currently use existing service providers and their load balancers. We have build or our self-automated load balance between having complete control but also saving on performance.
Before the upgrades, we used a Layer 7 load balancer with automatic Lets Encrypt SSL generation once the domain was pointed. There were both good things and a few drawbacks with this setup.
Good things
- Easy for the user to set up a domain. All you had to do was point your DNS to our Loadbalancer IP and then add the domain in your Kepler Base Dashboard.
- Automatic SSL check and generation
- Automatic propagation check before the domain can be added so that SSL does not fail
Points to fix
- Custom SSL certificate was not supported
- etc/hosts were not supported
- One had to point the domain before testing the site in a new environment due to DNS and SSL needed to be generated, which could lead to downtime.
- Not developer-friendly
- Took time to both add domain and generate SSL
- Bulk domain adding was not possible.
We went back to the drawing board, reviewed the feedback, and decided to make it flexible.
After about two months of intensive development and testing, we are launching our Kepler Load Balancer 2.0.
This time, we have made it possible to choose if you want to generate a Lets Encrypt SSL certificate or if you want to add your own or your clients SSL certificate.
Without a new and evolved SSL tab in the Kepler Base dashboard. Adding and managing SSL has never been easier.
And we now support etc/hosts where you can locally point your domain and test that everything works before you point your live domain. Minimising downtime and making sure everything goes smooth.
Managed SSL is just a click away. Either activate Lets Encrypt or adding a Custom SSL Certificate.