This year, we launched our new design, the VPS offers, our new phys­i­cal infra­struc­ture (with SSDs in all servers) and we start­ed to roll out updat­ed ver­sions of the data­base sys­tems avail­able to our cus­tomers.

Today, we are proud to announce the deploy­ment on all our servers of alproxy, the new ver­sion of our reverse proxy. This update is anoth­er mile­stone on the path to a mod­ern host­ing ser­vice. Read on to find out what’s new!

Reverse-proxy? What’s that?

Usually, a sin­gle piece of soft­ware han­dles all the HTTP traf­fic of a serv­er. At always­da­ta, we had to do things a bit dif­fer­ent­ly, and allow each account to run its own HTTP dae­mon (Apache) to serve its web pages. This design choice gives our users more con­trol over their pro­duc­tion envi­ron­ment: for instance, they can load cus­tom Apache mod­ules or choose the ver­sion of PHP on which to run their web­site.

This par­tic­u­lar­i­ty makes com­plex setups pos­si­ble (such as bridg­ing your app with an old Windows enter­prise serv­er… which is admit­ted­ly not for the faint of heart!), and also pro­vides bet­ter iso­la­tion between all the accounts host­ed on the same serv­er.

Schematic difference between a shared hosting and alwaysdata

This is why alproxy is a cen­tral piece in our pro­duc­tion archi­tec­ture: the reverse-proxy receives all HTTP requests, reads their des­ti­na­tion and then dis­patch­es the requests to the right account’s Apache instance. In this regard, alproxy acts a bit like the mail­boy sort­ing and deliv­er­ing mail to the dif­fer­ent com­pa­nies that have offices in the build­ing.

schema2_en

Not only does alproxy dis­patch HTTP traf­fic, but it also checks the health and sta­tus of all the HTTP dae­mons run­ning in each account: it starts a dae­mon when required, stops it if it has been idle for a while (to reclaim mem­o­ry that can be used by some­one else) and relaunch­es it when its con­fig­u­ra­tion is updat­ed or if it crash­es.

Since all the HTTP traf­fic goes through alproxy, it also has to han­dle the secu­ri­ty lay­er of HTTPS con­nec­tions. All of this is done dynam­i­cal­ly: the cer­tifi­cate and rout­ing is con­trolled from alwaysdata’s admin­is­tra­tion pan­el rather than writ­ten in con­fig­u­ra­tion files.

schema3_en

New features brought by alproxy

As a key com­po­nent of our tech­ni­cal stack, this upgrade brings improve­ments at many lev­els of the pro­duc­tion envi­ron­ment.

Better HTTPS security and private IPs no longer required

That’s right, HTTPS traf­fic served by alproxy is now secured accord­ing to the most recent indus­try stan­dards: using TLS 1.2 by default, secure ciphers only and enabling Forward Secrecy. Our HTTPS con­fig­u­ra­tion is now ranked A on SSLabs. And thanks to SNI, a pri­vate IP is no longer required to use your own cer­tifi­cate.

We are active­ly work­ing on the inte­gra­tion of Let’s Encrypt. In a few weeks, Let’s encrypt cer­tifi­cates will be ful­ly and auto­mat­i­cal­ly man­aged by always­da­ta. Thus, HTTPS will be enabled by default on all web­sites and domains. We also plan to enable OCSP sta­pling and TLS ses­sion resump­tion, two fea­tures of TLS that will bring wel­comed per­for­mance improve­ments.

More robust, alproxy fixes problems before you notice

This new ver­sion of alproxy has been designed to be more robust and to enable auto-heal­ing. For exam­ple, this means that alproxy han­dles over­load and traf­fic spikes more grace­ful­ly (for instance, dur­ing DDoS attacks), but also that var­i­ous prob­lems are auto­mat­i­cal­ly detect­ed and fixed.

Use Apache, Nginx, Node.js or all of them together

We will soon give our cus­tomers the abil­i­ty to choose the HTTP dae­mons they want to run in their accounts. You will be able to replace Apache by Nginx, Node.js or what­ev­er com­bi­na­tion fits your web­site require­ments.

And if you want to try bleed­ing-edge soft­ware, you can rely on alproxy to clean things up if ever some­thing goes wrong.

WebSockets are available

Using a mod­ern web serv­er with­out using shiny fea­tures is no fun, that’s why we added the sup­port of the WebSocket pro­to­col in alproxy.

There is more to come

While it’s too soon for us to talk about HTTP/2 (there’s still a lot of work to be done), we are look­ing for­ward adding a lot of new fea­tures in the com­ing months. For instance, we would like to add a WAF (Web Application Firewall) which blocks mali­cious requests (and has good chances to mit­i­gate bot attacks against vul­ner­a­ble WordPress instal­la­tions). We will also add a HTTP cache mid­dle­ware, which can be lever­aged to improve the respon­sive­ness of your web­sites and allow build­ing a CDN.

Under the hood

Before we end this tour of alproxy, let’s talk a bit about how it’s built!

alproxy is writ­ten in Python, and build on top of asyn­cio. We use many fea­tures intro­duced in Python 3.5, and some­times had to work around some non-triv­ial issues. During the devel­op­ment, we have worked on an open-source library called asynctest. We hope to pub­lish some tech­ni­cal blog posts to tell you more about some inter­est­ing parts of alproxy, like how we man­aged to han­dle TLS hand­shakes in a ful­ly asyn­chro­nous envi­ron­ment.

Towards a better service

We are con­stant­ly improv­ing our plat­form, and we have still a few more mile­stones to reach: always­da­ta will soon deploy its new pro­duc­tion envi­ron­ment, includ­ing updat­ed PHP, Python and Ruby ver­sions, and improved depen­den­cy man­age­ment (com­pos­er, pip, gem or npm will work out of the box).

We will be rolling out those updates to exist­ing accounts grad­u­al­ly, as we want to ensure that migrat­ing to this new envi­ron­ment won’t break your web­sites. Stay tuned!